jiebi/TextFlow huggingface dataset:
Original text:
4.2.2. <del> The ADDRESS_REQUEST capsule allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.  This capsule uses a Capsule Type of 0xfff101.  Its value uses the following format: </del>  IP Version of this address request.  MUST be either 4 or 6.

Reviewer comments:
This PR is one potential way to It simplifies route exchanges by going with NAME 's suggestion of sending the entire routing table each time something changes. It could be somewhat inefficient in some cases, but it becomes easier to reason about than what's currently in the draft when overlapping prefixes are involved.
This is interesting, but I'd prefer to wait to do this until after we post a -00 version. NAME is that OK with you?
I'd prefer we figure this out before -00, because this would be a pretty significant non-compatible change and I'd like to implement -00
NAME you nearly convinced me in the call that we rather want to announce ranges separately but I forgot why. Can you outline your reasoning again?
NAME my argument was that we shouldn't have two different ways to set routes, one that gives a table and one that gives a single route. If we go to only have a table, then it's fine.
I know saw the discussion in and support this approach. Also if we agree on this approach, I also think we should merge it before we submit -00
NAME I think we're ready to merge this PR
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think this looks good enough to include in the -00.

Revised text:
4.2.2.  <ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned. </ins> IP Version of this address request.  MUST be either 4 or 6.
Original text:
or split-tunnel. In this case, the client does not specify any scope in its request. <del> The server assigns the client an IPv6 address prefix to the client (2001:db8::/64) and a full-tunnel route of all IPv6 addresses (::/0). The client can then send to any IPv6 host using a source address in its assigned prefix. </del>  A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this <del> case, the advertised route is restricted to 2001:db8::/32, rather than ::/0. </del>  6.2.

Reviewer comments:
This PR is one potential way to It simplifies route exchanges by going with NAME 's suggestion of sending the entire routing table each time something changes. It could be somewhat inefficient in some cases, but it becomes easier to reason about than what's currently in the draft when overlapping prefixes are involved.
This is interesting, but I'd prefer to wait to do this until after we post a -00 version. NAME is that OK with you?
I'd prefer we figure this out before -00, because this would be a pretty significant non-compatible change and I'd like to implement -00
NAME you nearly convinced me in the call that we rather want to announce ranges separately but I forgot why. Can you outline your reasoning again?
NAME my argument was that we shouldn't have two different ways to set routes, one that gives a table and one that gives a single route. If we go to only have a table, then it's fine.
I know saw the discussion in and support this approach. Also if we agree on this approach, I also think we should merge it before we submit -00
NAME I think we're ready to merge this PR
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think this looks good enough to include in the -00.

