Roman Danyliw's No Objection on draft-ietf-httpbis-bcp56bis-14: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-bcp56bis-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Joseph Salowey for the SECDIR review.

** Section 4.5 and 4.6.
   ... they are
   encouraged to engage with the HTTP community early, and document
   their proposal as a separate HTTP extension, rather than as part of
   an application's specification.

Can more specificity be provided on who this “HTTP community” might be?  Is
this consulting whatever is the active WG maintaining HTTP in the IETF?  The
implementation community of HTTP libraries or browsers?

** Section 6.

If the transport is
   unencrypted, an attacker that can eavesdrop on HTTP communications
   can often escalate their privilege to perform operations on
   resources.

To me, eavesdrop means just the ability to read the cookie/bearer token.  An
on-path attacker could also escalate privileges by modifying the cookie. 
Proposing text just as:

NEW
If the transport is
   unencrypted, an attacker that can eavesdrop and/or modify HTTP communications
   can often escalate their privilege to perform operations on
   resources.

** Editorial

-- Section 3.1.
   It also allows people to leverage their
   knowledge of HTTP semantics without special-casing them

Consider using alternative wording for “special-casing”

--  Section 4.6.  Editorial.  Missing reference notation.
OLD

HTTP/2
I-D.ietf-httpbis-http2bis message format.

NEW
HTTP/2
[I-D.ietf-httpbis-http2bis] message format.

-- Section 4.6.1.  Editorial.  s/can not/cannot/

-- Section 4.9.1 and 4.9.4.  Both of these sections have illustrative examples
of responses.  They are clear.  Note that Section 4.1 calls out that “[w]hen
specifying examples of protocol interactions, applications should document both
the request and response messages, with complete header sections, preferably in
HTTP/1.1 format”.  It isn’t clear if the guidance for HTTP application (this
document) should follow it’s own guidance (since this document isn’t an HTTP
application).

-- Section 4.11.  Editorial.  Missing reference notation.

OLD
HTTP/3 I-D.ietf-quic-http

NEW
HTTP/3 [I-D.ietf-quic-http]

Received on Monday, 23 August 2021 19:13:26 UTC