jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-applicability

Commentary: This would be my proposal of a few small additions based on the discussion on list and at the last meeting ( IETF-112 ) about privacy implications after migration regarding exposure of linkable user IP addresses to the server . The text does n't give any recommendations but at least mentions it in the relevant sections . 
 I left a few suggestions , but this is heading in a good direction .
Paragraph (version A):
Use of a non-zero-length connection ID for the server is strongly
recommended if any clients are behind a NAT or could be.  A non-zero-
length connection ID is also strongly recommended when migration is
supported.
Paragraph (version B):
Use of a non-zero-length connection ID for the server is strongly
recommended if any clients are behind a NAT or could be.  A non-zero-
length connection ID is also strongly recommended when active
migration is supported.  If a connection is intentionally migrated to
new path, a new connection ID is used to minimize linkability by
network observers.  The other QUIC endpoint uses the connection ID to
link different addresses to the same connection and entity if a non-
zero-length connection ID is provided.
Paragraph (version B):
Further, migration to an new address exposes a linkage between client
addresses to the server and may expose this linkage also to the path
if the connection ID cannot be changed or flows can otherwise be
correlated.  When migration is supported, this needs to be considered
with respective to user privacy.
Draft: draft-ietf-quic-applicability

Commentary: Separates for manageability and this PR for applicability 
 I actually find this sentence weak : " Therefore it is not recommended to use different DiffServ Code Points ( DSCPs ) { { ? RFC2475 } } for ... Considering that QUIC v1 as defined has a single congestion controller and recovery handler and do n't treat different DSCP values as separate transport flows I would think that this should be stronger formulated . However , I could see that one could provide a bit more context to this DSCP and single QUIC connections vs multiple QUIC streams discussion by referencing Section 5.1 of and be explicit about the point that QUIC v1 is similar to SCTP in regards to the issues raised . 
 I think the new text do work .
Paragraph (version A):
QUIC assumes that all packets of a QUIC connection, or at least with
the same 5-tuple {dest addr, source addr, protocol, dest port, source
port}, will receive similar network treatment since feedback about
loss or delay of each packet is used as input to the congestion
controller.  Therefore, it is not recommended to use different
DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the
same connection.  If differential network treatment, e.g. by the use
of different DSCPs, is desired, multiple QUIC connections to the same
server may be used.  However, in general it is recommended to
minimize the number of QUIC connections to the same server, to avoid
increased overheads and, more importantly, competing congestion
control.
Paragraph (version B):
QUIC, as defined in RFC9000, has a single congestion controller and
recovery handler.  This design assumes that all packets of a QUIC
connection, or at least with the same 5-tuple {dest addr, source
addr, protocol, dest port, source port} that same the same DiffServ
Code Point (DSCP) RFC2475, will receive similar network treatment
since feedback about loss or delay of each packet is used as input to
the congestion controller.  Therefore, packets belonging to the same
connection should use a single DSCP.  Section 5.1 of RFC7657 provides
a discussion of DiffServ interactions with datagram transport
protocols RFC7657 (in this respect the interactions with QUIC
resemble those of SCTP).
Paragraph (version B):
When multiplexing multiple flows over a single QUIC connection, the
selected DSCP value should be the one associated with the highest
priority requested for all multiplexed flows.
Paragraph (version B):
If differential network treatment is desired, e.g., by the use of
different DSCPs, multiple QUIC connections to the same server may be
used.  However, in general it is recommended to minimize the number
of QUIC connections to the same server, to avoid increased overhead
and, more importantly, competing congestion control.
Paragraph (version B):
As in other uses of DiffServ, when a packet enters a network segment
that does not support the DSCP value, this could result in the
connection not receiving the network treatment it expects.  The DSCP
value in this packet could also be remarked as the packet travels
along the network path, changing the requested treatment.
Draft: draft-ietf-quic-manageability

Commentary: Addresses 
 ... does n't make it clear that only the Initial from the client ( and only those sent before receiving packets from the server ) contain a Destination Connection ID field that can be used to decrypt the packet . Any initial from the server , or any initial sent by a client after receiving Initial packets from the server , probably wo n't work . 
  , this is the last paragraph . Too late ? 
 More broadly , it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately . We would n't want people to bind to a 2 - tuple of CIDs and have that immediately fail . 
 I create PR based on your comment . Is that sufficient ? which section are you talking about ? 
 I think will fix comment here . 
 Much better . My comment here is mostly a nit . I think that you are implicitly talking about the first packet from the client , so maybe you can avoid using the " Client Initial " thing here ( if you are using the abstract concept you introduced ) , " client Initial " ( that is , Initial packets sent by a client ) , or anything that might be confusing .
