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

Commentary: If so , do n't serialize the oldest ranges , as previously specified . 
 This is n't the right section ; Section 13.2.4 already has context for this . I 'll make a small PR . 
 In terms of which is the right section , I 'll explain my thinking . In my mind , I think of the subsequent two sections as examples of how one could limit ACK frame size , but not really required reading , because I think that 's how they were originally written ? However , there 's quite a bit of normative text in there , so maybe I have an obsolete mental model . An easy alternative to doing what 's in those sections is to set a  number of ACK ranges(ie : 3 ) , which I think should be considered acceptable , even if it might not be optimal . 
 Let 's land this and handle any redundancies in an editorial pass along with . 
 In trying to do a simple fix for , I found other irrelevant or poorly - written recommendations in how a receiver could limit ACK ranges it sends . This section needs to be rewritten . Specifically , the sentence below is a poor recommendation and contradicts earlier recommendation on acking until the ACK frame is acknowledged . The recommendation below is fine , but the rationale does not make sense : This should be a design change . 
 I 'm not in love with this ( entire ) section either , but I 'd like to better understand this issue . I agree that sentence is mis - written , though I think the intent was fine . On the rationale , can you clarify why it does not make sense ? 
 The of the Transport Draft should explain what to do when generated ACK is too large to fit in a packet : a shorter ACK frame ( instead of aborting connection or erroring out ) . generate the shorter frame , do n't include older ( smaller ) packet numbers . ( As opposed to not including newer packet numbers . ) 
 There is a good amount of existing text about what ranges to send , ie " ACK frames SHOULD always acknowledge the most recently received packets , " I think this can be solved with some editorial additions to 13.2.2 . 
 The text we already have in 13.2.4 has the right context : 
 Ok , this became a bigger fix . See and . 
 Seems fine . A few suggestions
Paragraph (version A):
ACK frames SHOULD always acknowledge the most recently received
packets, and the more out-of-order the packets are, the more
important it is to send an updated ACK frame quickly, to prevent the
peer from declaring a packet as lost and spuriously retransmitting
the frames it contains.
Paragraph (version B):
ACK frames SHOULD always acknowledge the most recently received
packets, and the more out-of-order the packets are, the more
important it is to send an updated ACK frame quickly, to prevent the
peer from declaring a packet as lost and spuriously retransmitting
the frames it contains.  An ACK frame is expected to fit within a
single QUIC packet.  If it does not, then older ranges (those with
the smallest packet numbers) are omitted.
Draft: draft-ietf-quic-transport

Commentary: states : This is an unnecessary constraint and there ’s value in not having it . A server can , for example , include multiple IP addresses for a client in a token , enabling client validation from multiple attachment points . 
 Agreed . Just to give one example , it 'd make sense for a server to issue a NEWTOKEN token containing two addresses , if the client is using one path to communicate while having another path being probed and validated . Note also that it is difficult to implement the MUST NOT that exists now . Consider the case where a client receives a NEWTOKEN frame during or after path migration . Is the client expected to bind the token to the old IP address ? Or the new address ? It is hard to tell the intention of the server . 
 I agree this seems unnecessary , given tokens can not be used multiple times . The worst case scenario is including the token increases the number of Initial packets the client needs to send to two packets from one and the token turns out not to be useful for address validation . 
 As is clear from the PR , this should be marked design .
Paragraph (version A):
A client SHOULD NOT reuse a NEW_TOKEN token for different connection
attempts.  Reusing a token allows connections to be linked by
entities on the network path; see migration-linkability.  A client
MUST NOT reuse a token if it believes that its point of network
attachment has changed since the token was last used; that is, if
there is a change in its local IP address or network interface.  A
client needs to start the connection process over if there is any
change in its local address prior to completing the handshake.
Paragraph (version B):
A client SHOULD NOT reuse a NEW_TOKEN token for different connection
attempts.  Reusing a token allows connections to be linked by
entities on the network path; see migration-linkability.
Draft: draft-ietf-quic-transport

Commentary: This builds on to address the linkability issues that it . It recommends 1/16 of network paths are disabled randomly as suggested by It also allows the determination to be made per connection ID rather than per - path ( which is more granular , but I expect it will have a nearly identical effect ) . The net effect is that 1/8 paths will not spin as originally intended . 
 The draft says : Given that each endpoint needs to decide for itself whether it is enabling spin bit , it is not exactly clear whether each endpoint SHOULD disable spin bit on at least 1/8 (= 12.5 % ) of connections , or it can assume that the other endpoint is also making a random decision to disable and disable only on 1 - sqrt(7/8 ) (= 6.5 % ) of connections . 
 as the author of this passage , I intended the latter ( assume the other side is disabling as well , so 1 - sqrt(7/8 ) ) , but the " at least " is in there since just disabling 1/8 is probably what people will do , and the result ( about 1/4 ) is " at least 1/8 " . 
 could you review ? 
 One suggestionLooks good technically . It may be slightly confusing , though , that the last sentence only talks about paths , while a sentence before talks about " paths or connection IDs " . In any case , the behavior ensures a sufficient amount of traffic without the spin bit to prevent ossification of the bit .
