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

Commentary: Instead of just an address / hostname , could we ask to open a tunnel to a prefix ? 
  , 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 does n'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 .
Paragraph (version A):
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
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
protocol, it can leverage this information to optimize its resource
allocation; for example, the server can assign the same public IP
address to two CONNECT-IP requests that are scoped to different hosts
and/or different protocols.
Paragraph (version B):
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
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
protocol, it can leverage this information to optimize its resource
allocation; for example, the server can assign the same public IP
address to two CONNECT-IP requests that are scoped to different
prefixes and/or different protocols.
Draft: draft-ietf-masque-connect-ip

Commentary: 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 do n'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 .
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-masque-connect-ip

Commentary: Edits collected while reading this draft . cc : 
 LGTM , thanks for this !
Paragraph (version A):
If the IP Version and IP Protocol of A and B are both equal, the
End IP Address of A MUST be strictly lesser than the Start IP
Address of B.
Paragraph (version B):
If the IP Version and IP Protocol of A and B are both equal, the
End IP Address of A MUST be strictly less than the Start IP
Address of B.
Paragraph (version A):
In this case, the client does not specify any scope in its request.
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.
Paragraph (version B):
In this case, the client does not specify any scope in its request.
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.
Draft: draft-age-masque-connect-ip

Commentary: 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 for proposing this 
 I agree 
 What is a client expected to do with this information ? Say I ask for the proxy to connect to I get back a RA that includes the result of DNS lookups for ( 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 does n'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 : " { 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 . 
 thanks ! 
 Thanks !
Paragraph (version A):
The variable "target" contains a hostname or IP address of a
specific host to which the client wants to proxy packets.  If the
"target" variable is not specified, the client is requesting to
communicate with any allowable host.  If the target is an IP
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.
Paragraph (version B):
The variable "target" contains a hostname or IP address of a
specific host to which the client wants to proxy packets.  If the
"target" variable is not specified, the client is requesting to
communicate with any allowable host.  If the target is an IP
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.
The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes
routes for all usable resolved addresses for the requested
hostname.
Draft: draft-age-masque-connect-ip

Commentary: The current text in this draft needs to be updated to match the changes from I 'll write up a PR once existing conflicting PRs are merged . 
 is this unblocked now ?
Paragraph (version B):
The ADDRESS_ASSIGN capsule (see iana-types for the value of the
capsule type) allows an endpoint to inform its peer that 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.
Paragraph (version B):
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.
Paragraph (version B):
The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the
capsule type) allows an endpoint to communicate to its peer that it
is willing to route traffic to a given prefix.  This indicates that
the sender has an existing route to the prefix, and 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.  Any of these
addresses can be used as the destination address on IP packets
originated by the receiver of this capsule.
Paragraph (version B):
The ROUTE_WITHDRAWAL capsule (see iana-types for the value of the
capsule type) allows an endpoint to communicate to its peer that it
is not willing to route traffic to a given prefix.
Draft: draft-age-masque-connect-ip

Commentary: Good point , . Note that I 've also an important note about how ROUTEADVERTISEMENT and ROUTEWITHDRAWAL coexist , please take a look and . 
 As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table is n'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 the capsules description needs to be explicit if multiple capsules are allowed . I think there are different considerations depending on what type of capsules are used . The authors have already discussed and concluded that multiple routeadvertisement will be needed to allow to declare reachability of multiple prefix . I don''t know if multiple addressassign capsules are allowed . Allowing multiple allows multiple address ranges to be declared . However , that results that we also get the question if one need to withdraw source address prefixes .. 
 Yes , multiple capsules of each type are allowed . It does seem useful to clarify this , and what it means to receive multiple addresses and multiple routes ( which are additive ) . can you help write this ? 
 Agreed , multiple capsules of all currently defined capsule types are allowed . For example , multiple ADDRESS_ASSIGN are needed to support a dual - stack tunnel . I 'll write a PR .
