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
tsv-art@ietf.org 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 ("proxy-3.example.com"), 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?

Cheers

Magnus Westerlund