jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-masque-connect-ip

Commentary: 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 ' .
Paragraph (version A):
This document describes how to proxy IP packets in HTTP.  This
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
HTTP server that acts as a proxy.  This document updates RFC 9298.
Paragraph (version B):
This document describes how to proxy IP packets in HTTP.  This
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
HTTP server that acts as an IP proxy.  This document updates RFC
9298.
Paragraph (version A):
If any of these requirements are not met, the client MUST treat this
proxying attempt as failed and abort the connection.
Paragraph (version B):
If any of these requirements are not met, the client MUST treat this
proxying attempt as failed and close the connection.
Draft: draft-ietf-masque-connect-ip

Commentary: From . Let 's tweak that one sentence to mention the IANA registry that we 're changing .
Paragraph (version A):
This document updates CONNECT-UDP.
Paragraph (version B):
This document updates CONNECT-UDP to change the "masque" well-known
URI, see iana-uri.
Draft: draft-ietf-masque-connect-ip

Commentary:  that our section has text about how to handle IP packets that deserves its own section . Let 's split it out . 
 We should also move the following text to the new section : 
 The email response to my review linked above suggests the new section would be about performance . Performance does n't seem the right categorization .   / TTL is just a mechanical function that has to be done . the IPv6 min MTU rule is to prevent fragmentation , which was probably originally motivated by performance , but having been made a rule , it 's now an absolute functional limit . Whatever , the main point is a separate section . Thanks . 
 LGTM modulo one tweak
Paragraph (version A):
Note that the IP forwarding tunnels described in this document are
not fully featured "interfaces" in the IPv6 addressing architecture
sense IPv6-ADDR.  In particular, they do not necessarily have IPv6
link-local addresses.  Additionally, IPv6 stateless autoconfiguration
or router advertisement messages are not used in such interfaces, and
neither is neighbor discovery.
Paragraph (version A):
Implementers need to ensure that they do not forward any link-local
traffic beyond the IP proxying interface that it was received on.  IP
proxying endpoints also need to properly reply to packets destined to
link-local multicast addresses.
Paragraph (version B):
Note that the IP forwarding tunnels described in this document are
not fully featured "interfaces" in the IPv6 addressing architecture
sense IPv6-ADDR.  In particular, they do not necessarily have IPv6
link-local addresses.  Additionally, IPv6 stateless autoconfiguration
or router advertisement messages are not used in such interfaces, and
neither is neighbor discovery.  Implementers need to ensure that they
do not forward any link-local traffic beyond the IP proxying
interface that it was received on.  IP proxying endpoints also need
to properly reply to packets destined to link-local multicast
addresses.
Draft: draft-ietf-masque-connect-ip

Commentary: From 
 That 's a good clarification . I wrote it up in PR .
Paragraph (version A):
Since IP proxying endpoints often forward IP packets onwards to other
network interfaces, they need to handle errors in the forwarding
process.  For example, forwarding can fail if the endpoint does not
have a route for the destination address, or if it is configured to
reject a destination prefix by policy, or if the MTU of the outgoing
link is lower than the size of the packet to be forwarded.  In such
scenarios, IP proxying endpoints SHOULD use ICMP ICMP ICMPv6 to
signal the forwarding error to its peer.
Paragraph (version B):
Since IP proxying endpoints often forward IP packets onwards to other
network interfaces, they need to handle errors in the forwarding
process.  For example, forwarding can fail if the endpoint does not
have a route for the destination address, or if it is configured to
reject a destination prefix by policy, or if the MTU of the outgoing
link is lower than the size of the packet to be forwarded.  In such
scenarios, IP proxying endpoints SHOULD use ICMP ICMP ICMPv6 to
signal the forwarding error to its peer by generating ICMP packets
and sending them using HTTP Datagrams.
Draft: draft-ietf-masque-connect-ip

Commentary: as capsule type registry expert , are you OK with this text ? 
 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  0x02 for ADDRESSREQUEST 0x03 for ROUTE_ADVERTISEMENT assuming 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 do n't have one anyway ...
