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

Commentary: It does n't matter what an Initial is coalesced with . It could be a 0 - RTT packet , it could be an ( invalid ) Handshake packet , or the bytes after the Initial packet could be completely random . The only thing that matters is that the resulting UDP datagram has at least 1200 bytes . 
 CI failure is n't my fault . The faulty commit seems to be .
Paragraph (version A):
The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by combining the Initial packet with a 0-RTT
packet (see packet-coalesce).  Sending a UDP datagram of this size
ensures that the network path supports a reasonable Maximum
Transmission Unit (MTU), and helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified
client address; see address-validation.
Paragraph (version B):
The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by coalescing the Initial packet (see packet-
coalesce).  Sending a UDP datagram of this size ensures that the
network path supports a reasonable Maximum Transmission Unit (MTU),
and helps reduce the amplitude of amplification attacks caused by
server responses toward an unverified client address; see address-
validation.
Draft: draft-ietf-quic-tls

Commentary: As of -12 , TLS records are not used in QUIC ( TLS handshake messages are directly transmitted instead ) , and therefore it is impossible in QUIC to transmit early data using the machinery provided by TLS .
Paragraph (version A):
Early data within the TLS connection MUST NOT be used.  As it is for
other TLS application data, a server MUST treat receiving early data
on the TLS connection as a connection error of type
PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: Clients are n't forbidden from sending a Handshake packet before receiving the ServerHello , they just do n't have the keys to do so . 
 LGTM
Paragraph (version A):
If the packet is a 0-RTT packet, the server MAY buffer a limited
number of these packets in anticipation of a late-arriving Initial
Packet.  Clients are forbidden from sending Handshake packets prior
to receiving a server response, so servers SHOULD ignore any such
packets.
Paragraph (version B):
If the packet is a 0-RTT packet, the server MAY buffer a limited
number of these packets in anticipation of a late-arriving Initial
packet.  Clients are not able to send Handshake packets prior to
receiving a server response, so servers SHOULD ignore any such
packets.
Draft: draft-ietf-quic-transport

Commentary: Retry always changes the connection ID . 
 The paragraph 2 before this one says exactly that . 
 Ah ... I missed that . Thanks for pointing it out
Paragraph (version A):
Receiving a Retry packet, especially a Retry that changes the
connection ID used for subsequent packets, indicates a strong
possibility that 0-RTT packets could be lost.  A client only receives
acknowledgments for its 0-RTT packets once the handshake is complete.
Consequently, a server might expect 0-RTT packets to start with a
packet number of 0.  Therefore, in determining the length of the
packet number encoding for 0-RTT packets, a client MUST assume that
all packets up to the current packet number are in flight, starting
from a packet number of 0.  Thus, 0-RTT packets could need to use a
longer packet number encoding.
Paragraph (version B):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete.  Consequently, a server might expect 0-RTT
packets to start with a packet number of 0.  Therefore, in
determining the length of the packet number encoding for 0-RTT
packets, a client MUST assume that all packets up to the current
packet number are in flight, starting from a packet number of 0.
Thus, 0-RTT packets could need to use a longer packet number
encoding.
Draft: draft-ietf-quic-transport

Commentary: The phrase , , is semantically equal to This is not correct since all streams do n't create a ( new ) stream . Moreover , by definition , a stream is created by sending data[1 ] or STREAM frames implicitly create a stream[2 ] . This indicates a stream itself does n't create another stream . [ 1 ] [ 2 ] 
 Looks good . Just a minor comment .
Paragraph (version A):
Before creating a stream, all streams of the same type with lower-
numbered stream IDs MUST be created.  This ensures that the creation
order for streams is consistent on both endpoints.
Paragraph (version B):
Before a stream is created, all streams of the same type with lower-
numbered stream IDs MUST be created.  This ensures that the creation
order for streams is consistent on both endpoints.
Draft: draft-ietf-quic-transport

