Skip to main content

Telechat Review of draft-ietf-masque-connect-ip-08

Request Review of draft-ietf-masque-connect-ip
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team HTTP Directorate (httpdir)
Deadline 2023-04-11
Requested 2023-03-15
Requested by Francesca Palombini
Authors Tommy Pauly , David Schinazi , Alex Chernyakhovsky , Mirja K├╝hlewind , Magnus Westerlund
I-D last updated 2023-04-04
Completed reviews Dnsdir Telechat review of -09 by R. (Miek) Gieben (diff)
Intdir Early review of -07 by Timothy Winters (diff)
Dnsdir Last Call review of -08 by R. (Miek) Gieben (diff)
Genart Last Call review of -08 by Vijay K. Gurbani (diff)
Artart Last Call review of -08 by Jean Mahoney (diff)
Tsvart Last Call review of -08 by Bob Briscoe (diff)
Secdir Last Call review of -09 by Nancy Cam-Winget (diff)
Opsdir Last Call review of -08 by Linda Dunbar (diff)
Intdir Telechat review of -09 by Timothy Winters (diff)
Httpdir Telechat review of -08 by Mark Nottingham (diff)
Intdir Telechat review of -10 by Dr. Joseph D. Touch (diff)
Dnsdir Telechat review of -09 by R. (Miek) Gieben (diff)
I think this document could benefit from an httpdir review. Thanks!
Assignment Reviewer Mark Nottingham
State Completed
Request Telechat review on draft-ietf-masque-connect-ip by HTTP Directorate Assigned
Reviewed revision 08 (document currently at 13)
Result Ready w/issues
Completed 2023-04-04
# 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

Overall, I find the document well written and understandable. I only have
questions on clarifications and think the draft is ready with nits for

## 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'.