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

Request Review of draft-ietf-httpbis-proxy-status
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2021-08-11
Requested 2021-07-21
Authors Mark Nottingham, Piotr Sikora
Draft last updated 2021-08-04
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 Magnus Westerlund 
State Completed
Review review-ietf-httpbis-proxy-status-05-tsvart-lc-westerlund-2021-08-04
Posted at
Reviewed rev. 05 (document currently at 08)
Review result Ready with Issues
Review completed: 2021-08-04


This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

I found not transport related issues, only some clarity issues related to extra parameters and their registration. 

1. Section 2: 
Depending on the deployment, this might be a product or service name (e.g., ExampleProxy or "Example CDN"), a hostname (""), an IP address, or a generated string.

Is really an IP address a good identifier for intermediary? Or is the case that there some that doesn't have a better identity than its IP? And should there be additional security considerations about including IP addresses in the header?

2. Section 2.1.1:

Proxy Error Types can also define any number of extra parameters for use with that type. Their use, like all parameters, is optional. As a result, if an extra parameter is used with a Proxy Error Type for which it is not defined, it will be ignored.

It is not obvious how these extra parameters are to be encoded. 

If we take the example of DNS Error, how would that look like in an example? 

HTTP/1.1 502 Bad Gateway 
Proxy-Status: SomeReverseProxy; error=dns_error; rcode="123 something"; info-code=3454

Can you please clarify this aspect?

3. Section 3:

Shouldn't the extra parameters in Section 2.3 be registered in the HTTP Proxy-Status Parameters registry? If not can you clarify how they are handled?


Magnus Westerlund