Subject: [Gen-art] Genart last call review of draft-ietf-httpbis-http2bis-06

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Mon, 22 Nov 2021 08:06:57 -0800

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:

---

From: Cory Benfield <[email-masked]>
Date: Mon, 22 Nov 2021 17:34:11 +0000

>    HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.

This was requested as https://github.com/httpwg/http2-spec/issues/889
and removed in https://github.com/httpwg/http2-spec/pull/891. Those
issues don't do a good job laying out the rationale, but the core
specifications have split out the semantics from the messaging
formats. This means that it no longer makes sense to claim that HTTP/2
(a messaging spec) doesn't change the semantics: it's implied by the
new core specifications drafts.

> just editorial, or is it rather a more substantive change that should be

You say that SHOULD is dropped, but was it not added? In either case,
yes, I think we should probably add it. I think the SHOULD was implied
by the prior text, but it was never anywhere close to explicitly
stated, and we should probably do so.

> to reuse connections. Was the rest of former section 9.1.2 considered

Status code 421 is now defined in the -semantics draft of the core
specifications:
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.421.

>    for managing these extension points are defined in Section 11 of

The section in 5.3 does not require reading from RFC 7540. The
necessary parts required for implementation of the specification are
present in this draft. RFC 7540 is necessary to understand why these
elements are the way they are, but that seems an informative use, not
a normative one.

The registries seems like a better case. I think I'll have to defer to
the more experienced RFC editors here: I'm not sure whether the
deference to the registries defined in RFC 7540 requires us to make
the reference normative.