Paragraph (version B):
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>>.
Paragraph (version B):
RFC Editor: please remove the rest of this subsection before
publication.
Draft: draft-ietf-masque-connect-ip

Commentary: From   on the : 
 Connect IP follows the same . We should probably spell that out somewhere . Similarly , we should remind implementers that they may need to treat link - local differently to avoid forwarding it , and that they may need to ensure they properly handle link - local multicast . Using ULAs is deployment - specific so I do n't think anything needs to be said here : ULA is n't different from other IPv6 address blocks and we decided early on that addressing schemes are out of scope for this document Regarding RAs , I do n't think anything needs to be said in this document since some deployments might want them while others might not
Paragraph (version B):
Note that the IP forwarding tunnels described in this document are
not fully featured "interfaces" in the IPv6 addressing architecture
sense IPv6-ADDR.  In particular, they do not necessarily have IPv6
link-local addresses.  Additionally, IPv6 stateless autoconfiguration
or router advertisement messages are not used in such interfaces, and
neither is neighbor discovery.
Paragraph (version B):
Implementers need to ensure that they do not forward any link-local
traffic onto a different interface than the one it was received on.
IP proxies also need to properly reply to packets destined to link-
local multicast addresses.
Draft: draft-ietf-masque-connect-ip

Commentary: From   on the : 
 I do n't think we need to make normative changes to the protocol , but adding a note for implementers that they might want to treat extension headers differently that other IP protocols sounds like a good change .
Paragraph (version B):
Note that IP protocol numbers represent both upper layers (as defined
in IPv6, examples include TCP and UDP) and IPv6 extension headers (as
defined in IPv6, examples include Fragment and Options headers).  IP
proxies MAY reject requests to scope to protocol numbers that are
used for extension headers.  Upon receiving packets, implementations
that support scoping by IP protocol number MUST walk the chain of
extensions to find the matching IP protocol number.
Paragraph (version B):
Since there are known risks with some IPv6 extension headers (e.g.,
ROUTING-HDR), implementers need to follow the latest guidance
regarding handling of IPv6 extension headers.
Draft: draft-ietf-masque-connect-ip

Commentary: To match the abstract .
Paragraph (version B):
This document updates CONNECT-UDP.
Draft: draft-ietf-masque-connect-ip

Commentary: This is an editorial PR based on comments made by Chris Wood during his shepherd review of the document .
Paragraph (version A):
otherwise, the recipient will act as an IP proxy.  It extracts the
optional "target" and "ipproto" variables from the URI it has
reconstructed from the request headers, decodes their percent-
encoding, and establishes an IP tunnel.
Paragraph (version A):
IP proxies MUST validate whether the decoded "target" and "ipproto"
variables meet the requirements in scope.  If they do not, the IP
proxy MUST treat the request as malformed; see H2 and H3.  If the
"target" variable is a DNS name, the IP proxy MUST perform DNS
resolution before replying to the HTTP request.  If errors occur
during this process, the IP proxy MUST reject the request and SHOULD
send details using an appropriate Proxy-Status header field PROXY-
STATUS.  For example, if DNS resolution returns an error, the proxy
can use the "dns_error" Proxy Error Type from PROXY-STATUS.
Paragraph (version B):
otherwise, the recipient will act as an IP proxy.  The IP proxy
can choose to reject the IP proxying request.  Otherwise, it
extracts the optional "target" and "ipproto" variables from the
URI it has reconstructed from the request headers, decodes their
percent-encoding, and establishes an IP tunnel.
Paragraph (version B):
IP proxies MUST validate whether the decoded "target" and "ipproto"
variables meet the requirements in scope.  If they do not, the IP
proxy MUST treat the request as malformed; see H2 and H3.  If the
"target" variable is a DNS name, the IP proxy MUST perform DNS
resolution (to query the corresponding IPv4 and/or IPv6 addresses via
A and/or AAAA records) before replying to the HTTP request.  If
errors occur during this process, the IP proxy MUST reject the
request and SHOULD send details using an appropriate Proxy-Status
header field PROXY-STATUS.  For example, if DNS resolution returns an
error, the proxy can use the "dns_error" Proxy Error Type from PROXY-
STATUS.
Paragraph (version B):
The following example shows how to connect a branch office network to
a corporate network such that all machines on those networks can
communicate.  In this example, the IP proxying client is attached to
the branch office network 192.0.2.0/24, and the IP proxy is attached
to the corporate network 203.0.113.0/24.  There are legacy clients on
the branch office network that only allow maintenance request from
machines on their subnet, so the IP Proxy is provisioned with an IP
address from that subnet.
Paragraph (version B):
In this case, the client does not specify any scope in its request.
The IP proxy assigns the client an IPv4 address (203.0.113.100) and a
split-tunnel route to the corporate network (203.0.113.0/24).  The
client assigns the IP proxy an IPv4 address (192.0.2.200) and a
split-tunnel route to the branch office network (192.0.2.0/24).  This
allows hosts on both networks to communicate with each other, and
allows the IP proxy to perform maintenance on legacy hosts in the
branch office.
Draft: draft-ietf-masque-connect-ip

