jiebi/CodeConvo huggingface dataset:
Change:
I think it would be helpful to review the lifetime text in URL more closely align with it where it makes sense. What stuck out to me first was speaking about HTTP/3 specifically sticks out because all versions are supported. Second, there's no text about if a proxy can timeout itself and close the stream.
This makes sense, we can be a bit more specific with this guidance

Discussion:
been formed. The lifetime of the IP forwarding tunnel is tied to the IP proxying <del> request stream.  Closing that stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, or a QUIC RESET_STREAM frame) closes the associated IP tunnel. </del> <ins> request stream.  The IP proxy MUST maintain all IP address and route assignments associated with the IP forwarding tunnel while the request stream is open.  IP proxies MAY choose to tear down the tunnel due to a period of inactivity, but they MUST close the request stream when doing so. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The
Change:
Our cousin, CONNECT-UDP, has simple examples about how the requests and responses look in HTTP/1.1, 2 and 3. I appreciate the appendix has complicated examples. Would it be worth providing simple examples in Section 4, or at least forward referencing to them so people can get a feel?
That would be nice, if someone's willing to volunteer to do the editorial work of writing that PR. In other words, I'll happily review and merge it, but I don't have time to write it personally.
there's 5 authors on the draft, maybe one of the other 4 can spare the 10 minutes it would take?
Simple enough to add =)
Thanks for writing this!

Discussion:
malformed.  The recipient of such a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code. <ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: </ins> 4.2. The IP proxy SHALL indicate a successful response by replying with

If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the connection. <ins> For example, the IP proxy could respond with: </ins> 4.3. When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP

An IP proxying request that does not conform to these restrictions is malformed (see H2 and H3). <ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: </ins> 4.4. The IP proxy SHALL indicate a successful response by replying with

If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the request. <ins> For example, the IP proxy could respond with: </ins> 4.5. Unlike UDP proxying requests, which require specifying a target host,
Change:
Which IPv6 address is the Client pinging through the tunnel? The Client knows which source address(es) it can use (from the ADDRESSASSIGN(s) that it has received), but not necessarily a good destination address. When ROUTEADVERTISEMENT are networks, it is not clear which hosts if any on those networks are pingable. In the flow forwarding case, there is a clear target host, but do we want to require the target to respond to ICMPv6 echo request pings lest it be unreachable on any protocol over connect-ip? Perhaps the destination address for these pings should be a special address on which the IP Proxy itself is required to respond to ICMPv6 echo requests through the tunnel?
Good question! NAME thoughts?
This was intended to be the link-local address(es)
Good catch. I'll write a PR suggesting to use the link-local all-nodes multicast address if the peer's address is unknown

Discussion:
bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that the previous techniques is <del> sufficient, they MUST use this method. </del> <ins> sufficient, they MUST use this method.  If an endpoint does not know an IPv6 address of its peer, it can send the ICMPv6 echo request to the link local all nodes multicast address (ff02::1). </ins> If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets, and it detects that the QUIC MTU is too low to allow sending 1280
Change:
NAME as capsule type registry expert, are you OK with this text?
URL registers 3 capsules that use 0x1ECA6A00, 0x1ECA6A01, and 0x1ECA6A02. Its good practice to use the provisional registration space while developing a document, so you have my appreciation. But its not clear if you intend to change these into the permanent registration space prior to publication. CONNECT-UDP followed that approach and noted it with . Please clarify if you intend to change the values and, if so, when.
That's a good point, I was planning on changing them right after WGLC but I guess that's not written in the draft. Let's keep this issue open during the WGLC and close it once we move to the final values
Plan is to have: 0x01 for ADDRESSASSIGN 0x02 for ADDRESSREQUEST 0x03 for ROUTE_ADVERTISEMENT assuming NAME agrees since we're the two IANA experts on that registry
in principle that's fine by me. We should be wary of using them too early in case things have to change even after WGLC. So late binding once publication is impending is the least risky and works for me.
On one hand I agree with you that assigning them sooner avoids the risk of dealing with interop failures if IESG review leads to unavoidable wire-format changes. On the other, waiting until after IESG approval means that now we have interop issues between the folks that deployed before or after that - that's what we're seeing with QUIC version negotiation. So I would prefer to get provisional registrations for the low codepoints after WGLC personally
reasonable
LGTM. I was going to suggest ot would be nice to articulate the codepoint change in the changelog, but I guess you don't have one anyway...

