jiebi/CodeConvo huggingface dataset:
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. <del> 4.6.2. </del> <ins> 4.7.2. </ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of IP
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <del> 4.6.3. </del> <ins> 4.7.3. </ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it
Code change:
This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!

Related discussion:
text: 4.2.1. The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that <del> it has assigned an IP address to it.  It allows assigning a prefix which can contain multiple addresses.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del> <ins> it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </ins> IP Version of this address assignment.  MUST be either 4 or 6.
Code change:
This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!

Related discussion:
text: The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length <del> is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </del> <ins> is equal to the length of the IP Address, the receiver of this capsule is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the receiver of this capsule is allowed to send packets from any source address that falls within the prefix. </ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple
Code change:
This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!

Related discussion:
text: notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. <del> This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del> <ins> Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </ins> IP Version of this route advertisement.  MUST be either 4 or 6.
Code change:
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

Related discussion:
text: requesting full-tunnel IP packet forwarding, or a specific proxied flow, see scope. <del> Along with a request, the client can send a REGISTER_DATAGRAM_CONTEXT capsule HTTP-DGRAM to negotiate support for sending IP packets in HTTP Datagrams (packet-handling). </del> <ins> The client SHOULD also include the "Capsule-Protocol" header with a value of "?1" to negotiate support for sending and receiving HTTP capsules (HTTP-DGRAM). </ins> Any 2xx (Successful) response indicates that the proxy is willing to open an IP forwarding tunnel between it and the client.  Any response
Code change:
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

Related discussion:
text: request with a failure, or if the datagrams are received by the proxy before the request. <del> Extensions to this mechanism MAY define new HTTP Datagram Format Types in order to use different semantics or encodings for IP payloads.  For example, an extension could define a new HTTP Datagram Format Type which enables compression of IP header fields. </del> When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local policy checks (e.g., source address validation), check their routing
Code change:
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

Related discussion:
text: Endpoints MAY implement additional filtering policies on the IP packets they forward. <del> 6. </del> <ins> 7. </ins> CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used. <del> 6.1. </del> <ins> 7.1. </ins> The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote
Code change:
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

Related discussion:
text: case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. <del> 6.2. </del> <ins> 7.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to
Code change:
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

Related discussion:
text: (2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. <del> 6.3. </del> <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
Code change:
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

Related discussion:
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> <ins> 8. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad
Code change:
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

Related discussion:
text: they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. <del> 8. </del> <ins> 9. </ins> <del> 8.1. </del> <ins> 9.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at
Code change:
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

Related discussion:
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> <ins> 9.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:
Code change:
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.

Related discussion:
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> <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.
Code change:
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 ).

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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
Code change:
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 .

Related discussion:
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> <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.