Paragraph (version A):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood.  The random selection
process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of network paths.  The selection
process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection.
Paragraph (version B):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, endpoints MUST disable their use of the spin bit
for a random selection of at least one in every 16 network paths, or
for one in every 16 connection IDs.  As each endpoint disables the
spin bit independently, this ensures that the spin bit signal is
disabled on approximately one in eight network paths.
Draft: draft-ietf-quic-transport

Commentary: As mentioned in .
Paragraph (version A):
A client will always know whether the server has Handshake keys (see
discard-initial), but it is possible that a server does not know
whether the client has Handshake keys.  Under these circumstances, a
server SHOULD send a CONNECTION_CLOSE frame in both Handshake and
Initial packets to ensure that at least one of them is processable by
the client.  These packets can be coalesced into a single UDP
datagram (see packet-coalesce).
Paragraph (version B):
A client will always know whether the server has Handshake keys (see
discard-initial), but it is possible that a server does not know
whether the client has Handshake keys.  Under these circumstances, a
server SHOULD send a CONNECTION_CLOSE frame in both Handshake and
Initial packets to ensure that at least one of them is processable by
the client.  Similarly, a peer might be unable to read 1-RTT packets,
so an endpoint SHOULD send CONNECTION_CLOSE in Handshake and 1-RTT
packets prior to confirming the handshake; see Section 4.1.2 of QUIC-
TLS.  These packets can be coalesced into a single UDP datagram; see
packet-coalesce.
Draft: draft-ietf-quic-transport

Commentary: An endpoint can not increase the number of packets it receives .
Paragraph (version A):
During the closing period, an endpoint that sends a CONNECTION_CLOSE
frame SHOULD respond to any incoming packet that can be decrypted
with another packet containing a CONNECTION_CLOSE frame.  Such an
endpoint SHOULD limit the number of packets it generates containing a
CONNECTION_CLOSE frame.  For instance, an endpoint could
progressively increase the number of packets that it receives before
sending additional packets or increase the time between packets.
Paragraph (version B):
During the closing period, an endpoint that sends a CONNECTION_CLOSE
frame SHOULD respond to any incoming packet that can be decrypted
with another packet containing a CONNECTION_CLOSE frame.  Such an
endpoint SHOULD limit the number of packets it generates containing a
CONNECTION_CLOSE frame.  For instance, an endpoint could wait for a
progressively increasing number of received packets or amount of time
before responding to a received packet.
Draft: draft-ietf-quic-transport

Commentary: This is already implied by the existing text , but it is n't said directly . That is , we say that the values ca n't be linkable , which is a stronger requirement . Saying that you ca n't send the same value on two connections is much clearer . 
 This text does not forbid the server from sending the same token on multiple connections . Consequently the client has a hard , or impossible , task of excluding duplicates . At least if you only read that section . Later the text says : The token MUST NOT include information that would allow it to be linked by an on - path observer to the connection on which it was issued . This suggests that the token MUST indeed be unique , but in a roundabout manner . It would be helpful to make the initial paragraph clearer by stating the that the duplicate token can only happen on the same connection and that the server MUST ensure different connections use different tokens . 
 A nit , but looks good , thanks for working patiently !
Paragraph (version A):
A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on
which it was issued, unless the values are encrypted.  For example,
it cannot include the previous connection ID or addressing
information.  Information that allows the server to distinguish
between tokens from Retry and NEW_TOKEN MAY be accessible to entities
other than the server.
Paragraph (version B):
A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on
which it was issued, unless the values are encrypted.  For example,
it cannot include the previous connection ID or addressing
information.  A server MUST ensure that every NEW_TOKEN frame it
sends is unique across all clients, with the exception of those sent
to repair losses of previously sent NEW_TOKEN frames.  Information
that allows the server to distinguish between tokens from Retry and
NEW_TOKEN MAY be accessible to entities other than the server.
Paragraph (version A):
An endpoint might receive multiple NEW_TOKEN frames that contain the
same token value.  Endpoints are responsible for discarding duplicate
values, which might be used to link connection attempts; see
validate-future.
Paragraph (version B):
An endpoint might receive multiple NEW_TOKEN frames that contain the
same token value if packets containing the frame are incorrectly
determined to be lost.  Endpoints are responsible for discarding
duplicate values, which might be used to link connection attempts;
see validate-future.
Draft: draft-ietf-quic-transport

