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: