Reviewer: Dan Romascanu Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpbis-http2bis-06 Reviewer: Dan Romascanu Review Date: 2021-11-22 IETF LC End Date: 2021-11-26 IESG Telechat date: Not scheduled for a telechat Summary: This document is Ready from a GenART point of view, with a number of minor issues which I recommend to be clarified before approval. Major issues: Minor issues: 1. It seems to me that a better clarification of the issues related to backward compatibility is needed. RFC 7540 included the following sentence in the Abstract: > This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. Why was this taken out? 2. I noticed changes in Section 5.5 that describes the mechanisms for extending HTTP/2. RFC 7540 > Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. In this case, it could also be necessary to coordinate when the revised layout comes into effect. Note that treating any frames other than DATA frames as flow controlled is such a change in semantics and can only be done through negotiation. draft-ietf-httpbis-http2bis-06 >Extensions SHOULD avoid changing protocol elements defined in this document or elements for which no extension mechanism is defined. This includes changes to the layout of frames, additions or changes to the way that frames are composed into HTTP messages (Section 8.1), the definition of pseudo-header fields, or changes to any protocol element that a compliant endpoint might treat as a connection error (Section 5.4.1). An extension that changes existing elements MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. In this case, it could also be necessary to coordinate when the revised layout comes into effect. For example, treating frames other than DATA frames as flow controlled requires a change in semantics that both endpoints need to understand, so this can only be done through negotiation. This seems to me like a change as the SHOULD recommendation is dropped. Is this just editorial, or is it rather a more substantive change that should be mentioned in Appendix B. 3. RFC 7540 included a section (9.1.2) about the 421 Status Code, including description of behavior of clients and proxies. This was eliminated in the new version, which includes only one reference to servers that do not wish clients to reuse connections. Was the rest of former section 9.1.2 considered unnecessary? Why? 4. Should not be [RFC7540] be a Normative Reference? It is referred to around 20 times in the document. The discussion about priority signaling in 5.3 seems to require reading text from RFC 7540 that was not taken in this document. Also in Section 5.5 > Registries for managing these extension points are defined in Section 11 of [RFC7540]. Nits/editorial comments: -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call