Commentary: Which IPv6 address is the  pinging through the tunnel ? The  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 ! 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
Paragraph (version A):
IP proxying endpoints can also send ICMPv6 echo requests with 1232
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
sufficient, they MUST use this method.
Paragraph (version B):
IP proxying endpoints can also send ICMPv6 echo requests with 1232
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
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).
Draft: draft-ietf-masque-connect-ip

Commentary: Say for example that A and B have the same IP Version and they have the same or overlapping Start IP Address / End IP Address ranges . A 's IP Protocol is zero ( the wildcard ) whereas B 's is non - zero . That causes a weird kind of overlap even though all the requirements are followed . Is it worth disallowing in the spec ? 
 Earlier in this section , the version is defined as such : I think then this is OK , since zeros are n't allowed in route advertisements . that sound OK ? 
 The IP Verson can not be zero in the ROUTEADVERTISEMENT , but the IP Protocol can : The following ROUTEADVERTISEMENT follows the requirements ( the IP Protocol of A is lower than the IP Protocol of B ) , yet there is an overlap : 
 Oh , I see , I misread . I do think that it makes sense to put the wildcard first — so 0 shows up before others . And then the more specific protocol rules can potentially have different ranges . I still think this is acceptable to leave as - is .
Paragraph (version B):
Since setting the IP protocol to zero indicates all protocols are
allowed, the requirements above make it possible for two routes to
overlap when one has IP protocol set to zero and the other set to
non-zero.  Endpoints MUST not send a ROUTE_ADVERTISEMENT capsule with
routes that overlap in such a way.  Validating this requirement is
OPTIONAL, but if an endpoint detects the violation, it MUST abort the
IP proxying request stream.
Draft: draft-ietf-masque-connect-ip

Commentary: I 'm going to guess that order is not significant . But imagine that an endpoint would only honor a request for N addresses but the requester asks for N+Y. The endpoint has to pick a subset somehow . 
 What do you mean by " is the list ... significant " ? I do n't understand the comment about subsetting either --- if you ask for N+Y addresses and get back only N , you have N usable addresses ( ranges ) 
 How does the other end decide the which N to pick ? Without declaring if the request order is significant , then there can be no expectations of behaviour and we might find interop problems if assumptions do n't align . 
 If you request , say , 4 specific addresses , and the other side can satisfy 3 of the requests because they 're still available , it will include those 3 . It 's implementation - defined it if wants to provide a 4th address that is not the one you requested , or NAK it . However at no point in time was order significant --- you asked for all of these addresses , not any of these addresses . 
 Friendly amendment : it may include those 3 . It could also choose to only assign one , or a different address entirely if the implementation was so inclined . 
 You are pedantically correct :) . I was trying to give a specific worked example . 
 This design seems reasonable . It might help to state clearly somewhere that the value of the request ID has no significance other than as a unique handle , and that the ordering of and in a single capsule has no significance . This is in contrast to the ROUTE_ADVERTISEMENT where the ordering of things is very significant . 
 That 's a good suggestion Lucas . 
 My intention when writing this was for the order in the lists to not carry semantics , and similarly for the request ID to only exist for unicity . We should spell that out clearly . One thing we could do however , is saying that request IDs in ADDRESS_REQUEST MUST be increasing , to make duplicate detection easier on the receiver . If we do it , it adds a constraint on the sender and means that the receiver will check , while if we do n't add the constraint then receivers wo n't bother to check . Any thoughts on this point ? 
 I have no strong feeling about the potential to add such rules . 
 can you propose text here ?
