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

[David Schinazi <[e-mail]>]

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.
>
>
>