Many thanks to Jasdip Singh for the ARTART review, and thanks to the authors for addressing his review.

Thanks to Yaroslav R. for the SECDIR review and Alejandro S. for the shepherd's write up.

I will note that the security considerations continues in reference-after-reference and there could be some consideration on how to provide such extensive (and generally quite good) guidance without forcing readers to open 4+ RFCs to get it all.

Thanks to Yaroslav Rosomakho for their secdir review 

Only one Nit:  Section 1, spell out ICE on first use.

I have some COMMENTS (non-blocking), which I hope will improve this specification:

(1) Perhaps editorial, but at least reducing clarity for me: the terms "IP" "target IP" "unknown IPs" "Restricting IPs" "Unknown IP" etc seem like an incorrect use of an abbreviation IP meaning the "Internet Protocol". Please check carefully and then replace "IP" by "IP address" or "IP addresses" etc, to follow the usage in https://www.rfc-editor.org/info/rfc9484/.

(2) The text says: “Once an endpoint has either sent or received a COMPRESSION_CLOSE for a given Context ID, it MUST NOT send any further datagrams with that Context ID. "
- This was understood, but I did not see where the document said whether datagrams could be re-ordered - so, can datagrams be delivered after a close? .. and what should then happen? (Is it intended to be covered by section 8?)

(3) (Memory) limits are appropriately identified in section 9, but  no method is defined to detect these limits being exceeded. Ought this section also to recommend/require logging or counting when these limits are exceeded?

I also note these NiTs:
The text says: "If an endpoint nreceives COMPRESSION_ACK capsule for a Context ID "
- Insert “a” before “COMPRESSION_ACK capsule”?
The text says: "the effective MTU will change.” I expect this is /change/reduce/ - since I would not expect it to increase by adding protocol headers!

Section 11.1: Please use the exact IANA registry name “Hypertext Transfer Protocol (HTTP) Field Name Registry” rather than “HTTP Field Name” registry.

Section 3:

246 >    If the uncompressed Context ID is closed, the proxy MUST NOT open new
247 >    compressed Context IDs.  Allowing the proxy to do so would permit
248 >    traffic from source tuples not selected by the client, defeating the
249 >    IP restriction described in Section 8.1.  Note that compressed
250 >    Context IDs that were established prior to the closing of the
251 >    uncompressed Context ID are not impacted.

This resolves half of Ines's question 3 (pre-existing compressed contexts
survive), but leaves the other half open: is the client also expected to
stop opening *new* compressed Context IDs once it has closed its uncompressed
one, or is the restriction deliberately one-sided because the client is
trusted to only register targets it still wants to hear from? Section 8.1
reads as though the asymmetry is intentional -- the client is the one doing
the restricting -- but the document never says so, and a reader coming from
the proxy-side MUST just above could reasonably wonder whether the same
prohibition was meant to apply symmetrically. A one-sentence clarification
would help here.

---

Section 9:

490 >    Note that if the compression response (COMPRESSION_ACK or
491 >    COMPRESSION_CLOSE) cannot be immediately sent due to flow or
492 >    congestion control, an upper limit on how many compression responses
493 >    the endpoint is willing to buffer MUST be set to prevent memory
494 >    exhaustion.  The proxy MUST abort the request stream if this limit is
495 >    reached.

Aborting the whole request stream -- tearing down every Context ID on the
tunnel -- seems like a heavy-handed response to a buffering limit on
COMPRESSION_ACK/COMPRESSION_CLOSE alone, especially since ordinary UDP
payload congestion elsewhere in the tunnel isn't given the same treatment.
Have the authors considered whether rejecting or dropping the specific
registration that would overflow the buffer (i.e., failing that one
COMPRESSION_ASSIGN) is sufficient, reserving the full abort for cases where
the endpoint can no longer track state safely at all?

Hi David and Abhijit, 

Thank you for the effort put into this well-written document.

Thanks also to Aihua Guo for the OPSDIR review.

Please find below some few comments: 

# I failed to find where “unextended UDP proxying request“ was defined. Idem for “bound UDP proxying”.

# valid target

CURRENT:
  When "target_host" and "target_port" are set to a valid target, 

I guess we meant here valid host and port values? If so, please make that explicit as I wasn’t sure if by “valid target” we imply some other checks.

# wildcars

CURRENT:
   If only one of the "target_host" and the "target_port" variables is
   set to the '*' character, the request is malformed.  

Maybe this is obvious for the authors, but it wasn’t clear to be why having both as wildcard is acceptable but, for example, expressing no port preference is not allowed.

# Like any address sharing mechanism, the operational complications in rfc6269 will be experienced. I suggest to a note under Section 10.

# Likewise, operating a proxy will have to consider the Logging requirements similar to rfc6888#section-4 are required. You may consider a brief note under Section 10.

# I sent a PR with few editorial change proposals [1].

Cheers,
Med

[1] https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp-listen/pull/52/changes

Thank you to Ines Robles for the GENART review.

I second Chris' comment about your Security Considerations. I almost stepped in to DISCUSS why you haven't said anything about amplification attack potential, but realized it's discussed in RFC 8656 (TURN) which you defer to, in its nearly 400 line long security considerations. I highly advise adding at least some basic description of the things an implementer should think about as their greatest risks. In my UDP 53 traumatized mind, this obviously would include amplification attacks.