Discussion:
11.4. <del> This document will request IANA to add the following values to the "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </del> <ins> This document requests IANA to add the following values to the "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol>>. All of these new entries use the following values for these fields: RFC Editor: please remove the rest of this subsection before publication. Since this document has not yet been published, it might still change before publication as RFC.  Any implementer that wishes to deploy IP proxying in production before publication MUST use the following temporary codepoints instead: 0x2575D601 for ADDRESS_ASSIGN, 0x2575D602 for ADDRESS_REQUEST, and 0x2575D603 for ROUTE_ADVERTISEMENT. </ins>
Change:
In the abstract, the word 'proxy' is used without qualification. It would be better to use the term 'IP proxy'. In 4.3. HTTP/1.1 Response, 'abort the connection' is not typical usage (e.g., in RFC9112); suggest 'close the connection'.

Discussion:
protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an <del> HTTP server that acts as a proxy.  This document updates RFC 9298. </del> <ins> HTTP server that acts as an IP proxy.  This document updates RFC 9298. </ins> 1.

start the Capsule Protocol; see HTTP-DGRAM. If any of these requirements are not met, the client MUST treat this <del> proxying attempt as failed and abort the connection. </del> <ins> proxying attempt as failed and close the connection. </ins> For example, the IP proxy could respond with:
Change:
NAME NAME Does this PR also ?
NAME not quite--it's a step, but there's more to do
I think the field description needs updates. The IP adress is after all an prefix that is masked by the specified number of bits. That is not quite clear yet. However, I think the question if this range should support excluding one or more sub-ranges needs to be sorted out also.
The specification of the field currently states . Is that unclear? If so, can you help provide text to help make it clearer? Agreed, that's discussed in
Editorial clarification that the prefix in the advertisement applies to the address in the advertisement, which is a remote prefix that the client is allowed to send to.

Discussion:
field has value 6, the IP Address field SHALL have a length of 128 bits. <del> Length of the IP Prefix assigned, in bits.  MUST be lesser or equal to the length of the IP Address field, in bits. </del> <ins> 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 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. </ins> 3.2.2.