Commentary: This aligns section 4.5 with section 19.11 's text : " An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted . " 
 I 'm going to recommend calling this editorial on the basis that it reconciles this text with another MUST - level requirement . But I will leave the issue open for the chairs to make a design / editorial assessment and any resulting consensus call . 
 In most places in QUIC , if an error is clearly avoidable(ie : only a buggy implementation would do so ) , then we advise closing the connection with an error , not just closing the stream with an error . In section 4.5 of transport ( ) it says : " Endpoints MUST NOT exceed the limit set by their peer . An endpoint that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAMLIMITERROR " Came up in discussion of 
 As I commented in the updated PR description , section 19.11 already says this : " An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted . " 
 Reopening to keep this visible . 
 is effectively the proposal , correct ? 
 Yes . It was editorial . So I merged it . But then this issue really is n't editorial . 
 Yes , I opened this issue , then found that text in section 19.11 in the doc said exceeding  was a connection error , so the PR ended up aligning the two sections . 
 In HTTP/3  A.4 it states : : HTTPREQUESTREJECTED ( in { { http - error - codes } } ) is used to indicate that a request was not processed . Otherwise , not applicable because QUIC handles stream management . A STREAMIDERROR at the QUIC layer is used for streams that are improperly opened . But STREAMID_ERROR was removed in transport draft 17 . 
 Since there are different error codes that the transport might use depending on error conditions ( maybe STREAMSTATEERROR or maybe STREAMLIMITERROR ) . I 'm inclined to simply omit the sentence .
Paragraph (version A):
Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
that receives a STREAM frame with a stream ID exceeding the limit it
has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR
(error-handling).
Paragraph (version B):
Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
that receives a frame with a stream ID exceeding the limit it has
sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
(error-handling).
Draft: draft-ietf-quic-tls

Commentary: I must have missed this when making the PR to remove the version negotiation text . Thanks ! 
 I was n’t aware that there was an issue . Sorry for that ! 
 No worries , thanks for doing this ! 
 We can probably remove big chunks of section " 8.1 . Protocol and Version Negotiation " since we do n't do version negotiation anymore in v1 . 
 Fixed with . Thanks
Paragraph (version A):
The QUIC version negotiation mechanism is used to negotiate the
version of QUIC that is used prior to the completion of the
handshake.  However, this packet is not authenticated, enabling an
active attacker to force a version downgrade.
Paragraph (version A):
To ensure that a QUIC version downgrade is not forced by an attacker,
version information is copied into the TLS handshake, which provides
integrity protection for the QUIC negotiation.  This does not prevent
version downgrade prior to the completion of the handshake, though it
means that a downgrade causes a handshake failure.
Draft: draft-ietf-quic-tls

Commentary: The server does n't pick a version . The server only picks the application protocol from what the client offered , and it might do that based on the QUIC version that the client picked . 
 That depends on how you read RFC 7301 , does n't it ? Section 3.1 says : I interpret " suitable " as " one of the options that the client proposed " , but unfortunately that RFC is not very specific . 
 That is confusing , but it does n't mean that the server does n't pick an ALPN . We do require that it select an ALPN value , and even if it picks one that the client does n't offer ( whether legitimate or not ) , that does n't invalidate this text . 
 No , I was suggesting restoring the sentence that was there before , but with alternate wording to address concern . Now the server MUST abort if it ca n't pick a proper combination , and the client MUST abort if the server fails to abide by that requirement . 
 I think removing the sentence entirely is the wrong approach . OK , I see now . Yes , this WFM .
Paragraph (version A):
An application-layer protocol MAY restrict the QUIC versions that it
can operate over.  Servers MUST select an application protocol
compatible with the QUIC version that the client has selected.  If
the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection.  A client
MUST abort a connection if the server picks an incompatible
combination of QUIC version and ALPN identifier.
Paragraph (version B):
An application-layer protocol MAY restrict the QUIC versions that it
can operate over.  Servers MUST select an application protocol
compatible with the QUIC version that the client has selected.  If
the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection.  A client
MUST abort a connection if the server picks an application protocol
incompatible with the protocol version being used.
Draft: draft-ietf-quic-transport

Commentary: The client only replaces a token sent in Initial packets when receiving a Retry . NEW_TOKEN is an orthogonal mechanism to provide tickets for subsequent connections , and does n't have any effect on the current connection .
Paragraph (version A):
The server uses the NEW_TOKEN frame frame-new-token to provide the
client with an address validation token that can be used to validate
future connections.  The client includes this token in Initial
packets to provide address validation in a future connection.  The
client MUST include the token in all Initial packets it sends, unless
a Retry or NEW_TOKEN frame replaces the token with a newer one.  The
client MUST NOT use the token provided in a Retry for future
connections.  Servers MAY discard any Initial packet that does not
carry the expected token.
Paragraph (version B):
The server uses the NEW_TOKEN frame frame-new-token to provide the
client with an address validation token that can be used to validate
future connections.  The client includes this token in Initial
packets to provide address validation in a future connection.  The
client MUST include the token in all Initial packets it sends, unless
a Retry replaces the token with a newer one.  The client MUST NOT use
the token provided in a Retry for future connections.  Servers MAY
discard any Initial packet that does not carry the expected token.
Draft: draft-ietf-quic-transport

