Benjamin Kaduk's No Objection on draft-ietf-httpbis-priority-11: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-httpbis-priority-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for another well-written and easy-to-read document from the

Many thanks to Bob Briscoe for the detailed tsv-art review, and to the
authors for the updates and responses to him.
Thanks as well to Robert Sparks for the secdir review.

I put my editorial suggestions in (to the extent that
I have concrete suggestions).

Section 4

   Intermediaries can consume and produce priority signals in a
   PRIORITY_UPDATE frame or Priority header field.  Sending a
   PRIORITY_UPDATE frame preserves the signal from the client, but
   provides a signal that overrides that for the next hop; see
   Section 14.  [...]

I'm having a bit of trouble following "provides a signal that overrides
that for the next hop"; is the "that" in "overrides that" referring to
"the signal from the client"?  Is the "signal that overrides" referring
to the PRIORITY_UPDATE frame emitted by the intermediary in question?
That seems to set us up for a scenario where the same frame is both
preserving and overriding the signal from the client, which doesn't make
much sense.  Is it perhaps that "when used by downstream intermediaries,
this mechanism would override the signal from the client, even though
the current intermediary under discussion has preserved the signal from
the client"?

Section 4.3.1

   When reviewing registration requests, the designated expert(s) can
   consider the additional guidance provided in Section 4.3 but cannot
   use it as a basis for rejection.

That seems to invite the question of what *can* be used as a basis for
rejection?  Or is the presence of any written specification sufficient
to trigger a "shall-issue" registration?

Section 7

   Servers SHOULD buffer the most recently received PRIORITY_UPDATE
   frame and apply it once the referenced stream is opened.  Holding
   PRIORITY_UPDATE frames for each stream requires server resources,
   which can can be bounded by local implementation policy.  [...]

Just to confirm my understanding: this local policy being described
would be distinct from the limit on the number of streams that the
client is allowed to open (which would also serve as a limit on the
amount of resources committed to storing priority information), right?

Section 9

   A client MAY use priority values to make local processing or
   scheduling choices about the requests it initiates.

Are the values in question here the server-generated response priority
values (used to affect future requests) or the client's own generated
priority values (used to affect those same requests)?

Received on Wednesday, 15 December 2021 23:56:17 UTC