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

Commentary: This is really about case - sensitivity . The Connection header field value is case - insensitive - The requirement is uppercase but example uses lowercase . Without citing or mentioning the case sensitivity , readers might be confused , and pedants might complain
the request SHALL include a single "Connection" header field with
value "Upgrade".
the request SHALL include a single "Connection" header field with
value "Upgrade" (note that this requirement is case-insensitive as
per HTTP).
the reponse SHALL include a single "Connection" header field with
value "Upgrade".
the reponse SHALL include a single "Connection" header field with
value "Upgrade" (note that this requirement is case-insensitive as
per HTTP).
Draft: draft-ietf-masque-connect-udp

Commentary: " 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 .
A payload within a UDP proxying request message has no defined
semantics; a UDP proxying request with a non-empty payload is
malformed.
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.
Draft: draft-ietf-masque-connect-udp

Commentary: 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 ) .
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
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.
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
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.
Draft: draft-ietf-masque-connect-udp

Commentary: 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 .
In this document, we use the term "proxy" to refer to the HTTP server
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.
In this document, we use the term "proxy" to refer to the HTTP server
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.
Draft: draft-ietf-masque-connect-udp

Commentary: 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
This document describes how to proxy UDP over HTTP.  Similar to how
the CONNECT method allows proxying TCP over HTTP, this document
defines a new mechanism to proxy UDP.  It is built using HTTP
Extended CONNECT.
This document describes how to proxy UDP over HTTP.  Similar to how
the CONNECT method allows proxying TCP over HTTP, this document
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.
Draft: draft-ietf-masque-connect-udp