Commentary: The word ' it ' was used to refer to clients .
Paragraph (version A):
Due to packet reordering or loss, clients might receive packets for a
connection that are encrypted with a key it has not yet computed.
Clients MAY drop these packets, or MAY buffer them in anticipation of
later packets that allow it to compute the key.
Paragraph (version B):
Due to packet reordering or loss, a client might receive packets for
a connection that are encrypted with a key it has not yet computed.
The client MAY drop these packets, or MAY buffer them in anticipation
of later packets that allow it to compute the key.
Draft: draft-ietf-quic-http

Commentary: Use ' on a control stream ' instead of ' on either control stream ' . This is consistent with the changes made by .
Paragraph (version A):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on either control stream, the recipient MUST
respond with a connection error (errors) of type HTTP_WRONG_STREAM.
Paragraph (version B):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type HTTP_WRONG_STREAM.
Draft: draft-ietf-quic-qpack

Commentary: In addition , remove verbiage stating that the settings values are integers , as the are integers by the definition of the SETTINGS frame . 
 Both specify the maximum value the decoder supports . The encoder is free to pick and use a smaller value . There is no reason to add artificial limits to the way an decoder is implemented . 
 This could be viewed as an alternative resolution to . 
 Also , historical note : These have maxima because settings used to be length - prefixed blobs . By defining them to be integers of a maximum size , the length could be constrained . Now that we use varints , there is a maximum structural size already .
Paragraph (version A):
An integer with a maximum value of 2^30 - 1.  The default value is
zero bytes.  See _table-dynamic for usage.  This is the equivalent
of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2.
Paragraph (version A):
An integer with a maximum value of 2^16 - 1.  The default value is
zero.  See overview-hol-avoidance.
Paragraph (version B):
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 overview-hol-avoidance.
Draft: draft-ietf-quic-tls

Commentary: draft - ietf - quic - tls currently mentions AEADAES256CCM , however there is no way to use that AEAD in TLS 1.3 - TLSAES256CCMSHA256 does not appear in the . If I understand this correctly , the presence of AEADAES256CCM in the document was an editorial oversight . 
 Thanks . This was extremely confusing : you meant CCM , but wrote GCM in tons of places .
Paragraph (version A):
Before a TLS ciphersuite can be used with QUIC, a header protection
algorithm MUST be specified for the AEAD used with that ciphersuite.
This document defines algorithms for AEAD_AES_128_GCM,
AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs
are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to
TLS selecting a ciphersuite, AES header protection is used (hp-aes),
matching the AEAD_AES_128_GCM packet protection.
Paragraph (version B):
Before a TLS ciphersuite can be used with QUIC, a header protection
algorithm MUST be specified for the AEAD used with that ciphersuite.
This document defines algorithms for AEAD_AES_128_GCM,
AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in
AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a
ciphersuite, AES header protection is used (hp-aes), matching the
AEAD_AES_128_GCM packet protection.
Paragraph (version A):
This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and
AEAD_AES_256_CCM.  AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit
AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM, and
AEAD_AES_256_CCM use 256-bit AES in ECB mode.
Paragraph (version B):
This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM.
AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in
electronic code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES
in ECB mode.
Draft: draft-ietf-quic-transport

Commentary: made a good suggestion in , which I have taken and tweaked further . It is not sufficient to discard ECN if one QUIC packet is discared , you need to discard ALL QUIC packets in the IP packet . 
 Sounds about right to me . 
 S 21.7 This could use more elaboration . As written , it seems like if you win the race ( which you might like half the time ) then you will succeed in the attack . Is that true ? 
 Yes , the winner of a race can reduce the congestion window or maybe prevent it from being reduced . 
 As I see this : QUIC receivers ignore the ECN codepoint field received in IP packets that carry duplicate QUIC packets ( see { { ecn } } ) . 
 So is this resolved or do you expect more than what  wrote ? 
 I think that I can make that call now . If there is a problem , we can open an issue .
Paragraph (version A):
An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate.  If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this
attack.  Therefore, QUIC receivers ignore ECN codepoints set in
duplicate packets (see ecn).
Paragraph (version B):
An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate.  If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this
attack.  Therefore, QUIC endpoints ignore the ECN codepoint field on
an IP packet unless at least one QUIC packet in that IP packet is
successfully processed; see ecn.
Draft: draft-ietf-quic-transport

Commentary: ekr says there used to be stateless and stateful retry , but now there is just stateless . This is the only place the phrase is used , so instead just say " retry " .
Paragraph (version A):
A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server.  It is
used by a server that wishes to perform a stateless retry (see
validate-handshake).
Paragraph (version B):
A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server.  It is
used by a server that wishes to perform a retry (see validate-
handshake).
Draft: draft-ietf-quic-transport

