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@xxxxxxxx> 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@xxxxxxxx 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 >
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
