Re: Tsvart last call review of draft-ietf-httpbis-proxy-status-05

Hi,

For anyone, I consider my comments resolved based on discussion on github.

Cheers

Magnus

On Thu, 2021-08-05 at 11:02 +1000, Mark Nottingham wrote:
> Hi Magnus,
> 
> Thanks for the review. See:
>   
> https://protect2.fireeye.com/v1/url?k=18027952-47994057-180239c9-86959e472243-6ae4abefd2621f9c&q=1&e=eaef9439-42b5-4c7a-b321-f40111cfe78f&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fissues%2F1591
> 
> Happy to continue the discussion here or over there.
> 
> Cheers,
> 
> 
> > On 4 Aug 2021, at 6:48 pm, Magnus Westerlund via Datatracker <
> > noreply@ietf.org> wrote:
> > 
> > Reviewer: Magnus Westerlund
> > Review result: Ready with Issues
> > 
> > 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
> > 
> > 
> 
> --
> Mark Nottingham   
> https://protect2.fireeye.com/v1/url?k=cc2bdbca-93b0e2cf-cc2b9b51-86959e472243-c8d4bff306a4942e&q=1&e=eaef9439-42b5-4c7a-b321-f40111cfe78f&u=https%3A%2F%2Fwww.mnot.net%2F
>