Skip to main content

Last Call Review of draft-ietf-httpbis-proxy-status-06
review-ietf-httpbis-proxy-status-06-artart-lc-fenton-2021-08-21-00

Request Review of draft-ietf-httpbis-proxy-status
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2021-08-23
Requested 2021-07-21
Authors Mark Nottingham , Piotr Sikora
I-D last updated 2021-08-21
Completed reviews Tsvart Last Call review of -05 by Magnus Westerlund (diff)
Secdir Last Call review of -05 by Rich Salz (diff)
Genart Last Call review of -05 by Thomas Fossati (diff)
Artart Last Call review of -06 by Jim Fenton (diff)
Intdir Telechat review of -06 by Benno Overeinder (diff)
Assignment Reviewer Jim Fenton
State Completed
Request Last Call review on draft-ietf-httpbis-proxy-status by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/slXTvhFQGNlZRdZFgMQcdB1vs94
Reviewed revision 06 (document currently at 08)
Result Almost ready
Completed 2021-08-21
review-ietf-httpbis-proxy-status-06-artart-lc-fenton-2021-08-21-00
Substantive comment:

The third paragraph from the end of Section 2 says:

   When adding a value to the Proxy-Status field, intermediaries SHOULD
   preserve the existing members of the field, to allow debugging of the
   entire chain of intermediaries handling the request.

Under what circumstances would an intermediary need to mess with existing
Proxy-Status entries? Please consider upgrading this requirement to a MUST, and
perhaps also require that the ordering of existing entries be preserved.

Minor comments:

The descriptions of errors in sections 2.3.13, 2.3.14, 2.3.28, 2.3.30, and
2.3.31 all contain a paragraph saying, "Note that additional information...(as
is the case for all errors)." It isn't clear whether this text belongs in the
"Notes" column of the registry entry being created since it is separate from
the bulleted list describing the entry. Please consider removing this text in
these sections and instead including it as introductory text describing the
error parameter.

The Notes for the entries either are empty or contain the text, "Responses with
this error type might not have been generated by the intermediary." I wonder if
this might more efficiently be represented by a Boolean flag in the registry
entries, but probably preserving the Notes field in the registry for future use.

The introduction uses both the phrase "towards the origin server" and the term
"upstream". It might be helpful to some readers to make it clear that they're
synonymous, e.g., "towards the origin server (upstream)"

Section 1.1 says that this specification uses ABNF, but I find only structured
fields. Consider removing the mention of ABNF and the informative reference to
RFC 5234.