Paragraph (version A):
When the version has been identified as QUIC version 1, the packet
type needs to be verified as an Initial packet by checking that the
third and fourth bits of the header are both set to 0.  Then the
Destination Connection ID needs to be extracted to calculate the
Initial secret using the version-specific Initial salt, as described
in Section 5.2 of QUIC-TLS.  The length of the connection ID is
indicated in the 6th byte of the header followed by the connection ID
itself.
Paragraph (version B):
When the version has been identified as QUIC version 1, the packet
type needs to be verified as an Initial packet by checking that the
third and fourth bits of the header are both set to 0.  Then the
Destination Connection ID needs to be extracted from the packet.  The
Initial secret is calculated using the version-specific Initial salt,
as described in Section 5.2 of QUIC-TLS.  The length of the
connection ID is indicated in the 6th byte of the header followed by
the connection ID itself.
Draft: draft-ietf-quic-manageability

Commentary: It could be worth noting two general further things about DSCPs : ( a ) " When multiplexing multiple flows over a QUIC connection , the DSCP value selected should be the one associated with the highest priority requested for all multiplexed flows . " ( b ) " If a packet enters a network segment that does not support the DSCP value , this could result in the connection not receiving the network treatment it expects . The DSCP value in this packet could also be remarked as the packet travels along the network path . " 
 A sample PR : " More aspects of setting DSCPs "
Paragraph (version A):
It is expected that any QoS handling in the network, e.g. based on
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost
Multi-Path (ECMP) routing, is applied on a per flow-basis (and not
per-packet) and as such that all packets belonging to the same QUIC
connection get uniform treatment.  Using ECMP to distribute packets
from a single flow across multiple network paths or any other non-
uniform treatment of packets belong to the same connection could
result in variations in order, delivery rate, and drop rate.  As
feedback about loss or delay of each packet is used as input to the
congestion controller, these variations could adversely affect
performance.
Paragraph (version A):
Depending on the loss recovery mechanism implemented, QUIC may be
more tolerant of packet re-ordering than traditional TCP traffic (see
packetnumber).  However, it cannot be known by the network which
exact recovery mechanism is used and therefore reordering tolerance
should be considered as unknown.
Paragraph (version B):
It is expected that any QoS handling in the network, e.g. based on
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost
Multi-Path (ECMP) routing, is applied on a per flow-basis (and not
per-packet) and as such that all packets belonging to the same QUIC
connection get uniform treatment.
Paragraph (version B):
Using ECMP to distribute packets from a single flow across multiple
network paths or any other non-uniform treatment of packets belong to
the same connection could result in variations in order, delivery
rate, and drop rate.  As feedback about loss or delay of each packet
is used as input to the congestion controller, these variations could
adversely affect performance.  Depending on the loss recovery
mechanism implemented, QUIC may be more tolerant of packet re-
ordering than traditional TCP traffic (see packetnumber).  However,
the recovery mechanism used by a flow cannot be known by the network
and therefore reordering tolerance should be considered as unknown.
Draft: draft-ietf-quic-manageability

Commentary: this addresses a comment from in issue 
 In the interests of timely completion of the document , will go ahead and merge this ; please open an issue if this does n't work for you :) 
 ... does n't make it clear that only the Initial from the client ( and only those sent before receiving packets from the server ) contain a Destination Connection ID field that can be used to decrypt the packet . Any initial from the server , or any initial sent by a client after receiving Initial packets from the server , probably wo n't work . 
  , this is the last paragraph . Too late ? 
 More broadly , it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately . We would n't want people to bind to a 2 - tuple of CIDs and have that immediately fail . 
 I create PR based on your comment . Is that sufficient ? which section are you talking about ? 
 I think will fix comment here .
Paragraph (version A):
The Client Completion datagram does not expose any additional
information; however, recognizing it can be used to determine that a
handshake has completed (see sec-confirm), and for three-way
handshake RTT estimation as in sec-rtt.
Paragraph (version B):
The Client Completion datagram does not expose any additional
information; however, as the destination connection ID is server-
selected, it usually is not the same ID than in the Client Initial
datagram.  Client Completion datagram can be used to determine that a
handshake has completed (see sec-confirm), and for three-way
handshake RTT estimation as in sec-rtt.
Draft: draft-ietf-quic-manageability

