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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call