Re: Httpdir telechat review of draft-ietf-masque-connect-ip-08

Thanks for the review Mark!

We've addressed your comments in draft-ietf-masque-connect-ip-09.

David

On Wed, Apr 5, 2023 at 12:59 AM Mark Nottingham via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Mark Nottingham
> Review result: Ready with Issues
>
> # HTTPDIR comments for draft-ietf-masque-connect-ip-08
>
> I am an assigned HTTP directorate reviewer for
> draft-ietf-masque-connect-ip.
> These comments were written primarily for the benefit of the ART Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the HTTP Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
>
> Overall, I find the document well written and understandable. I only have
> questions on clarifications and think the draft is ready with nits for
> publication.
>
> ## Comment
>
> ### Intermediaries
>
> In 4.1. IP Proxy Handling, the first bullet says:
>
> > if the recipient is configured to use another HTTP proxy, it will act as
> an
> intermediary by forwarding the request to another HTTP server.
>
> The nature of this intermediary isn't very clear, but I believe that for
> it to
> function it needs support for the capsule protocol *and* this protocol; if
> so,
> that should be stated explicitly.
>
> Also, sections 4.3 and 4.5 specify how IP Proxies are to respond to a
> tunnelling request, but do not specify how the intermediary role created
> in 4.1
> is to respond to such a request; nor is it specified elsewhere, as far as
> I can
> tell. This can be addressed by broadening the first sentences in 4.3 and
> 4.5 to
> apply to both IP proxies and intermediaries that support this protocol.
>
> ## Nits
>
> In the abstract, the word 'proxy' is used without qualification. It would
> be
> better to use the term 'IP proxy'.
>
> In 4.3. HTTP/1.1 Response, 'abort the connection' is not typical usage
> (e.g.,
> in RFC9112); suggest 'close the connection'.
>
>
>