Commentary: This wo n't necessarily prevent fragmentation from happening , but it 's the best we can do . I did n't REQUIRE dropping of fragments , because some systems do that for you , but a SHOULD seems appropriate . 
  notes correctly that fragmentation can play poorly with using IW10 . If a sender uses a large maxdatagramsize , and if the network fragments , then IW10 can result in substantially larger amplification than 10x . A simple fix here is to say that if the endpoint uses maxdatagramsize larger than 1280 bytes ( this is what the transport spec limits it to in the absence of DPLPMTUD ) , then the endpoint MUST set DF on outgoing packets . This is a problem with RFC 6928 as well , but we should be clear about it for QUIC . 
 Should n't endpoint always set DF for all QUIC packets ? TCP does so . 
 I tend to agree with Praveen here . I think this is something that 's under - specified in transport ? I believe it should be in section 14 : 
 Yeah , this is probably an issue in transport . DF seems like the obvious answer . 
 That was my first answer , but I thought that might be too intrusive . If we all agree that is a fine response , I 'm happy with that . I can write up a PR . 
 From memory , I think there was once a discussion on DF bit not being accessible in some language interfaces . As such , the formulation should perhaps be that the DF bit SHOULD be set whenever possible . Having a MUST whenever possible could be problematic because possible could involve a lot of complexity . 
 -- 
 yes , that is exactly the text I am referring to . I 'm questioning if that requirement is practically enforceable .
Paragraph (version B):
UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4,
the DF bit MUST be set to prevent fragmentation on the path.
Draft: draft-ietf-quic-transport

Commentary: The Retry packet can be discarded . 
 The Retry packet currently allows sending an empty token . The Retry token is defined as an opaque blob where " indicates that x is variable - length " , which also includes zero - length values . On the wire , an Initial packet with a zero - length token is identical to an Initial without a token . However , there 's a difference on the client side , since a client will perform at most a single Retry . 
 Tagging this editorial . This was clearly intended to be considered non - zero length .
Paragraph (version A):
Clients MUST discard Retry packets that contain an Original
Destination Connection ID field that does not match the Destination
Connection ID from its Initial packet.  This prevents an off-path
attacker from injecting a Retry packet.
Paragraph (version B):
Clients MUST discard Retry packets that contain an Original
Destination Connection ID field that does not match the Destination
Connection ID from its Initial packet.  This prevents an off-path
attacker from injecting a Retry packet.  A client MUST discard a
Retry packet with a zero-length Retry Token field.
Draft: draft-ietf-quic-tls

Commentary: Use the exact names of the registries .
Paragraph (version A):
TLS ExtensionsType Registry TLS-REGISTRIES - IANA is to register
the quic_transport_parameters extension found in quic_parameters.
The Recommended column is to be marked Yes.  The TLS 1.3 Column is
to include CH and EE.
Paragraph (version A):
QUIC Error Codes Registry QUIC-TRANSPORT - IANA is to register the
KEY_UPDATE_ERROR (0xE), as described in key-update-error.
Paragraph (version B):
TLS ExtensionType Values Registry TLS-REGISTRIES - IANA is to
register the quic_transport_parameters extension found in
quic_parameters.  The Recommended column is to be marked Yes.  The
TLS 1.3 Column is to include CH and EE.
Paragraph (version B):
QUIC Transport Error Codes Registry QUIC-TRANSPORT - IANA is to
register the KEY_UPDATE_ERROR (0xE), as described in key-update-
error.
Draft: draft-ietf-quic-qpack

Commentary: xml2rfc v3 format prohibits the use of these , which will cause problems . This makes the anchors longer , so feel free to go with something else . 
 Had to merge it , but feel free to fix anchors .
Paragraph (version A):
Like HPACK, QPACK uses two tables for associating header fields to
indices.  The static table (see _table-static) is predefined and
contains common header fields (some of them with an empty value).
The dynamic table (see _table-dynamic) is built up over the course of
the connection and can be used by the encoder to index header fields
in the encoded header lists.
Paragraph (version B):
Like HPACK, QPACK uses two tables for associating header fields to
indices.  The static table (see header-table-static) is predefined
and contains common header fields (some of them with an empty value).
The dynamic table (see header-table-dynamic) is built up over the
course of the connection and can be used by the encoder to index
header fields in the encoded header lists.
Paragraph (version A):
The default value is zero.  See _table-dynamic for usage.  This is
the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2.
Paragraph (version B):
The default value is zero.  See header-table-dynamic for usage.
This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from
HTTP/2.
Draft: draft-ietf-quic-transport

