AD review of draft-ietf-httpbis-priority-09

[Francesca Palombini <[e-mail]>]

Thank you for this document. Here is my review: please handle these  comments together with any future Last Call ones. I have opened an issue with the text below in the github: https://github.com/httpwg/http-extensions/issues/1783 . The first one should be fixed (and is easy to fix), the rest are more for my understanding – and apologies in advance if I have missed previous decisions.

Francesca

1. -----

FP: For some reason the IDnit check didn't pick it up, but the boilerplate about BCP 14 (first paragraph of Section 1.1) is outdated and should be updated to:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2. -----

   However, in order to maintain wire compatibility, HTTP/2 priority
   signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]).

FP: I have re-read this Section of HTTP2 several times, but I still can't be sure that "mandatory to handle" is accurate. In particular, paragraph 1 states that "some of the mandatory handling is retained" (side note: that leaves me confused to which parts are retained - maybe one of the HTTP2 authors in CC can help me here):

   This update to HTTP/2 deprecates the priority signaling defined in
   RFC 7540 [RFC7540].  The bulk of the text related to priority signals
   is not included in this document.  The description of frame fields
   and some of the mandatory handling is retained to ensure that
   implementations of this document remain interoperable with
   implementations that use the priority signaling described in RFC
   7540.

And the last paragraph states:

   priority of requests in the absence of any priority signals.  Servers
   MAY interpret the complete absence of signals as an indication that
   the client has not implemented the feature.  The defaults described

Which to me implies that clients are not required to implement them. But maybe this is me misinterpreting "handling" as processing from either clients or servers, while maybe it is intended to be mandatory to be supported from servers only?

Just to clarify, this might not be an actionable comment on this document, but just want to make sure that [HTTP2] and this document are consistent.

3. -----

   SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD
   stop sending the HTTP/2 priority signals.  If the value was 0 or if
   the settings parameter was absent, it SHOULD stop sending
   PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the

FP: For both SHOULDs above: it might be good to give a hint of when it is acceptable to deviate from the RECOMMENDations here. Otherwise, since there are a number of SHOULD throughout the document (I noted those in Section 4.1 as well), it might be good to address them in one sentence explaining that those recommendations have exceptions. (I am pointing this out as I expect it will otherwise come up later in IESG evaluation)

4. -----

Section 16. IANA Considerations

FP: Is there a reason not to request the first available values in the IANA registries: 0x7 for SETTINGS_NO_RFC7540_PRIORITIES and 0xb for PRIORITY_UPDATE instead of 0x9 and 0x10 ?