Skip to main content

Last Call Review of draft-ietf-masque-connect-ip-09

Request Review of draft-ietf-masque-connect-ip
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-03-15
Requested 2023-03-01
Authors Tommy Pauly , David Schinazi , Alex Chernyakhovsky , Mirja Kühlewind , Magnus Westerlund
I-D last updated 2023-04-10
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)
Assignment Reviewer Nancy Cam-Winget
State Completed
Request Last Call review on draft-ietf-masque-connect-ip by Security Area Directorate Assigned
Posted at
Reviewed revision 09 (document currently at 13)
Result Ready
Completed 2023-04-10
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document specifies how to proxy IP packets using HTTP.
The protocol defined allows for a client to establish a tunnel
with an HTTP server that acts as an IP proxy.

The document is well written and straightforward in its descriptions.
I only have one minor nit.

Section 4.5 - It would be good to clarify some error/unsuccessful
codes that speak explicitly to the proxy setup being unsuccessful as well.
I presume codes NOT in 2xx are deemed to be error/unsuccessful like
 305, 407, et al though not sure they either apply or
not apply. Perhaps adding a clause to the first bullet to clarify
That status codes of anything BUT 2xx should be deemed as unsuccessful
And must then abort the request.