Hi David, Thank you for addressing my comments. I agree with your suggestions.
Best regards, Ines On Tue, Jun 30, 2026 at 3:11 AM David Schinazi <[email protected]> wrote: > Hi Ines, and thank you for your review. > > I've addressed your comments in this commit: > > https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp-listen/commit/fbcfa7484150d707062a2f27a5e37746a6841140 > > More detailed responses inline. > David > > On Tue, Jun 23, 2026 at 4:49 PM Ines Robles via Datatracker < > [email protected]> wrote: > >> 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. >> > > The important part here is "opened by the peer". You're not allowed to > open two contexts for the same tuple. What is allowed is when both > endpoints do it without knowing about the other's context. I rephrased the > paragraph to clarify this. > > >> >> 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. >> > > Agreed. I rephrased that paragraph. > > 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. >> > > Added a note that prior contexts are not impacted. I think it's clear that > the MUST NOT only applies to the proxy though. Hopefully the reworded > explanation clarifies why this only applies to the proxy. > > 4- It is not clear to me whether a Context ID can be reused after >> COMPRESSION_CLOSE. >> > > They cannot be reused. This is covered in the definition of Context IDs, > in Section 4 of RFC 9298. I added a reference. > > 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? >> > > This is also discussed in Section 4 of RFC 9298. > > 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. >> > > Added "for the duration of the tunnel". > > 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. >> > > A state diagram would be great but I don't think I'll have time to add one > unfortunately. I've added text to clarify what is possible though. > > Thanks for this document, >> >> Ines. >> >> >>
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
