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

Commentary: Thanks everyone , this is much better . 
 From Once an ACK frame has been acknowledged , the packets it acknowledges SHOULD NOT be acknowledged again . I think that the advice here is that ranges are dropped when all ACKs for all packets in that range have been acknowledged . Or something along those lines . Maybe : Though that seems clumsy . Better words would be appreciated . 
 Maybe " Endpoints SHOULD not acknowledge packets for which it has already received acknowledgement of acknowledgements , except where this would create unnecessary gaps in the encoded ACK frame . " Not ideal , I know/ 
 I think this is connected to in an interesting way . The question that arises is if one MUST include all ACK state between highest received , and the lower PN that needs to be  ( as it is newly arrived due to reordering ) . An alternative would be to explicitly allow GAPs for packets that has been received and where the reception 's ACKs has been ACKed . But , I guess that results in interesting bookkeeping chores in the implementations . 
 Agreed the wording is too strong . Take a look at PR
Paragraph (version A):
To limit ACK Blocks to those that have not yet been received by the
sender, the receiver SHOULD track which ACK frames have been
acknowledged by its peer.  Once an ACK frame has been acknowledged,
the packets it acknowledges SHOULD NOT be acknowledged again.
Paragraph (version B):
To limit ACK Blocks to those that have not yet been received by the
sender, the receiver SHOULD track which ACK frames have been
acknowledged.  The receiver SHOULD exclude already acknowledged
packets from future ACK frames whenever these packets would
unnecessarily contribute to the ACK frame size.
Draft: draft-ietf-quic-transport

Commentary: Implementations can do this anyway , so we 're not getting much from the recommendation . And we already have good limits on what can be sent ( including PATH_RESPONSE ) in the migration section . 
 This can lead to amplification attack if not careful . 
 how can this lead to amplification ? 
 If an endpoint seeing a challenge uses the opportunity to discover if its preferred MTU is supported by padding the response ( as opposed to the challenge ) even if the challenge packet is small . Since this might fail , it like will also send a small response after a delay or after a new challenge if it does n't get an ACK before that . A defence could be to ensure that challenges are no larger than , say twice , response . 
 An endpoint may also optimistically bundle all kinds of other data in a response . Even with 1200 bytes , this can be much larger than a small challenge packet without considering PMTU discovery at all . 
 I think I raised this issue quite a while ago this is the reason the limit was introduced , although I did n't formulate the exact counter measure . 
 The counter measure we have against amplification is the initial congestion window . We wo n't send more than that . That 's higher than the x3 we have during the handshake , but I think that 's a reasonable balance , considering that the attacker in this context has to spend a considerable amount of effort . Yes , this is a policy question , but I 'm happy with it . ( Though we should probably highlight this when asking for review . ) 
 It 's pretty hard to understand what the normative force of this is , given that it does n't explain what the limit is . I think there 's actually a simple rule we should propose , which is one PATH_CHALLENGE frame per packet ( with others to be ignored ) . Given that we require duplicate suppression at the packet level , that will have an amplification factor of 1:1 , which you can get by a variety of other mechanisms . 
 The relevant existing guideline is the 3x limit we have on handshake amplification . Given that CHALLENGE / RESPONSE does n't inherently include any amplification other than what might result from different connection ID lengths on packets , I do n't think that we need to do much special . That is , the text in 9.3.1 is fine , even if the limits are different . I 'm OK with striking everything from " However " onward here .
Paragraph (version A):
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame.  However, because a PATH_CHALLENGE might be
sent from a spoofed address, an endpoint MUST limit the rate at which
it sends PATH_RESPONSE frames and MAY silently discard PATH_CHALLENGE
frames that would cause it to respond at a higher rate.
Paragraph (version B):
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame.
Draft: draft-ietf-quic-transport

Commentary: This does n't need normative text . This adds recommendation about only sending flow control frames when there are other frames to send . Though I another note about the peer being explicitly blocked , which I think is a useful transition to the next paragraph . 
 I do n't think so . Flow control credits can go out with acknowledgments . The advice is there so that you do n't have the MAX_DATA frame go out immediately , with a delayed ACK going out 20ms later . They can both go out together . 
 Bundling frames definitely makes sense , but I do n’t think we need the “ or when a peer is blocked ” part . 
 Your assertion being that a blocked peer will already have to live with being blocked for a round trip , so the gain is n't worth documenting ? 
 I ’m saying that you should n’t let your peer become blocked under normal circumstances . I just noticed that in the corner case where the peer is blocked because the application is consuming data too slowly , it actually makes sense to not bundle the flow control update . So I guess the text is fine as is . 
 The text just says that sending more packets causes more packets to be sent . That is kind of obvious . Also , sending flow control with other frames is n't working if there is n't anything to ACK or anything to send once the application gets around to drain its buffer and inform transport about more credits . 
 Looks fine , one suggestion . 
 In light of the first paragraph which says that I can do whatever I want , what is the purpose of this MAY ? It seems like you should either recommend that people do this or just remove the normative language . 
 I agree the MAY is n't doing anything here . The one thing I think should be encouraged is bundling flow control updates with other data instead of sending them in their own packets , since the frames themselves are very small . 
 It takes one RTT for the sender to learn that the receiver is blocked and to grant additional flow control credit , so this will lead to frequent stalls of the connection , if one receiver has nothing else to send .
