Subject: [secdir] Secdir last call review of draft-ietf-httpbis-http2bis-06

From: Sean Turner via Datatracker <[email-masked]>
Date: Mon, 06 Dec 2021 20:19:12 -0800

Reviewer: Sean Turner
Review result: Has Nits

Ready with nits. And by nits I mean editorial nits. I could not think of
anything security/privacy-related.

BTW - this I-D was a pleasure to read. Thanks to everybody who made it that way.

I read the GENART and TSVDIR reviews so I hopefully did not duplicate anything
they raised. I will admit that I did not just focus on new text. If, as a
result, I have unwittingly stumbled onto a hard fought WG consensus, then I do
not want my questions/comments to be see as restarting that discussion.

s3.3 (editorial): Even though s3 is clear that this section is about starting
with http, I would have thought that the last sentence in para 2 would have
been the very 1st sentence in the section to make that point very clear in case
it missed in s3.

s4.1 (editorial): s/Frames defined in this documented/
Frames defined in this document

s4.1 (editorial): s/Implementations MUST ignore and discard any frame that has
a type that is unknown./Implementations MUST ignore and discard frames of
unknown types.

s4.1 (editorial): s/Unused flags are those that have no defined semantics for a
particular frame type, and MUST be ignored and MUST be left unset (0x0) when
sending./Unused flags are those that have no defined semantics for a particular
frame type; unused flags MUST be ignored and MUST be left unset (0x0) when
sending.

s4.3 (editorial): s/END_HEADERS flag cleared/END_HEADERS flag unset
“unset” is used in s4.1.

s5 (editorial): s/Streams can be established and used unilaterally or shared by
either the client or server./Streams can be established and used unilaterally
or shared by either endpoint.

5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be disabled, but
in s5.2.2 you explain how to do exactly that. In s5.2.1, are you really saying
you can’t skip implementing the flow control mechanism and frames related to
connection control, i.e., WINDOW_UPDATE?

s5.3 (compliment): I think this is a great way to describe deprecating features
that did not work.

s7 (question): Since we already have h3, is it worth adding an h3 required
error?

s8.3.1 (question): s8.3.1 includes this:

     The recipient of a HTTP/2 request MUST ignore
      the Host header field if :authority is present.

And, it also includes this:

     A server SHOULD treat a request as malformed if
     it contains a Host header field that identifies a
     different entity to the :authority pseudo-header field.

If I follow the MUST, then is the SHOULD ever followed?

s9.2.1, last para, 1st sentence (editorial): Should the DHE suites reference
[TLS13] or [TLS1.2] in the TLS1.2 section?

s11 (confirmation, and I guess this is somewhat related to the last GENART
comment): Because you obsolete RFC 7540 with this I-D, I am going with the
assumption that the obsoleting is about the protocol and not about the
registries. As a result, there’s no need to copy the IANA instructions for
what’s in 7540 to this I-D.

s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446?

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 07 Dec 2021 17:12:05 +1100

Hey Sean,

Most of your changes are pretty straightforward and easy to address.   Thanks for the review.

You can review the changes I'm proposing here: https://github.com/httpwg/http2-spec/pull/1001

> been the very 1st sentence in the section to make that point very clear in case

Yeah, this is a little buried.  At the same time, I do somewhat like the natural flow that this text has.  The pull request above tries to pull out the important piece, but I'm not sure that I made it better in the process.  We'll kick it around some.

> connection control, i.e., WINDOW_UPDATE?

Good question.  I've clarified by saying that endpoints have to respect flow control set by their peer, even though they can opt out of setting limits of their own.  The original was incorrect-ish, but I was never motivated to fix it before.

> s7 (question): Since we already have h3, is it worth adding an h3 required

I don't think we need it for various reasons, mostly because HTTP/1.1 is very much lowest common denominator, from which we can kick off Alt-Svc and other stuff.  We've discussed various options in this space and we continue to have those discussions, but I don't get the impression that the HTTP11_REQUIRED thing is anything more than safety valve.

> If I follow the MUST, then is the SHOULD ever followed?

The MUST was not intended to be so broad; it's OK to validate as well.  What we don't want to see is the Host header field being used to determine the target URI.  I've narrowed it some (hopefully not too much).

> what’s in 7540 to this I-D.

Yeah, I don't know that we're ever going to get this right, but I think that we can rely on what is in the registries already and save making another copy.  FWIW, IANA got the changes absolutely right first time, so I don't think this is going to produce a bad result.  It's just a bit odd, that's all.

> s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446?

I am not sure that I want to wait behind that.  As that particular change is easy, it's something we can do if the stars align at any time before AUTH48, so I've been putting off that decision in the hopes that we can go out together.  Of course, I was hoping that this could go out with HTTP/3 and all the other HTTP docs, but that opportunity seems to have passed.

Thanks,
Martin

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Dec 2021 15:46:38 -0500

Martin,

Perfectly fine with how you resolved all of these.

Cheers,
spt

> On Dec 7, 2021, at 01:12, Martin Thomson <[email-masked]> wrote:
> 
> Hey Sean,
>