Revised text:
or split-tunnel. In this case, the client does not specify any scope in its request.  <ins> The server assigns the client an IPv4 address to the client (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </ins> A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this  <ins> case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. </ins> 6.2.
Original text:
Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a <del> specific host or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target host or </del>  protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP <del> address to two CONNECT-IP requests that are scoped to different hosts and/or different protocols. </del>  CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined

Reviewer comments:
Instead of just an address / hostname, could we ask to open a tunnel to a prefix?
Tommy, can you please clarify the reasoning why this functionality is useful. Specifying the target as a subnet would to my understanding compared to a general IP tunneling address just restrict that the client will never try to send IP packets to any IP addresses outside of this subnet. And thus potentially enable serving multiple masque clients using restricted targets to share the source IP address. Is that the intention? Or is the intention here to have the masque server potentially redirect to another instance based on the target in the request?
This came up in a discussion—if we let you ask to connect to a specific hostname or address instead of all addresses (as we do today), we wondered if there was any need to connect to a subnet of addresses. This would be for connecting to an IPv6 /64, which is unique enough for a device, and doesn't require needing to assign an IP address exclusively to the client that is issuing the request.
I'm supportive of adding this if we can come up with an encoding that's not a pain to implement. For example slash with prefix length seems fine to me - the slash would be percent-encoded just like the IPv6 address colons are.
In relation to my just raised issue on source address validation if we add this functionality, I would think that the proxy would need to do destination or source address validation depending on direction of traffic to enforce the signalled aspect.

Revised text:
Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a  <ins> specific prefix or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target prefix or </ins> protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP  <ins> address to two CONNECT-IP requests that are scoped to different prefixes and/or different protocols. </ins> CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined
Original text:
There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary targets, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies <del> that support UDP proxying SHOULD restrict its use to authenticated </del>  users. Because the CONNECT method creates a TCP connection to the target,

Reviewer comments:
People shout at me for doing this, so I'm paying it forward. Perhaps you could move the SHOULD requirement to a statement in Section 3, so that it covers all forms of the CONNECT-UDP request.

Revised text:
There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary targets, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies  <ins> that support UDP proxying ought to restrict its use to authenticated </ins> users. Because the CONNECT method creates a TCP connection to the target,
Original text:
contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its UDP proxying request.  However, implementors should note that such proxied packets may not be processed by the proxy if it responds to the request with a failure, or if the proxied packets are received by the 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

Reviewer comments:
In section 5 in this sentence the term "proxied UDP packets" is used the only time and might not be clear: How about to just say "UDP packets in HTTP datagrams"?
+1 good improvement

Revised text:
contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP).  <ins> 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 proxy if it responds to the request with a failure, or if the proxied packets are received by the proxy before the request. </ins> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints
Original text:
servers that support UDP proxying ought to restrict its use to authenticated users.  UDP proxies share many similarities to TCP CONNECT proxies when considering them as infrastructure for abuse to enable denial of service attacks.  Both can obfuscate the attacker's source address

Reviewer comments:
This was prompted by .
LGTM. Nice and tight. URL Erik Kline has entered the following ballot position for draft-ietf-masque-connect-udp-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Should the 2xx discussion here include additional reference to the extended commentary in masque-h3-datagram#section-3.2? I really wish there could be more said about tunnel security. I was tempted to try to formulate some DISCUSS on the matter, but I cannot seem to see where any more extensive text was ever written for the CONNECT method. Nevertheless, there are plenty of concerns that could be mentioned, like what should a proxy do if the target_host is one if its own IP addresses, or a link-local address, and so on. I'm not entirely convinced that it suffices to claim that because the tunnel is not an IP-in-IP tunnel certain considerations don't apply. Anything and everything can be tunneled over UDP, especially if RFC 8086 GRE-in-UDP is what the payloads carry (or ESP, of course). It seems like most of the points raised in RFC 6169 apply; perhaps worth a mention. But as I said, I think all these concerns apply equally to CONNECT (in principle, anyway), and the text here is commensurate with the text for its TCP cousin (that I could find, anyway).

Revised text:
servers that support UDP proxying ought to restrict its use to authenticated users. <ins> There exist software and network deployments that perform access control checks based on the source IP address of incoming requests. For example, some software allows unauthenticated configuration changes if they originated from 127.0.0.1.  Such software could be running on the same host as the UDP proxy, or in the same broadcast domain.  Proxied UDP traffic would then be received with a source IP address belonging to the UDP proxy.  If this source address is used for access control, UDP proxying clients could use the UDP proxy to escalate their access privileges beyond those they might otherwise have.  This could lead to unauthorized access by UDP proxying clients unless the UDP proxy disallows UDP proxying requests to vulnerable targets, such as localhost names and addresses, link-local addresses, the UDP proxy's own addresses, multicast and broadcast addresses. UDP proxies can use the destination_ip_prohibited Proxy Error Type from PROXY-STATUS when rejecting such requests. </ins> UDP proxies share many similarities to TCP CONNECT proxies when considering them as infrastructure for abuse to enable denial of service attacks.  Both can obfuscate the attacker's source address
Original text:
could also cause issues for valid traffic. The security considerations described in HTTP-DGRAM also apply here.  8.