Commentary: Reword the text to be a bit more clear about what 's expected from a CID issuer . 
 I believe this is editorial , since it does not change any normative text . 
 This inverts the form of the recommendation , but does n't really change the design . 
 We previously had text : In adding text for the TP ( activeconnectionid_limit ) , we kept the same idea , but lost a little bit of the text : We still need the SHOULD replace used CIDs in the event that we have n't provided the peer with the maximum number of CIDs . 
 Putting together a PR for this
Paragraph (version A):
An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs.  Endpoints store received
connection IDs for future use.  An endpoint uses the
active_connection_id_limit transport parameter to advertise the
number of connection IDs it can store for future use.  An endpoint
SHOULD NOT provide more connection IDs than the peer's limit.  If an
endpoint has provided its peer with the maximum number of connection
IDs, it SHOULD only provide a new connection ID when the peer retires
one.  An endpoint MAY limit the frequency or the total number of
connection IDs issued for each connection to avoid the risk of
running out of connection IDs (see reset-token).
Paragraph (version B):
An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs.  Endpoints store received
connection IDs for future use and advertise the number of connection
IDs they are willing to store with the active_connection_id_limit
transport parameter.  An endpoint SHOULD NOT provide more connection
IDs than the peer's limit.
Paragraph (version B):
An endpoint SHOULD supply a new connection ID when it receives a
packet with a previously unused connection ID or when the peer
retires one, unless providing the new connection ID would exceed the
peer's limit.  An endpoint MAY limit the frequency or the total
number of connection IDs issued for each connection to avoid the risk
of running out of connection IDs; see reset-token.
Draft: draft-ietf-quic-http

Commentary: Until now , only bidirectional streams were specified to treat a truncated last frame on a cleanly terminated stream as an error . With this pr , the same logic applies to push streams as well . I just slightly reworded the text from the bidirectional streams section and put it into the push stream section . Not sure if this is the best solution but I 'm also not sure where to put the text if the text for both the bidirectional streams and push streams had to be combined . 
 already contains this text : That 's intended to cover any stream type with frames . Perhaps we should consolidate the language from both sections into that , possibly leaving behind cross - references . 
 I had n't seen that paragraph yet . I 'd propose to drop the text in the Bidirectional Streams section . The reasoning is that when searching for what to do when a stream is closed with a truncated frame , I found ( or rather was pointed to ) the text in the Bidirectional Streams section . After finding a paragraph like that , I did n't expect to find any other text in the rfc related to truncated frames ( which led to this pr ) . Without the text in the Bidirectional Streams section , I might have found the text in the Frame Layout section first which would have immediately answered my question . This would also consolidate errors related to frames in the HTTP Framing Layer section which seems like the first place to go looking for frame related errors . Should I make another pr ( if this sounds like a good idea ) or update this one with the proposed change ? 
 Fine to just update this one . Thanks ! 
 This is the best I could come up with . I had to relax the text from Frame Layout to allow truncated frames on abruptly closed streams . Maybe abruptly closed stream should be clarified better ( I 'm not sure if this is done elsewhere already ? ) . 
 Reworded so as to not change the original text as much . The pr now just moves the truncation section from the streams section to the frames section .
Paragraph (version A):
These streams carry frames related to the request/response (see
request-response).  When a stream terminates cleanly, if the last
frame on the stream was truncated, this MUST be treated as a
connection error (see HTTP_MALFORMED_FRAME in http-error-codes).
Streams which terminate abruptly may be reset at any point in the
frame.
Paragraph (version B):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (errors) of
type HTTP_MALFORMED_FRAME.  Streams which terminate abruptly may be
reset at any point in a frame.
Draft: draft-ietf-quic-recovery

Commentary: Otherwise it does n't get rendered correctly ( see ) . 
 Thanks for fixing this !
Paragraph (version A):
Once a later packet packet within the same packet number space has
been acknowledged, an endpoint SHOULD declare an earlier packet lost
if it was sent a threshold amount of time in the past.  To avoid
declaring packets as lost too early, this time threshold MUST be set
to at least kGranularity.  The time threshold is: ~~~ kTimeThreshold
* max(SRTT, latest_RTT, kGranularity) ~~~ If packets sent prior to
the largest acknowledged packet cannot yet be declared lost, then a
timer SHOULD be set for the remaining time.
Paragraph (version B):
If packets sent prior to the largest acknowledged packet cannot yet
be declared lost, then a timer SHOULD be set for the remaining time.