Commentary: NiT Fix 365 - The randomness described was a result of indiscriminate drops .
Paragraph (version A):
Further, if UDP traffic is desired to be throttled, it is recommended
to block individual QUIC flows entirely rather than dropping packets
randomly.  When the handshake is blocked, QUIC-capable applications
may failover to TCP However, blocking a random fraction of QUIC
packets across 4-tuples will allow many QUIC handshakes to complete,
preventing a TCP failover, but the connections will suffer from
severe packet loss (see also sec-filtering).  Therefore UDP
throttling should be realized by per-flow policing as opposed to per-
packet policing.  Note that this per-flow policing should be
stateless to avoid problems with stateful treatment of QUIC flows
(see sec-stateful), for example blocking a portion of the space of
values of a hash function over the addresses and ports in the UDP
datagram.  While QUIC endpoints are often able to survive address
changes, e.g. by NAT rebindings, blocking a portion of the traffic
based on 5-tuple hashing increases the risk of black-holing an active
connection when the address changes.
Paragraph (version B):
Further, if UDP traffic is desired to be throttled, it is recommended
to block individual QUIC flows entirely rather than dropping packets
indiscriminately.  When the handshake is blocked, QUIC-capable
applications may failover to TCP However, blocking a random fraction
of QUIC packets across 4-tuples will allow many QUIC handshakes to
complete, preventing a TCP failover, but resulting in connections
then suffering severe packet loss (see also sec-filtering).
Therefore UDP throttling should be realized by per-flow policing, as
opposed to per-packet policing.  Note that this per-flow policing
should be stateless to avoid problems with stateful treatment of QUIC
flows (see sec-stateful), for example blocking a portion of the space
of values of a hash function over the addresses and ports in the UDP
datagram.  While QUIC endpoints are often able to survive address
changes, e.g. by NAT rebindings, blocking a portion of the traffic
based on 5-tuple hashing increases the risk of black-holing an active
connection when the address changes.
Draft: draft-ietf-quic-manageability

Commentary: Add ref to RFC3449 rather than explain how this works . 
 The text says : “ Distinguishing ACK packets is trivial in TCP , ” arguably this is not trivial , since you need to handle data and ACKs and exclude implications of TCP options . I ’d prefer to say “ possible ” than “ trivial ” . 
 It 's more than possible , it 's easy . I do n't quite follow which TCP options you 're referring to . I can only think of SACK , which just reduces the number of them . Why is this not as trivial as " If only the ACK bit is set , and there 's no payload , it 's an ACK . " ? ( Yes , truly bidirectional flows will have payload , but then I would argue they are not simple ACK packets . ) 
 SACK adds an obvious widley deployed complication for TCP ; ECN feedback also ; some methods have simply used packet size . I know there are various forms ACK decimation / filtering / etc , some even delve into IP encaps to do this , I just do n't want to convey a message that this " trivial " to get a good solution . The key point is that QUIC does not allow any of this without keying information . 
 I see . So we need a word that says it 's a bit more complex than " trivial " , but still reasonably simple ( esp . in comparison with QUIC ) . " Possible " would work . 
 Yes , " possible " is indeed fine . Shall I make a PR ?   I 'd say yes .
Paragraph (version A):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing ACK
packets is trivial in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Paragraph (version B):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling RFC3449.  Distinguishing
ACK packets is possible in TCP, but is not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Draft: draft-ietf-quic-manageability