the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. <del> Length of the IP Prefix of the advertised route, in bits.  MUST be lesser or equal to the length of the IP Address field, in bits. </del> <ins> The number of bits in the IP Address that are used to define the prefix of the advertised route.  This MUST be lesser or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, this route only allows sending packets to a single destination address.  If the prefix length is less than the length of the IP address, this route allows sending packets to any destination address that falls within the prefix. </ins> The Internet Protocol Number for traffic that can be sent to this prefix.  If the value is 0, all protocols are allowed.
Change:
The current version of the draft contains the ROUTEADVERTISEMENT capsule but is missing the ROUTEREJECTION capsule. It's very common for networks to want to advertise routes such as "I can handle all of IPv4 space minus RFC 1918 space" and that becomes incredibly painful if you don't have a way to subtract prefixes. An alternate solution is to use an address start/address end encoding like , but if we want to use a prefix-based encoding we need a way to cut out holes from prefixes.
Oh, is that what the rejection capsule was for? I guess I'd just rather have the route advertisement itself provide a list of exceptions, rather than tying it to a separate capsule?
Yes, that would also work. This is just a matter of encoding.
The nice thing about the rejection capsule is it allows you to remove announcements that were previous present without having to re-send a full routing table. I would prefer keeping it, as it allows for more efficient transmission of information. (I disagree it's just a matter of encoding.)
Actually sending a full routing table seems like the safer way to go. And given you don’t do that very often, I don’t think we need to worry about overhead.
I will disagree with my co-author. I think the basic case for what in most cases are the equivalent to the default route for a host on a LAN segment would be good to have in a reasonable compact form. I think the question to ask here is if we in general need a mechanism to specify an IP prefix with one or more carved out sub-prefixes. I that requirement may apply to both advertising and rejecting/removing a prefix. In the removing maybe it is possible to specify the whole prefix without carve out sub-prefixes.
Maybe call with ROUTE_WITHDRAW instead of reject
ROUTE_WITHDRAW sounds good to me.

Discussion:
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> 3.2.4. The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix.  This capsule uses a Capsule Type of 0xfff103.  Its value uses the following format: IP Version of this route withdrawal.  MUST be either 4 or 6. IP address of the withdrawn route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. The number of bits in the IP Address that are used to define the prefix of the withdrawn route.  This MUST be lesser or equal to the length of the IP Address field, in bits. The Internet Protocol Number for traffic for this route.  If the value is 0, all protocols are withdrawn for this prefix. Upon receiving the ROUTE_WITHDRAWAL capsule, an endpoint MUST stop routing IP packets in that prefix to its peer.  Note that this capsule can be reordered with DATAGRAM frames, and therefore an endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. </ins> 4. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.
Change:
We should be clear that when a proxy resolves a hostname, it SHOULD give all results back as routes to the client (unless there is some policy to restrict it). Credit to NAME for proposing this
I agree
What is a client expected to do with this information? Say I ask for the proxy to connect to URL I get back a RA that includes the result of DNS lookups for URL (maybe multiple RAs that include all the answers from A/AAAA records?). Am I supposed to assume that this is the result of the DNS lookup? How do I distinguish that from other RAs that might just advertise where I might be able send packets via the tunnel? If the purpose of this is to provide name resolution, it is probably better to include an explicit signal. It's a bit of a rathole, but a new capsule type seems fairly obvious. That leads me to ask a whole bunch of questions about whether the proxy needs to supply a DNS service, ...
Nit: there is no port number. That's the status quo in this draft for hostname targets. The implicit signal here doesn't bother me, since it's unambiguous. I'm also fine with dropping support for DNS targets, although I think it might be useful in some scenarios.
Of course. I somehow got mislead by the first example: "URL{target}/{target_port}/"
Yeah, looks like that example had a copy paste error from CONNECT-UDP. I filed
The ability to specify a host to proxy to was important in our discussions for keeping parity with other proxying methods.
Indeed, that was bad copy-pasta from me, my apologies. It's been fixed in the editor's copy.
NAME thanks!
Thanks! ... wanted to raise the issue. URL". Section 4.1 says "route(s)", implying that the proxy might choose to advertise multiple routes to the target host, presumably because DNS resolution returned multiple A/AAAA records. I see the current text as an implicit "MAY return all the IP addresses", and I'm suggesting an upgrade to SHOULD.

Discussion:
address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client. <ins> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes routes for all usable resolved addresses for the requested hostname. </ins> The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If
Change:
Edits collected while reading this draft. cc: NAME NAME
LGTM, thanks for this NAME !

Discussion:
be lesser or equal than IP Protocol of B. If the IP Version and IP Protocol of A and B are both equal, the <del> End IP Address of A MUST be strictly lesser than the Start IP </del> <ins> End IP Address of A MUST be strictly less than the Start IP </ins> Address of B. If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not

or split-tunnel. In this case, the client does not specify any scope in its request. <del> 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. </del> <ins> The server assigns the client an IPv4 address (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
Change:
Fixing some ID nits validations errors include update references from drafts to RFCs for SEMANTICS and H3 Websockets draft.

Discussion:
establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies that support CONNECT-IP SHOULD restrict its use to authenticated <del> users.  The HTTP Authorization header AUTH MAY be used to </del> <ins> users.  The HTTP Authorization header SEMANTICS MAY be used to </ins> authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using CONNECT-IP extensions.
Change:
There should be a reference providing an URL for the Assigned Internet Protocol Number registry in this document, not just the name, even if this is formally sufficient. The URL is: URL

Discussion:
11.3. This document will request IANA to add the following values to the <del> "HTTP Capsule Types" registry created by HTTP-DGRAM: </del> <ins> "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </ins>
Change:
"The ADDRESS_REQUEST capsule contains a sequence of zero or more Requested Addresses." In cases there are zero Requested Addresses what does this mean? It appears that this is an even less determined form than the all zero block , that at least indicates an address family support or preference as well as prefix length by including one or two all-zero address of the families the endpoint want assigned? Should this be explicitly stated?

Discussion:
optionally indicate a preference for which address it would get assigned. <del> The ADDRESS_REQUEST capsule contains a sequence of zero or more </del> <ins> The ADDRESS_REQUEST capsule contains a sequence of one or more </ins> Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that

requested address, and that it can also assign some requested addresses but not others. <ins> If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. </ins> 4.6.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the

End IP Address of A MUST be strictly less than the Start IP Address of B. <del> If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not </del> <ins> If an endpoint receives a ROUTE_ADVERTISEMENT capsule that does not </ins> meet these requirements, it MUST abort the IP proxying request stream.
Change:
So the description of target says: The variable "target" contains a hostname or IP prefix of a specific host to which the client wants to proxy packets. If the "target" variable is not specified or its value is "", the client is requesting to communicate with any allowable host. "target" supports using DNS names, IPv6 literals and IPv4 literals. Further down the the ABNF is stating: target = IPv6prefix / IPv4prefix / reg-name / "" IPv6prefix = IPv6address ["%2F" 13DIGIT] IPv4prefix = IPv4address ["%2F" 12DIGIT] ipproto = 13DIGIT / "" Thus, the text is inconsistent where the first indicates hostnames and prefixes. Second indicates hostnames (as DNS names) and IPv4/6 Literals, but not prefixes. Then the ABNF indicates Prefixes and reg-name. So if it is only the prefix construct and hostnames then the text about literals directly needs to be addressed. If it is hostnames, IPvX literals, and IPprefix the ABNF and description need to be addressed.
I think you misread the ABNF? It allows hostnames and IP prefixes, that's what the is for. Also those brackets indicate optionality of the prefix.
I think the ABNF is fine. It's the text that once talks about IP prefixes and once about IP literals.
Ah! Thank you, will fix via PR

Discussion:
"target" and "ipproto" variables MUST adhere to the format in target- format, using notation from ABNF.  Additionally: <del> if "target" contains an IPv6 literal, the colons (":") MUST be percent-encoded.  For example, if the target host is </del> <ins> if "target" contains an IPv6 literal or prefix, the colons (":") MUST be percent-encoded.  For example, if the target host is </ins> "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42".
Change:
That omits the HTTP/1.1 support that you have. Is that intentional?
You're right that should be fixed - the intro is correct but the abstract needs to be updated to look more like the corresponding text in the into

Discussion:
This document describes how to proxy UDP over HTTP.  Similar to how the CONNECT method allows proxying TCP over HTTP, this document <del> defines a new mechanism to proxy UDP.  It is built using HTTP Extended CONNECT. </del> <ins> defines a new mechanism to proxy UDP.  When using HTTP/2 or HTTP/3, it uses Extended CONNECT; when using HTTP/1.1, it uses Upgrade. </ins> 1.
Change:
In the notational conventions Some might argue an HTTP/3 server already opend a UDP socket :-) so you might want to tighten this a bit to say something like In this document, we use the term "proxy" to refer to the HTTP server that acts upon the client request to open a UDP socket to a target server, and generates the response to this request.

Discussion:
capitals, as shown here. In this document, we use the term "proxy" to refer to the HTTP server <del> that opens the UDP socket and responds to the UDP proxying request. If there are HTTP intermediaries (as defined in HTTP) between the client and the proxy, those are referred to as "intermediaries" in this document. </del> <ins> that acts upon the client's UDP proxying request to open a UDP socket to a target server, and generates the response to this request.  If there are HTTP intermediaries (as defined in HTTP) between the client and the proxy, those are referred to as "intermediaries" in this document. </ins> Note that, when the HTTP version in use does not support multiplexing streams (such as HTTP/1.1), any reference to "stream" in this
Change:
"A payload within a UDP proxying request message has no defined semantics; a UDP proxying request with a non-empty payload is malformed." "payload" here I assume is HTTP message content?
Already discussed in and fixed in
... or "message content" There's a lot of uses of UDP payload that do not qualify here. The one example I can see that would benefit from a change is please check if there are any other cases though.

Discussion:
encoding, so for example if the target_host is "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42". <del> A payload within a UDP proxying request message has no defined semantics; a UDP proxying request with a non-empty payload is malformed. </del> <ins> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), UDP proxying requests do not carry any message content.  Similarly, successful UDP proxying responses also do not carry any message content. </ins> Responses to UDP proxying requests are not cacheable.