Re: Éric Vyncke's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)

On Wed, 5 Jan 2022 at 12:10, Éric Vyncke via Datatracker
<noreply@ietf.org> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-httpbis-http2bis-06: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. As a side note, I am impressed
> that the WG only needed 6 revisions for such a major document! The introduction
> section is also crystal clear and to the points.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Mark Nottingham for the (short) shepherd's write-up including
> the section about the WG consensus (even if very terse).
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> -- Section 3.1 --
> Beside the history associated to "h2c", I really wonder why it is described in
> the document (just out of curiosity).

Enough description was given to explain what it is, but a note about
its deprecation was provided. In principle we could just delete the
first two paragraphs and leave only the note that it is no longer
defined.

>
> -- Section 5.1.1 --
> In "The identifier of a newly established stream MUST be numerically greater",
> is the increment interval 1 or can it be any positive non-nul integer ?

It can be any even positive non-zero integer. The fact that the
increment must be even derives from the first paragraph in the
section:

> Streams initiated by a client MUST use odd-numbered stream identifiers;
> those initiated by the server MUST use even-numbered stream identifiers.

>
> -- Section 5.2.1 --
> In the bullet 1. in "Both types of flow control", it is unclear to me what
> "both" refers to especially after reading the previous "allow a variety of
> flow-control algorithms", which hints to several (and not 2) mechanisms. Or is
> it per direction ?

The "both types" here applies to per-stream and per-connection flow
control, but I agree that it reads weirdly. We should reword it.

>
> -- Section 6.1 --
> The SEC AD will obviously have the final word on this but wouldn't random
> padding be more secure (at the expense of later compression of course) ?

I'm not really qualified to draw a conclusion here, but my layperson
view is that padding is only useful within an encrypted tunnel
provided by TLS, so the specifics of what the padding bytes _are_
should not matter: the TLS stream cipher should make their specific
byte value entirely unobservable. And it's way cheaper to assemble
zero bytes than it is to assemble random ones. You can also verify
that padding has been done correctly if you use zero bytes (though
probably you shouldn't, lest you anger Daniel Bleichenbacher).

>
> -- Section 6.7 --
> In figure 9, suggest to indicate that the Length is 8 octets.
>
> -- Section 9.1 --
> In "Clients SHOULD NOT open more than one HTTP/2 connection", should some words
> be added when the client has multiple interfaces (e.g., Wi-Fi & mobile) ? I
> understand that this is probably beyond HTTP...

I'm inclined to suggest that this is beyond HTTP/2.

>
> -- Appendix A --
> Some justifications (beyond the note at the end of the appendix) would be
> welcome.

I don't know that there are any justifications beyond the note at the
end of the appendix. Would you prefer that we formalised that note?

>
> Should a pointer to section 9.2.2 be added ?
>
>
>
>

Thanks for the feedback! Please find some changes here:
https://github.com/httpwg/http2-spec/pull/1010.

Received on Thursday, 6 January 2022 14:18:50 UTC