Commentary: This is an attempt to clearly say what the problem is with NAT state timeout and what is a recommended approach . 
 As this is advice for network operators and middlebox vendors , this reads to me as permission to use a lower timeout . I think that it still makes sense to maintain the recommendation in RFC 4787 . The advice for applications ( do n't rely on 2 minutes ) still applies , but a 2 minute recommendation is worth sticking to . 
 I thought the text is pretty clear in saying that a bit later : I would rather want to keep this part because the message really is : yes we know these too short timers are implemented for UDP but please , please use at least 2 minutes for QUIC . Maybe removing some paragraph breaks would make it clearer that these parts belong together ? Also this part got now edited quite extensively , so I rather not change it again ... 
 Each of the sentences looks fine to me , but together I also have a hard time seeing the recommendation v. current experience . Here is a proposal : . 
 This is better . With  's suggestion .
Paragraph (version A):
RFC4787 requires a timeout that is not less than 2 minutes for most
UDP traffic.  However, in practice, timers are sometimes lower, in
the range of 30 to 60 seconds.  In contrast, RFC5382 recommends a
timeout of more than 2 hours for TCP, given that TCP is a connection-
oriented protocol with well- defined closure semantics.
Paragraph (version A):
Even though QUIC has explicitly been designed to tolerate NAT
rebindings, decreasing the NAT timeout is not recommended, as it may
negatively impact application performance or incentivize endpoints to
send very frequent keep-alive packets.  Instead it is recommended,
even when lower timers are used for other UDP traffic, to use a timer
of at least two minutes for QUIC traffic.
Paragraph (version B):
RFC4787 requires a network state timeout that is not less than 2
minutes for most UDP traffic.  However, in practice, a QUIC endpoint
can experience lower timeouts, in the range of 30 to 60 seconds.
Paragraph (version B):
In contrast, RFC5382 recommends a state timeout of more than 2 hours
for TCP, given that TCP is a connection-oriented protocol with well-
defined closure semantics.  Even though QUIC has explicitly been
designed to tolerate NAT rebindings, decreasing the NAT timeout is
not recommended, as it may negatively impact application performance
or incentivize endpoints to send very frequent keep-alive packets.
Paragraph (version B):
The recommendation is therefore that, even when lower state timeouts
are used for other UDP traffic, a state timeout of at least two
minutes ought to be used for QUIC traffic.
Draft: draft-ietf-quic-manageability

Commentary: thank you for your help with this . 
 It is specifically designed to allow for multiplexing of QUIC with real - time protocols . See RFC 7983 . 
 is this issue conflating what endpoints can distinguish and what anyone else can distinguish ? I 'm guessing that 's the case , but it would be good to be clear about this , especially in the ops drafts . Again , I 'm being informed here about what issue being addressed in in MOPS should say . So thank you for opening the issue here ! 
 you are right to point that out . If we consider this about observers , then this text is probably OK . I would say that it needs qualification to be properly correct though . We might reasonably assume that the statement applies only to " a passive observer in the network " , as noted in the top of the section , but the risk that this statement be taken out of context is strong ( it 's a nice clear sound bite ) . The same section later mentions RFC 7983 . That text could also be improved in this regard .
Paragraph (version A):
The QUIC wire image is not specifically designed to be
distinguishable from other UDP traffic.
Paragraph (version B):
The QUIC wire image is not specifically designed to be
distinguishable from other UDP traffic by a passive observer in the
network.
Draft: draft-ietf-quic-manageability

Commentary: This is already set clearly enough in the previous two paragraphs .
Paragraph (version A):
Therefore, the use of address rewriting to ensure routing stability
can open QUIC up to various attacks, as it conceals client address
changes, and as such masks important signals that drive security
mechanisms.
Draft: draft-ietf-quic-manageability

Commentary: As x to y might be read to be inclusive , rather than exclusive of the end value .
Paragraph (version A):
As both the derivation of the Initial secret and the structure of the
Initial packet itself are version-specific, the first step is always
to parse the version number (second to sixth bytes of the long
header).  Note that only long header packets carry the version
number, so it is necessary to also check if the first bit of the QUIC
packet is set to 1, indicating a long header.
Paragraph (version B):
As both the derivation of the Initial secret and the structure of the
Initial packet itself are version-specific, the first step is always
to parse the version number (the second through fifth bytes of the
long header).  Note that only long header packets carry the version
number, so it is necessary to also check if the first bit of the QUIC
packet is set to 1, indicating a long header.
Draft: draft-ietf-quic-manageability

Commentary: No client currently attempts to use UDP port 443 for HTTP/3 without first having been told to do so , most often by AltSvc or HTTPS records . Technically we can also use the URL to decide to use QUIC , but that does n't currently happen . With HTTPS records , that might never be necessary . 
 This is not entirely true . As we have HTTPS records and Alternative Services , there is no case where HTTP/3 goes without a means of signaling a port number . So there is no real " default " as far as it goes . It 's just that we reserved the number and we tend to use that port number by convention . 
 For what it 's worth , and I were talking about this wrt in MOPS , so the timing of this issue in QUIC was very helpful . Thank you for that . I 'm using " by convention " , at his suggestion .
Paragraph (version A):
The only application binding defined by the IETF QUIC WG is HTTP/3
QUIC-HTTP at the time of this writing; however, many other
applications are currently being defined and deployed over QUIC, so
an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3
uses UDP port 443 by default, although URLs referring to resources
available over HTTP/3 may specify alternate port numbers.  Simple
assumptions about whether a given flow is using QUIC based upon a UDP
port number may therefore not hold; see also Section 5 of RFC7605.
Paragraph (version B):
The only application binding defined by the IETF QUIC WG is HTTP/3
QUIC-HTTP at the time of this writing; however, many other
applications are currently being defined and deployed over QUIC, so
an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3
uses UDP port 443 by convention but various methods can be used to
specify alternate port numbers.  Simple assumptions about whether a
given flow is using QUIC based upon a UDP port number may therefore
not hold; see also Section 5 of RFC7605.