Dan, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-11-22, at 18:06, Dan Romascanu via Datatracker <noreply@xxxxxxxx> wrote: > > 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: > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