Reviewer comments:
This was prompted by .
LGTM. Nice and tight. URL Erik Kline has entered the following ballot position for draft-ietf-masque-connect-udp-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Should the 2xx discussion here include additional reference to the extended commentary in masque-h3-datagram#section-3.2? I really wish there could be more said about tunnel security. I was tempted to try to formulate some DISCUSS on the matter, but I cannot seem to see where any more extensive text was ever written for the CONNECT method. Nevertheless, there are plenty of concerns that could be mentioned, like what should a proxy do if the target_host is one if its own IP addresses, or a link-local address, and so on. I'm not entirely convinced that it suffices to claim that because the tunnel is not an IP-in-IP tunnel certain considerations don't apply. Anything and everything can be tunneled over UDP, especially if RFC 8086 GRE-in-UDP is what the payloads carry (or ESP, of course). It seems like most of the points raised in RFC 6169 apply; perhaps worth a mention. But as I said, I think all these concerns apply equally to CONNECT (in principle, anyway), and the text here is commensurate with the text for its TCP cousin (that I could find, anyway).

Revised text:
could also cause issues for valid traffic. The security considerations described in HTTP-DGRAM also apply here. <ins> Since it is possible to tunnel IP packets over UDP, the guidance in TUNNEL-SECURITY can apply. </ins> 8.
Original text:
3. <del> This document defines the "masque-udp" HTTP Upgrade Token. "masque- </del>  udp" uses the Capsule Protocol as defined in HTTP-DGRAM. <del> A "masque-udp" request requests that the recipient establish a tunnel over a single HTTP stream to the destination target server 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 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. </del>  When sending its UDP proxying request, the client SHALL perform URI template expansion to determine the path and query of its request.

Reviewer comments:
Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.

Revised text:
3.  <ins> This document defines the "connect-udp" HTTP Upgrade Token. "connect- </ins> udp" uses the Capsule Protocol as defined in HTTP-DGRAM.  <ins> A "connect-udp" request requests that the recipient establish a tunnel over a single HTTP stream to the destination target server 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 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. </ins> When sending its UDP proxying request, the client SHALL perform URI template expansion to determine the path and query of its request.
Original text:
"Upgrade". the request SHALL include a single "Upgrade" header with value <del> "masque-udp". </del>  For example, if the client is configured with URI template "https://proxy.example.org/{target_host}/{target_port}/" and wishes

Reviewer comments:
Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.

Revised text:
"Upgrade". the request SHALL include a single "Upgrade" header with value  <ins> "connect-udp". </ins> For example, if the client is configured with URI template "https://proxy.example.org/{target_host}/{target_port}/" and wishes
Original text:
"Upgrade". the response SHALL include a single "Upgrade" header with value <del> "masque-udp". </del>  the response SHALL NOT include any Transfer-Encoding or Content- Length header fields.

Reviewer comments:
Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.

Revised text:
"Upgrade". the response SHALL include a single "Upgrade" header with value  <ins> "connect-udp". </ins> the response SHALL NOT include any Transfer-Encoding or Content- Length header fields.
Original text:
The ":method" pseudo-header field SHALL be "CONNECT". <del> The ":protocol" pseudo-header field SHALL be "masque-udp". </del>  The ":authority" pseudo-header field SHALL contain the authority of the proxy.

Reviewer comments:
Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.

Revised text:
The ":method" pseudo-header field SHALL be "CONNECT".  <ins> The ":protocol" pseudo-header field SHALL be "connect-udp". </ins> The ":authority" pseudo-header field SHALL contain the authority of the proxy.
Original text:
7.1. <del> This document will request IANA to register "masque-udp" in the HTTP </del>  Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> masque-udp </del>  Proxying of UDP Payloads.

Reviewer comments:
Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.

Revised text:
7.1.  <ins> This document will request IANA to register "connect-udp" in the HTTP </ins> Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>.  <ins> connect-udp </ins> Proxying of UDP Payloads.
Original text:
versions. format defines how QUIC DATAGRAM frames are used with HTTP/3. <del> setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. </del>  capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP

Reviewer comments:
When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.

Revised text:
versions. format defines how QUIC DATAGRAM frames are used with HTTP/3.  <ins> setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. </ins> capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP