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

[Ines Robles <[e-mail]>]

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 <[e-mail]>
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 <
> [e-mail]> 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.
>>
>>
>>