Paragraph (version B):
This document defines multiple new capsule types that allow endpoints
to exchange IP configuration information.  Both endpoints MAY send
any number of these new capsules.
Paragraph (version B):
If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the
assigned addresses or prefixes can be used.  For example, multiple
ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6
addresses.
Paragraph (version B):
If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of
the advertised routes can be used.  For example, multiple
ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both
IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL
capsules.
Paragraph (version B):
ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in
order of receipt: if a prefix is covered by multiple received
ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last
received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT
and ROUTE_WITHDRAWAL capsules for this prefix.
Draft: draft-age-masque-connect-ip

Commentary: This change adds text that addresses conveyed by  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 I 'll write up a PR once existing conflicting PRs are merged . 
 is this unblocked now ? 
 We need to clearly state that  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 
 ( 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 !
Paragraph (version A):
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.
Paragraph (version B):
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 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.
Draft: draft-age-masque-connect-ip

Commentary: 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 do n'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 do n’t do that very often , I do n’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 .
Paragraph (version B):
IP Version of this route withdrawal.  MUST be either 4 or 6.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
The Internet Protocol Number for traffic for this route.  If the
value is 0, all protocols are withdrawn for this prefix.
Paragraph (version B):
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.
Draft: draft-age-masque-connect-ip

Commentary: Does this PR also ? 
 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 .
Paragraph (version A):
Length of the IP Prefix assigned, in bits.  MUST be lesser or
equal to the length of the IP Address field, in bits.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-age-masque-connect-ip

Commentary: The draft currently mentions an " IP forwarding path " ( or elsewhere a " path for proxying IP packets " ) without defining what that term means . It 's ambiguous because " path " is a . I 'd propose we replace this use of the word " path " with the word " tunnel " which is . 
 Yes , " IP forwarding tunnel " sounds fine to me . 
 Yes tunnel is good . Or maybe association in the context of handling state st the proxy .
Paragraph (version A):
The CONNECT-IP protocol allows endpoints to set up a path for
proxying IP packets using an HTTP proxy.  This can be used for
various solutions that include general-purpose packet tunnelling,
such as for a point-to-point or point-to-network VPN, or for limited
forwarding of packets to specific hosts.
Paragraph (version B):
The CONNECT-IP protocol allows endpoints to set up a tunnel for
proxying IP packets using an HTTP proxy.  This can be used for
various solutions that include general-purpose packet tunnelling,
such as for a point-to-point or point-to-network VPN, or for limited
forwarding of packets to specific hosts.
Paragraph (version A):
Any 2xx (Successful) response indicates that the proxy is willing to
open an IP forwarding path between it and the client.  Any response
other than a successful response indicates that the tunnel has not
been formed.
Paragraph (version B):
Any 2xx (Successful) response indicates that the proxy is willing to
open an IP forwarding tunnel between it and the client.  Any response
other than a successful response indicates that the tunnel has not
been formed.
Paragraph (version A):
The lifetime of the forwarding path is tied to the CONNECT stream.
Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame,
or a QUIC RESET_STREAM frame) closes the associated forwarding path.
Paragraph (version B):
The lifetime of the forwarding tunnel is tied to the CONNECT stream.
Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame,
or a QUIC RESET_STREAM frame) closes the associated forwarding
tunnel.
Paragraph (version A):
In the other direction, when a CONNECT-IP endpoint receives an IP
packet, it checks to see if the packet matches the routes mapped for
a CONNECT-IP forwarding path, and performs the same forwarding checks
as above before transmitting the packet over HTTP Datagrams.
Paragraph (version B):
In the other direction, when a CONNECT-IP endpoint receives an IP
packet, it checks to see if the packet matches the routes mapped for
a CONNECT-IP forwarding tunnel, and performs the same forwarding
checks as above before transmitting the packet over HTTP Datagrams.
Paragraph (version A):
The following example shows an IP flow forwarding setup, where a
client requests to establish a forwarding path to target.example.com
using ICMP (IP protocol 1), and receives a single local address and
remote address it can use for transmitting packets.
Paragraph (version B):
The following example shows an IP flow forwarding setup, where a
client requests to establish a forwarding tunnel to
target.example.com using ICMP (IP protocol 1), and receives a single
local address and remote address it can use for transmitting packets.