Commentary: For  , should the method be " GET " or " CONNECT " ? WebSockets uses GET -- are there any uses of " Extended CONNECT " that use CONNECT rather than GET ? ( issue based on by 
 In my experience , H1.1 CONNECT for anything but it 's intended purpose of proxying will see some deployment problems . The last HTTP spec admits some origins might respect it , but I suspect many HTTP components wo n't like it . I think sticking with GET plus Upgrade header field is a good choice 
 At IETF 113 , after lengthy discussion the consensus is the room appeared to be to switch to GET so I 'm merging so we have a version of the draft ready for WGLC
the method SHALL be "CONNECT".
the method SHALL be "GET".
Draft: draft-ietf-masque-connect-udp

Commentary: . That template contains the and variables which convey the target host / port in the pseudo - header . This has the following benefits : allows custom schemes allows proxy to pick path they use However it has downsides : it requires parsing URI templates which is more of a pain than it seems it prevents reusing the same configuration between CONNECT - UDP and CONNECT - IP Alternatively , we could replace the configuration URI template with a configuration URL , and instead convey the target host / port in separate HTTP headers . This has the same benefits of the URI template without the downsides . 
 Discussed this issue at IETF 112 , consensus in the room was to keep the URI template but to tighten the template restrictions .
The URI template MUST be a level 3 template or lower.  The URI
template MUST be in absolute form, and MUST include non-empty scheme,
authority and path components.  The path component of the URI
template MUST start with a slash "/".  All template variables MUST be
within the path component of the URI.  The URI template MUST contain
the two variables "target_host" and "target_port" and MAY contain
other variables.  The URI template MUST NOT contain any non-ASCII
unicode characters and MUST only contain ASCII characters in the
range 0x21-0x7E inclusive (note that percent-encoding is allowed).
The URI template MUST NOT use Reserved Expansion ("+" operator),
Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix,
Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter
Expansion with Semicolon-Prefix.  If any of the requirements above
are not met by a URI template, the client MUST reject its
configuration and fail the request without sending it to the proxy.
Draft: draft-ietf-masque-connect-udp

Commentary: With the CONNECT UDP , a proxy will send and receive UDP datagrams on behalf of a client . However , in addition to these UDP datagrams , it could also receive ICMP messages . The current draft does not discuss how these ICMP messages should be handled by a proxy and how they would need to be conveyed to the client . It probably makes sense to at least discuss how  destination / network / port unreachable should be handled by the proxy ( ignore , terminate the HTTP connection , ... ) 
 I agree . I 'm not yet sure what the best solution is ( closing the stream on port unreachable would improve reliability but does introduce a way for an attacker to deny service ) but we should figure that out and provide guidance in the doc . 
 FWIW , the way TURN handles this is by having a way for the server to forward ICMP indications . Obviously , in order to have this in MASQUE we would need to have some sort of type indicator in the datagram . 
 I do want the relevant information in the ICMP to make it to the client . However , ICMP falls into the asynchronous information that is not directly associated with a forwarded packet . It can clearly be a forwarded packet per EKR 's suggestion . We have other cases where we have information that is related to the associated packet , for example ECN . So I think this there is an important high level design choice here that we need to sorted out . I think for the general extensibility lets consider a content identifier so that just UDP payloads can be separated from additional types with additional fields .
The lifetime of the socket is tied to the request stream.  The proxy
MUST keep the socket open while the request stream is open.  If a
proxy is notified by its operating system that its socket is no
longer usable, it MUST close the request stream.  Proxies MAY choose
to close sockets due to a period of inactivity, but they MUST close
the request stream when closing the socket.  Proxies that close
sockets after a period of inactivity SHOULD NOT use a period lower
than two minutes, see BEHAVE.
The lifetime of the socket is tied to the request stream.  The proxy
MUST keep the socket open while the request stream is open.  If a
proxy is notified by its operating system that its socket is no
longer usable (for example, this can happen when an ICMP "Destination
Unreachable" message is received, see ICMP6), it MUST close the
request stream.  Proxies MAY choose to close sockets due to a period
of inactivity, but they MUST close the request stream when closing
the socket.  Proxies that close sockets after a period of inactivity
SHOULD NOT use a period lower than two minutes, see BEHAVE.
and send an ICMP "Packet Too Big" message to the target ICMP6.
and send an ICMP "Packet Too Big" message to the target, see ICMP6.
Draft: draft-ietf-masque-connect-udp

Commentary: An application that tunnels UDP may rely on certain properties or features of the socket that the proxy creates . The draft covers some of these but does n't seem to mention the UDP fragmentation . TURN has a whole section on this QUIC , for example , requires that and recommends the Do n't Fragment ( DF ) bit MUST be set if possible . Since a proxy is agnostic to the application protocol in use ( I 'm assuming that because we do n't mention the anywhere ) perhaps CONNECT - UDP would benefit from a signal the client can send to the proxy to state it 's DF preferences . 
 This sounds like a worthwhile extension draft ? I do n't think it 's required to have a functional CONNECT - UDP protocol 
 One argument for doing it here is that one of the common uses of CONNECT - UDP will be to tunnel QUIC , and this is an obvious footgun in consideration of RFC 9000 requirements . The opposite way to solve the problem could be to add MUST / SHOULD language about proxies setting DF by default . And then require an extension to signal to disable it . But this is solutionizing a bit . Really , I want to be able to write a client that can have consistent expectations about the way datagram payload gets sent on UDP . Otherwise when things go wrong I 'm left guessing and I might not have the information that the proxy did . I could even live with text in this document that raises this as a consideration but punts on the problem . 
 Note that this is n't just about setting in IPv4 . It 's also about whether to apply sender fragmentation , in IPv6 . I would be OK with declaring that all fragmentation is off by default , and leave it to extensions to turn it on . 
 Good point  ! 
 I 'd be OK with saying proxies MUST NOT explicitly add fragmentation and SHOULD set the DF bit . We ca n't say MUST set DF because not all operating systems allow setting the DF bit on UDP sockets . 
 RFC 9000 says , not a fan ? 
 " MUST ... if possible " is the same as " SHOULD " for me , I do n't much care between them .
Proxies MUST NOT introduce fragmentation at the IP layer when
forwarding HTTP Datagrams onto a UDP socket.  In IPv4, the Don't
Fragment (DF) bit MUST be set if possible, to prevent fragmentation
on the path.  Future extensions MAY remove these requirements.
Draft: draft-ietf-masque-connect-udp

Commentary: When the client < -proxy hop is HTTP/3 , and HTTP/3 datagrams are in use , the practical limit of datagrams is the maximum size of a QUIC packet minus header overheads . When DATAGRAM capsules are used , the logical limit is increased to that of an entire data stream . For the UDP proxying use case , a proxy that converts capsules into UDP datagrams will have a practical limit to the size of UDP datagrams that it can send . And it most likely wants to avoid fragmentation . When fragmentation is to be avoided , I would expect many proxy implementations to have a practical limit of less than 2000 for the size they would be willing to send . Such proxies can drop the contents of too - large datagrams but they would be required to drain them completely in order to continue reading the data stream . This seems like a possible avenue for DoS , because a client could send a verylarge datagram in theory , it would need to buffer the entirety of the datagram before sending it . We might be tempted to try to create some way for endpoints to communicate the practical limit of datagram capsules . But that could be hard due to the end - to - end version - indendent design . Instead we might just provide some guidance that $ very_large capsules might cause problems for implementations , and that receivers might have local ( or implementation - specific ) limits that they want to enforce , which they could do by closing the stream or closing the connection . 
 According to RFC 768 , the maximum length of a UDP payload is . I would add some text to draft - ietf - masque - connect - udp along the lines of : Additionally , I think we could add some guidance text to draft - ietf - masque - h3 - datagram along the lines of : I would leave the communication of actual limits to an extension . 
 Yeah we do n't need to be 100 % prescriptive , just spelling out foothold WFM
Endpoints MUST NOT send HTTP Datagrams with payloads longer than
65527 using Context ID zero.  An endpoint that receives a DATAGRAM
capsule using Context ID zero whose payload is longer than 65527 MUST
abort the stream.  If a proxy knows it can only send out UDP packets
of a certain length due to its underlying link MTU, it SHOULD discard
incoming DATAGRAM capsules using Context ID zero whose payload is
longer than that limit without buffering the capsule contents.
Draft: draft-ietf-masque-connect-udp

Commentary: recovery ( e.g. , [ QUIC ] ) , and the underlying HTTP connection runs over TCP , the proxied traffic will incur at least two nested loss recovery mechanisms . This can reduce performance as both can sometimes independently retransmit the same data . To avoid this , HTTP/3 datagrams SHOULD be used . This text could maybe be clearer . Is it trying to say " You SHOULD use H3 + Datagram " or " You SHOULD use H3 and if you do you should use datagram " . I.e. , is it possible to use H3 but not datagram ? 
 You 're right , this is unclear . That text predates the refactor of HTTP/3 Datagram to HTTP Datagrams , so we should tweak it to say " To avoid this , UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame . "
When the protocol running over UDP that is being proxied uses loss
recovery (e.g., QUIC), and the underlying HTTP connection runs over
TCP, the proxied traffic will incur at least two nested loss recovery
mechanisms.  This can reduce performance as both can sometimes
independently retransmit the same data.  To avoid this, HTTP/3
datagrams SHOULD be used.
When the protocol running over UDP that is being proxied uses loss
recovery (e.g., QUIC), and the underlying HTTP connection runs over
TCP, the proxied traffic will incur at least two nested loss recovery
mechanisms.  This can reduce performance as both can sometimes
independently retransmit the same data.  To avoid this, UDP proxying
SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM
frame.
Draft: draft-ietf-masque-connect-udp

Commentary: For some kinds of implementations , the action of closing a QUIC stream is not immediate . Do we really want to make this ordering so strong ? There 's not really any way to enforce it . 
 That makes sense . I 'd like to keep the " MUST close the request stream " but we can remove the ordering requirement or make it a SHOULD . 
 Either of those options works for me . I can make a PR tomorrow .
The lifetime of the socket is tied to the request stream.  The proxy
MUST keep the socket open while the request stream is open.  If a
proxy is notified by its operating system that its socket is no
longer usable, it MUST close the request stream.  Proxies MAY choose
to close sockets due to a period of inactivity, but they MUST close
the request stream before closing the socket.  Proxies that close
sockets after a period of inactivity SHOULD NOT use a period lower
than two minutes, see Section 4.3 of BEHAVE.
The lifetime of the socket is tied to the request stream.  The proxy
MUST keep the socket open while the request stream is open.  If a
proxy is notified by its operating system that its socket is no
longer usable, it MUST close the request stream.  Proxies MAY choose
to close sockets due to a period of inactivity, but they MUST close
the request stream when closing the socket.  Proxies that close
sockets after a period of inactivity SHOULD NOT use a period lower
than two minutes, see Section 4.3 of BEHAVE.
Draft: draft-ietf-masque-connect-udp

Commentary: The doc has a development versioning header but it omits the ABNF . The format is described as a list of values on request headers and a single item on response headers . I 'm going to assume this is an sf - list , can we state that to avoid uncertainty ?
In order to allow implementations to support multiple draft versions
of this specification during its development, we introduce the
"connect-udp-version" header.  When sent by the client, it contains a
list of draft numbers supported by the client (e.g., "connect-udp-
version: 0, 2").  When sent by the proxy, it contains a single draft
number selected by the proxy from the list provided by the client
(e.g., "connect-udp-version: 2").  Sending this header is RECOMMENDED
but not required.
Draft: draft-ietf-masque-connect-udp

Commentary: the target has to indicate its willingness to accept TCP connections by responding with a TCP SYN - ACK before the proxy can send it application data . UDP does n't have this property , so a UDP proxy could send more data to an unwilling target than a CONNECT proxy . However , in practice denial of service attacks target open TCP ports so the TCP SYN - ACK does not offer much protection in real scenarios . Proxies MUST NOT introspect the contents of UDP payloads as that would lead to ossification of UDP - based protocols by proxies . This seems like an RFC 6919 " MUST ( but we know you wo n't ) " 
 Agreed . Are you proposing a change to the draft ? 
 Yes . I would remove the last sentence . OTOH , given that the status of proxies is still under discussion maybe we just wait on this one .
Because the CONNECT method creates a TCP connection to the target,
the target has to indicate its willingness to accept TCP connections
by responding with a TCP SYN-ACK before the proxy can send it
application data.  UDP doesn't have this property, so a UDP proxy
could send more data to an unwilling target than a CONNECT proxy.
However, in practice denial of service attacks target open TCP ports
so the TCP SYN-ACK does not offer much protection in real scenarios.
Proxies MUST NOT introspect the contents of UDP payloads as that
would lead to ossification of UDP-based protocols by proxies.
Because the CONNECT method creates a TCP connection to the target,
the target has to indicate its willingness to accept TCP connections
by responding with a TCP SYN-ACK before the proxy can send it
application data.  UDP doesn't have this property, so a UDP proxy
could send more data to an unwilling target than a CONNECT proxy.
However, in practice denial of service attacks target open TCP ports
so the TCP SYN-ACK does not offer much protection in real scenarios.
Draft: draft-ietf-masque-connect-udp

Commentary: This is one potential design for the identifier at the start of the CONNECT - UDP datagram payload . Note that this PR is against the design team consensus branch , not main . . . 
 During the HTTP Datagrams Design Team meeting on 2022 - 01 - 20 , we reached consensus to move forward with the dynamic approach , so I 'm merging this PR .
The design team meetings will continue until morale improves.
UDP packets are encoded using HTTP Datagrams with the To Be
Determined field set to TBD0.  When the To Be Determined is set to
TBD0, the Context Payload field contains the unmodified payload of a
UDP packet (referred to as "data octets" in UDP).
This protocol allows future extensions to exchange HTTP Datagrams
which carry different semantics from UDP payloads.  Some of these
extensions can augment UDP payloads with additional data, while
others can exchange data that is completely separate from UDP
payloads.  In order to accomplish this, all HTTP Datagrams associated
with UDP Proxying request streams start with a context ID, see
format.
A variable-length integer that contains the value of the Context
ID.  Endpoints MUST silently drop any received HTTP Datagram which
carries an unknown Context ID.
UDP packets are encoded using HTTP Datagrams with the Context ID set
to zero.  When the Context ID is set to zero, the Context Payload
field contains the unmodified payload of a UDP packet (referred to as
"data octets" in UDP).
Draft: draft-ietf-masque-connect-udp

Commentary: RFC 4787 ( ) does define some default timeouts for NAT bindings for UDP . Over general Internet I would not expect that UDP flow state is mainstained longer than these default values . Thus , I think it makes sense to indicate that if the MASQUE server is recovering state for inactive UDP flows , it SHOULD NOT recover them faster than the timeout recommendation in the behave UDP RFC . 
 That makes sense to me , can you send a PR ? Otherwise I 'll add it in the next batch .
The lifetime of the socket is tied to the request stream.  The proxy
MUST keep the socket open while the request stream is open.  Proxies
MAY choose to close sockets due to a period of inactivity, but they
MUST close the request stream before closing the socket.  If a proxy
is notified by its operating system that its socket is no longer
usable, it MUST close the request stream.
The lifetime of the socket is tied to the request stream.  The proxy
MUST keep the socket open while the request stream is open.  If a
proxy is notified by its operating system that its socket is no
longer usable, it MUST close the request stream.  Proxies MAY choose
to close sockets due to a period of inactivity, but they MUST close
the request stream before closing the socket.  Proxies that close
sockets after a period of inactivity SHOULD NOT use a period lower
than two minutes, see Section 4.3 of BEHAVE.