jiebi/TextFlow huggingface dataset:
Original text:
case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. <del> 6.2. </del>  The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0.  <ins> 7.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to
Original text:
(2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. <del> 6.3. </del>  The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
(2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host.  <ins> 7.3. </ins> The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection
Original text:
UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy. <del> 7. </del>  There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy.  <ins> 8. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad
Original text:
they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. <del> 8. </del>  <del> 8.1. </del>  This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks.  <ins> 9. </ins>  <ins> 9.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at
Original text:
This document <del> 8.2. This document will request IANA to register IP_PACKET in the "HTTP Datagram Format Types" registry established by HTTP-DGRAM. 8.3. </del>  This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:

Reviewer comments:
Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric

Revised text:
This document  <ins> 9.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:
Original text:
scope for this document but can be implemented using CONNECT-IP extensions. <del> Since CONNECT-IP endpoints can proxy IP packets send by their peer, they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. </del>  10.

Reviewer comments:
Connect-IP enables the Masque client to set the source address for any IP packets it requests the MASQUE proxy to forward to the external network. This enables the potential for source address spoofing by the MASQUE client or an entity prior to it. For proxies that assign addresses to the client and allows general access to Internet I think it would be really good to recommend or require the masque server to perform source address validation. However, there clearly exist some use cases where the MASQUE will be used to establish a virtual path between two networks and where source address validation is hard as neither network may be stubs networks. However, I think there are several things to address in the document. 1) Include in security description a discussion of the risks here and when it would be useful to perform source address validation. Especially for the assigned address(es) use case where rejecting all but the provided address range would be possible. 2) Consider if the security risks for certain deployments are such that source address validation is RECOMMENDED or REQUIRED
I don't think this is correct. I thought there was text in the draft that enforced that the source address was in the set of addresses the endpoints agreed were routable. [4.2.1] ADDRESSASSIGN capsule says "Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.". I suppose this means we need a clarification that a MASQUE proxy MUST drop any packets whose source address is not in the set of addresses agreed upon in ADDRESSASSIGN capsules.
I think we can write a PR that addresses this. Here's a rough shape of a paragraph: how does that sound?
+1 to this text.

Revised text:
scope for this document but can be implemented using CONNECT-IP extensions.  <ins> Falsifying IP source addresses in sent traffic has been common for denial of service attacks.  Implementations of this mechanism need to ensure that they do not facilitate such attacks.  In particular, there are scenarios where an endpoint knows that its peer is only allowed to send IP packets from a given prefix.  For example, that can happen through out of band configuration information, or when allowed prefixes are shared via ADDRESS_ASSIGN capsules.  In such scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. </ins> 10.
Original text:
This document defines the "connect-udp" HTTP Upgrade Token. "connect- udp" uses the Capsule Protocol as defined in HTTP-DGRAM. <del> A "connect-udp" request requests that the recipient proxy establish a tunnel over a single HTTP stream to the destination target identified by the "target_host" and "target_port" variables of the URI Template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa </del>  until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP.

Reviewer comments:
The technicalities here are fine but I think someone will pick up on the grammar sooner or later. How about something like below (take or leave it) "Clients issue requests containing a "connect-udp" upgrade token in initiate an UDP tunnel associated with a single HTTP stream. The client indicates, to the proxy, the target of the tunnel using the "targethost" and "targetport" variables of the URI template (see ).

Revised text:
This document defines the "connect-udp" HTTP Upgrade Token. "connect- udp" uses the Capsule Protocol as defined in HTTP-DGRAM.  <ins> Clients issue requests containing a "connect-udp" upgrade token to initiate a UDP tunnel associated with a single HTTP stream.  The target of the tunnel is indicated by the client to the proxy via the "target_host" and "target_port" variables of the URI Template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa </ins> until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP.
Original text:
udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request:  3.3. The UDP proxy SHALL indicate a successful response by replying with

Reviewer comments:
Given that this draft is couched in terms of , the use of in HTTP/1.1 is surprising. At the least, a reason should be mentioned.
Closing for now, as I have more serious concerns that may make this OBE.
Reopening.

Revised text:
udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: <ins> In HTTP/1.1, this protocol uses the GET method to mimic the design of the WebSocket Protocol WEBSOCKET. </ins> 3.3. The UDP proxy SHALL indicate a successful response by replying with
Original text:
The path component of the URI Template MUST start with a slash "/". <del> All template variables MUST be within the path component of the URI. </del>  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.

Reviewer comments:
The client configuration section says: ... but the examples contain: Which is it?
This was an accident, I suspect it dates back to when the document referred to which contains both path and query. Fixing to mention both path and query via .

Revised text:
The path component of the URI Template MUST start with a slash "/".  <ins> All template variables MUST be within the path or query components of the URI. </ins> The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.
Original text:
the method SHALL be "GET". <del> the request-target SHALL use absolute-form (see H1). </del> the request SHALL include a single Host header field containing the origin of the UDP proxy.

Reviewer comments:
Is this strictly necessary?
You're right, it's unnecessary and doesn't add anything. Removing via .

Revised text:
the method SHALL be "GET".  the request SHALL include a single Host header field containing the origin of the UDP proxy.
Original text:
contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. </del> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527

