Last Call Review of draft-ietf-httpbis-proxy-status-06

Request Review of draft-ietf-httpbis-proxy-status
Requested rev. 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
Draft last updated 2021-08-21
Completed reviews Secdir Last Call review of -05 by Rich Salz (diff)
Genart Last Call review of -05 by Thomas Fossati (diff)
Tsvart Last Call review of -05 by Magnus Westerlund (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 Snapshot
Review review-ietf-httpbis-proxy-status-06-artart-lc-fenton-2021-08-21
Posted at
Reviewed rev. 06 (document currently at 08)
Review result Almost Ready
Review completed: 2021-08-21


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.