Commentary: I think this is an editorial issue .
Paragraph (version A):
When an endpoint has requested a non-zero-length connection ID, it
needs to ensure that the peer has a supply of connection IDs from
which to choose for packets sent to the endpoint.  These connection
IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame
(frame-new-connection-id).
Paragraph (version B):
When an endpoint uses a non-zero-length connection ID, it needs to
ensure that the peer has a supply of connection IDs from which to
choose for packets sent to the endpoint.  These connection IDs are
supplied by the endpoint using the NEW_CONNECTION_ID frame (frame-
new-connection-id).
Draft: draft-ietf-quic-transport

Commentary: Some definitional work for terms that were poorly used . Note that " host " in the remaining uses is strictly interpreted in the RFC 1122 sense , so I left those alone . I considered sorting the terms section differently , and might still alphabetize that , but this is n't problematic just yet . 
 The word " host " is undefined . If it is equal to " endpoint " , it should be replaced . Otherwise , " host " should " be defined in Sec 1.2 . The word " address " sometime means " IP address " and " a pair of IP address and port " in other cases . Sec 1.2 should define " address " as " a pair of IP address and port " . And " IP " should be in front of " address " which means " IP address " . 
 fixed this . 
 Thank you !
Paragraph (version B):
When used without qualification, the tuple of IP version, IP
address, UDP protocol, and UDP port number that represents one end
of a network path.
Paragraph (version A):
Hosts try to associate a packet with an existing connection.  If the
packet has a non-zero-length Destination Connection ID corresponding
to an existing connection, QUIC processes that packet accordingly.
Note that more than one connection ID can be associated with a
connection; see connection-id.
Paragraph (version A):
If the Destination Connection ID is zero length and the packet
matches the local address and port of a connection where the host
used zero-length connection IDs, QUIC processes the packet as part of
that connection.
Paragraph (version B):
Endpoints try to associate a packet with an existing connection.  If
the packet has a non-zero-length Destination Connection ID
corresponding to an existing connection, QUIC processes that packet
accordingly.  Note that more than one connection ID can be associated
with a connection; see connection-id.
Paragraph (version B):
If the Destination Connection ID is zero length and the packet
matches the local address and port of a connection where the endpoint
used zero-length connection IDs, QUIC processes the packet as part of
that connection.
Draft: draft-ietf-quic-recovery

Commentary: Rewrites an awkward sentence . From  's comments 
 Lgtm
Paragraph (version A):
A sender MAY attempt to detect suppression of reports by marking
occasional packets that they send with ECN-CE.  If a packet marked
with ECN-CE is not reported as having been marked when the packet is
acknowledged, the sender SHOULD then disable ECN for that path.
Paragraph (version B):
A sender MAY attempt to detect suppression of reports by marking
occasional packets that they send with ECN-CE.  If a packet sent with
ECN-CE is not reported as having been CE marked when the packet is
acknowledged, then the sender SHOULD disable ECN for that path.
Draft: draft-ietf-quic-recovery

Commentary: And note that 8311 is an update . 
 ( Broken out of . ) A receiver maintains a cumulative sum of It would have helped me , had this explained what was intended by “ control violations ” - I think it means to detect when the sender sends more than permitted by the flow control limit . I think the control part comes in a later sentence ? ( Is this measured against the largest advertised offset , or the current offset ? … given what is written about reducing the advertised value ? ) 
 one suggestion , but I 'm approving
Paragraph (version A):
If a path has been verified to support ECN, QUIC treats a Congestion
Experienced codepoint in the IP header as a signal of congestion.
This document specifies an endpoint's response when its peer receives
packets with the Congestion Experienced codepoint.  As discussed in
RFC8311, endpoints are permitted to experiment with other response
functions.
Paragraph (version B):
If a path has been verified to support ECN RFC3168 RFC8311, QUIC
treats a Congestion Experienced(CE) codepoint in the IP header as a
signal of congestion.  This document specifies an endpoint's response
when its peer receives packets with the Congestion Experienced
codepoint.
Draft: draft-ietf-quic-recovery

Commentary: From  's review . 
  suggested that the QUIC recovery draft should specifically recommend against packet reordering thresholds less than 3 because it will not be sufficiently tolerant of real - world reordering . Pull already created . 
 FWIW , I think this is likely design because it adds a SHOULD NOT , but it also does n't substantively change the existing recommendation .
Paragraph (version A):
The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss
detection RFC5681 RFC6675.
Paragraph (version B):
The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss
detection RFC5681 RFC6675.  Implementations SHOULD NOT use a packet
threshold less than 3, to keep in line with TCP RFC5681.