Reviewer comments:
PR in response to Al's OPSDIR review -- Reviewer: Al Morton Review result: Has Nits Hi David, this is the OPS-DIR review. I tried to stay in my lane. I found this paragraph confusing (which doesn't mean it is incorrect, just that someone with limited background read the section 2 requirements list, all MUSTs, and then the paragraph below, which seems to have a conflicting MUST with the SHOULD and MAY that follows). Help readers like me understand the options you are allowing here: If the client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the UDP proxy. While clients SHOULD validate the requirements above, some clients MAY use a general-purpose URI Template implementation that lacks this specific validation. I see that Christer's GEN_ART review picked-up on this too (I looked after I was done...). In Section 5, there seems to be a possible operations issue for proxy operators: Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. This seems like a good place to limit the amount of optimistic traffic, given that the request is not yet accepted. (also, would the optimistic traffic use Context ID zero?) In Performance Considerations UDP proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. This requirement is written qualitatively, so users might "know a violation if they see it", but not hold the proxy system/operator to any specific performance without providing more details here. Inter-packet delay variation measurements on proxy ingress and egress would characterize increased burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased burstiness will be avoidable, or enforceable.) Thanks in advance for considering these comments, Al

Revised text:
contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP).  By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527
Original text:
consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds <del> to the CONNECT-UDP request with a 2xx (Successful) response, and indicates it supports HTTP Datagrams by sending the corresponding registration capsule. </del>  Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however

Reviewer comments:
This text was a mistake I made when converting from Datagram-Flow-Id to capsules.
Section 4 states that the proxy responds to a CONNECT-UDP request with 2xx and a corresponding registration capsule to indicate end-to-end support of datagrams. If the client sends a REGISTERDATAGRAMCONTEXT capsule, the corresponding capsule from the proxy will be of the same kind, and it will register a new server-generated context ID. So now we would have two context IDs for the same stream, which seems a bit unnecessary. Could we simply omit the step where the proxy sends a registration capsule and simply state that a 2xx response to the CONNECT-UDP request is sufficient indication of end-to-end datagram support?
My reading of the spec is different, URL says So for example, if the client sends a request on stream 4 and then REGISTERDATAGRAMCONTEXT { Context ID (0)}, the server will respond with REGISTERDATAGRAMCONTEXT { Context ID (0)} to confirm that the context is accepted.
That makes sense, I was assuming that the "used in both directions" referred to datagrams. I think my confusion in part came from the same section that says: But sending a registration capsule with an already registered context ID is not a new registration I suppose. Maybe it's good to clarify this a bit in the datagram spec. I'll open a separate issue there.
I agree the draft is a bit ambiguous here.
Indeed, the spec is unclear here, my apologies. I got this wrong when I rewrote the old Datagram-Flow-Id text. The server doesn't need to echo the registration capsule here since the client's registration is bidirectional. NAME we should add text to HTTP Datagrams to clarify what we want to do about echoing registrations, is it required allowed forbidden I'm leaning towards (3) unless we have a use case for communicating the fact that a context is "accepted" and in which case I'd say (2).
Aha! In that case I apologise too. This seems important for interop! Now I remember, I think some people felt registration ack wasn't needed as long as there was a way to reject. And we have that with CLOSEDATAGRAMCONTEXT. So I think (3), modelled as implicit accept and explicit close, sounds good. That cuts down the chatter (and probably simplifies some code in my implementation).

Revised text:
consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds  <ins> to the CONNECT-UDP request with a 2xx (Successful) response. </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however
Original text:
5.1.  UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying

Reviewer comments:
A proxy can receive a UDP packet from an origin to a client that cannot fit within a DATAGRAM frame, given either the limit set by the maximum datagram frame size, or based on the current path MTU. In this case, one solution is for the proxy to generate ICMP errors back to the sender. If that sender implements PMTU discovery, it should adjust its size.
I think adding advice here is good, though we can't mandate sending ICMP because most OSes don't let user space applications send ICMP.
Yes, we can't mandate it, but we should recommend it I think. For a full-blown production server, it should be possible.
Recommendation seems sensible. Although this does get me thinking about what the expectations of fragmentation are, we can't expect all UDP protocols to set DF.
The DATAGRAM capsule type offers one way to address this. Capsules can be arbitrarily large, because they'll be reassembled by QUIC. If it won't fit in a QUIC DATAGRAM and you don't want to drop it, it goes in a DATAGRAM capsule. Now, that might not always be desirable, because capsules don't have all the behavior that causes you to choose datagrams in the first place; a proxy that behaves that way will mess with PMTUD, and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules. Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped?

Revised text:
5.1. <ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot be fragmented, they can only carry payloads up to a given length determined by the QUIC connection configuration and the path MTU.  If a proxy is using QUIC DATAGRAM frames and it receives a UDP payload from the target that will not fit inside a QUIC DATAGRAM frame, the proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. 5.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying
Original text:
recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes <del> independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. </del>  6.1.

Reviewer comments:
recovery (e.g., [QUIC]), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduce performance as both can sometimes independently retransmit the same data. To avoid this, HTTP/3 datagrams SHOULD be used. This text could maybe be clearer. Is it trying to say "You SHOULD use H3 + Datagram" or "You SHOULD use H3 and if you do you should use datagram". I.e., is it possible to use H3 but not datagram?
You're right, this is unclear. That text predates the refactor of HTTP/3 Datagram to HTTP Datagrams, so we should tweak it to say "To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame."

Revised text:
recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes  <ins> independently retransmit the same data.  To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame. </ins> 6.1.
Original text:
the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del>  1.

Reviewer comments:
In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,

Revised text:
the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC  <ins> DATAGRAM frames with HTTP/3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> 1.