[Gen-art] draft-ietf-masque-connect-udp-listen-12 ietf last call Genart review

[Ines Robles via Datatracker <[e-mail]>]

Document: draft-ietf-masque-connect-udp-listen
Title: Proxying Bound UDP in HTTP
Reviewer: Ines Robles
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-masque-connect-udp-listen-12
Reviewer: Ines Robles
Review Date: 2026-06-23
IETF LC End Date: 2026-06-23
IESG Telechat date: Not scheduled for a telechat

Summary:

This document describes an extension to UDP Proxying in HTTP that allows
sending and receiving UDP payloads to multiple hosts within the scope of a
single UDP proxying HTTP request.

I have some comments/questions that would be useful to address before
publication.

Comments/Questions:

1- Section 3.1: Related to duplicate tuple registrations, the text first states
that if both endpoints open a Context ID for the same IP-port tuple, the
Context ID opened by the proxy MUST be closed. (Since both endpoints can send
COMPRESSION_ASSIGN capsules, my understanding is that this situation can occur
when both the client and the proxy independently send a COMPRESSION_ASSIGN for
the same IP-port tuple).

However, the following sentence states that receipt of a COMPRESSION_ASSIGN for
a tuple that matches another open Context ID opened by the peer is malformed.

It is not clear to me how these two cases differ. Is the intent that these
statements apply to different situations? For example, does the former apply to
simultaneous registrations, while the latter applies to duplicate registrations
detected after a registration already exists? If so, it would be helpful to
describe this distinction explicitly.

2- Section 3.1 states "...uncompressed compression close...". It is not clear
to me what is meant by this expression. Consider rewording this text for
clarity.

3- Section 3.1 states: "If the uncompressed context is closed, the proxy MUST
NOT open new compressed contexts."

Appendix A appears to indicate that compressed contexts established prior to
closure remain valid. It may be helpful to state this explicitly in the
normative text. In addition, it is not clear to me whether the restriction on
opening new compressed contexts applies only to proxy-originated contexts or
whether there are any corresponding restrictions on client-originated contexts.

4- It is not clear to me whether a Context ID can be reused after
COMPRESSION_CLOSE.

5- It may be helpful to specify the handling of datagrams received for a
Context ID that has already been closed. For example, due to reordering or
packets already in flight, an endpoint may receive datagrams for a recently
closed context. Should such datagrams be discarded or treated as an error?

6- Section 7: The text recommends maintaining address stability per address
family. It is not clear to me what "address stability" means in this context.
For how long is the advertised address expected to remain stable? Clarifying
the intended scope of this recommendation would be helpful.

7- Would it be useful to include a state machine describing the lifecycle of a
Context ID? The current text defines the behavior of COMPRESSION_ASSIGN,
COMPRESSION_ACK, and COMPRESSION_CLOSE individually. A simple state-transition
diagram could help clarify the protocol and improve implementation consistency.
7.1- For example, it is not entirely clear to me, whether a COMPRESSION_ACK can
arrive after a COMPRESSION_CLOSE, and whether duplicate COMPRESSION_ACK
capsules are possible.

Thanks for this document,

Ines.