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

[Kazuho Oku <[e-mail]>]

Hello Benjamin,

Thank you for your review. We discussed the PR that you opened as part of
the review (thank you for filing that!), but Francesca noticed that we did
not respond to other comments.

Sorry for the delay, but please see below.

2021年12月16日(木) 8:56 Benjamin Kaduk via Datatracker <[e-mail]>:

> 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 https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for another well-written and easy-to-read document from the
> HTTPBIS WG!
>
> 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
> https://github.com/httpwg/http-extensions/pull/1861 (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"?
>

I can see the confusion; filed a PR that should address the issue:
https://github.com/httpwg/http-extensions/pull/1880.


> 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?
>

That is my understanding. IIRC, the intention here is prohibit httpbis from
blocking the registration of new priority parameters based on the argument
that they have issues.

If httpbis acts as such, third parties would use a new header field name
instead. That's a lose-lose situation for all of us. Considering that, I
think current policy is adequate.


> 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?
>

Correct. The requirement here is that PRIORITY_UPDATE has to reach the
server before the HEADERS frame that opens the new stream, so that the
server would apply the signal carried by the frame rather than that carried
by the Priority header field (or lack of).


> 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)?
>

That's an excellent question. I recall that the working group has focused
on how the value of the request header field or the PRIORITY_UPDATE frame
can be used. But there is no reason to prohibit clients from using the
priority response header field. To conclude, I think that current text
as-is is fine.



-- 
Kazuho Oku