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

Hi Roman,

Thanks for the feedback. I've responded and tracked the resulting changes in:
 https://github.com/httpwg/http-extensions/issues/1615

Happy to discuss further here or there if necessary.

Cheers,


> On 24 Aug 2021, at 5:13 am, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> 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]
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 24 August 2021 02:21:35 UTC