Paragraph (version B):
Note that the ordering of Requested Addresses does not carry any
semantics.  Similarly, the Request ID is only meant as a unique
identifier, it does not convey any priority or importance.
Draft: draft-ietf-masque-connect-ip

Commentary: I think it would be helpful to review the lifetime text in 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
Paragraph (version A):
The lifetime of the IP forwarding tunnel is tied to the IP proxying
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.
Paragraph (version B):
The lifetime of the IP forwarding tunnel is tied to the IP proxying
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.
Draft: draft-ietf-masque-connect-ip

Commentary: Where the word " lesser " is used , I think " less than " would read better . Especially in the construct " lesser or equal than " 
 SGTM
Paragraph (version A):
If the IP Version of A and B are equal, the IP Protocol of A MUST
be lesser or equal than IP Protocol of B.
Paragraph (version B):
If the IP Version of A and B are equal, the IP Protocol of A MUST
be less than or equal than IP Protocol of B.
Draft: draft-ietf-masque-connect-ip

Commentary: 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 ,  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
Paragraph (version A):
if "target" contains an IPv6 literal, the colons (":") MUST be
percent-encoded.  For example, if the target host is
"2001:db8::42", it will be encoded in the URI as
"2001%3Adb8%3A%3A42".
Paragraph (version B):
if "target" contains an IPv6 literal or prefix, the colons (":")
MUST be percent-encoded.  For example, if the target host is
"2001:db8::42", it will be encoded in the URI as
"2001%3Adb8%3A%3A42".
Draft: draft-ietf-masque-connect-ip

Commentary: Thanks !
Paragraph (version A):
If an ADDRESS_ASSIGN capsule does not contain an address that was
sent previously transmitted in another ADDRESS_ASSIGN capsule, that
indicates that the address has been removed.  An ADDRESS_ASSIGN
capsule can also be empty, that indicates that all addresses have
been removed.
Paragraph (version B):
If an ADDRESS_ASSIGN capsule does not contain an address that was
previously transmitted in another ADDRESS_ASSIGN capsule, that
indicates that the address has been removed.  An ADDRESS_ASSIGN
capsule can also be empty, indicating that all addresses have been
removed.
Draft: draft-ietf-masque-connect-ip

Commentary: " 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 ?
Paragraph (version A):
The ADDRESS_REQUEST capsule contains a sequence of zero or more
Requested Addresses.
Paragraph (version B):
The ADDRESS_REQUEST capsule contains a sequence of one or more
Requested Addresses.
Paragraph (version B):
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero
Requested Addresses, it MUST abort the IP proxying request stream.
Paragraph (version A):
If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not
meet these requirements, it MUST abort the IP proxying request
stream.
Paragraph (version B):
If an endpoint receives a ROUTE_ADVERTISEMENT capsule that does not
meet these requirements, it MUST abort the IP proxying request
stream.
Draft: draft-ietf-masque-connect-ip

Commentary: Fixing some ID nits validations errors include update references from drafts to RFCs for SEMANTICS and   draft .
Paragraph (version A):
There are significant risks in allowing arbitrary clients to
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
users.  The HTTP Authorization header AUTH MAY be used to
authenticate clients.  More complex authentication schemes are out of
scope for this document but can be implemented using CONNECT-IP
extensions.
Paragraph (version B):
There are significant risks in allowing arbitrary clients to
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
users.  The HTTP Authorization header SEMANTICS MAY be used to
authenticate clients.  More complex authentication schemes are out of
scope for this document but can be implemented using CONNECT-IP
extensions.