W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

Roman Danyliw's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)

From: Roman Danyliw via Datatracker <noreply@ietf.org>
Date: Mon, 03 Jan 2022 08:46:44 -0800
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-httpbis-http2bis@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net
Message-ID: <164122840433.5266.917309014087563431@ietfa.amsl.com>
Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-http2bis-06: 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-http2bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Sean Turner for the SECDIR review.

** Section 2.  Editorial.  Could this section provide a summary of what’s
getting obsoleted from RFC7540 in one place?  The text already explicitly says
that the RFC7540 prioritization scheme is deprecated.  Should the text also
note that the upgrade mechanism of HTTP2-Settings header field (per Section 3.2
of RFC7540) is obsolete?  This detail is buried in Section 11 and Section 3.1
could be clearer.

** Section 5.3.2
  Servers SHOULD use other contextual information in determining
  priority of requests in the absence of any priority signals.

Given that “the prioritization signaling in RFC7540 [RFC7540] was not
successful.”  Can more be said to guide implementers on what contextual
information could be used?

** Section 6.5.1.  Editorial.   After Figure 7, should this section have the
boiler plate text “The Length, Type, Unused Flag(s), Reserved, and Stream
Identifier fields are described in Section 4”?

** Section 8.1.1.  Per Section 6.1, padding octets must be zero and a recipient
may treat non-zero padding as a connection error (no change in guidance from
RFC7540).  In this new section, would it be worth reiterating this guidance and
categorizing non-zero padding as a malformed frame?
Received on Monday, 3 January 2022 16:46:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 3 January 2022 16:46:59 UTC