Paragraph (version A):
A receiver MAY use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations.
Paragraph (version B):
A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations.  As an optimization,
sending frames related to flow control only when there are other
frames to send or when a peer is blocked ensures that flow control
doesn't cause extra packets to be sent.
Draft: draft-ietf-quic-transport

Commentary: How could this happen ? The recipient knows if a given tuple is unique , so it should n't issue zero - length DCIDs for that tuple . 
 Yeah , it is more like recipients MUST not issue 0 - length CID 's in that case . And MUST drop non - issued CID 's . 
 I remember why was . If you had one connection on those addresses , time passes and a NAT rebinding moves another connection to that same path , then you get problems . That a nonsensical situation and better addressed as suggested .
Paragraph (version A):
If the Destination Connection ID is zero length and the packet
matches the address/port tuple of a connection where the host did not
require connection IDs, QUIC processes the packet as part of that
connection.  Endpoints MUST drop packets with zero-length Destination
Connection ID fields if they do not correspond to a single
connection.
Paragraph (version B):
If the Destination Connection ID is zero length and the packet
matches the address/port tuple of a connection where the host did not
require connection IDs, QUIC processes the packet as part of that
connection.  Endpoints SHOULD either reject connection attempts that
use the same addresses as existing connections, or use a non-zero-
length Destination Connection ID so that packets can be correctly
attributed to connections.
Draft: draft-ietf-quic-tls

Commentary: In Section 12.3 , the transport specs says : But in both 17.2 ( Long Header ) and 17.3 ( Short Header ) , Packet Number field in the packet is noted as the following format : which suggest it is n't variable - length integers . Can we get some clarification regarding this ? Thank you ! 
 Section 17.2/17.3 is correct -- PNs are not encoded using the varint form in Sec 16 .
Paragraph (version A):
The key and IV for the packet are computed as described in
protection-keys.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 64 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.
Paragraph (version B):
The key and IV for the packet are computed as described in
protection-keys.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 62 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.
Paragraph (version A):
The packet number is an integer in the range 0 to 2^62-1.  Where
present, packet numbers are encoded as a variable-length integer (see
integer-encoding).  This number is used in determining the
cryptographic nonce for packet protection.  Each endpoint maintains a
separate packet number for sending and receiving.
Paragraph (version B):
The packet number is an integer in the range 0 to 2^62-1.  This
number is used in determining the cryptographic nonce for packet
protection.  Each endpoint maintains a separate packet number for
sending and receiving.
Paragraph (version B):
Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK
frame (frame-ack).  When present in a long or short header however,
packet numbers are reduced and encoded in 1 to 4 bytes, see packet-
encoding).
Paragraph (version A):
Packet numbers in long and short packet headers are encoded in 1 to 4
bytes.  The number of bits required to represent the packet number is
reduced by including the least significant bits of the packet number.
Paragraph (version B):
Packet numbers are integers in the range 0 to 2^62-1 (packet-
numbers).  When present in long or short packet headers, they are
encoded in 1 to 4 bytes.  The number of bits required to represent
the packet number is reduced by including the least significant bits
of the packet number.
Draft: draft-ietf-quic-recovery

Commentary: Ok , text modified .
Paragraph (version A):
Implementers MAY experiment with using other reordering thresholds,
including absolute thresholds, bearing in mind that a lower
multiplier reduces reordering resilience and increases spurious
retransmissions, and a higher multiplier increases loss detection
delay.
Paragraph (version B):
Implementations MAY experiment with absolute thresholds, thresholds
from previous connections, adaptive thresholds, or including RTT
variance.  Smaller thresholds reduce reordering resilience and
increase spurious retransmissions, and larger thresholds increases
loss detection delay.
Draft: draft-ietf-quic-transport

Commentary: Handshake and Retry have the same type number in the text ; assuming the table is correct , this aligns the text with the table .
Paragraph (version A):
A Handshake packet uses long headers with a type value of 0x3.  It is
used to carry acknowledgments and cryptographic handshake messages
from the server and client.
Paragraph (version B):
A Handshake packet uses long headers with a type value of 0x2.  It is
used to carry acknowledgments and cryptographic handshake messages
from the server and client.