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. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
