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

Commentary: This claim is n't necessary , as the statement about suitability is what matters here . 
 S 7 . Claims 1 - RTT keys have forward secrecy This is only true if you only resume with PSK-(EC)DHE , but I do n't see a requirement for this . So we need to either require this or change the text . 
 This obsession with forward secrecy is a hang - up from Google QUIC . I think that we should instead say that 1 - RTT keys are derived from the completed cryptographic handshake instead .
Paragraph (version A):
every connection produces distinct and unrelated keys,
Draft: draft-ietf-quic-transport

Commentary: We were n't very concrete in saying how endpoints generate packets with CONNECTIONCLOSE , particularly those that throw away keys . We have a rather vague requirement . In short , follow the same rules we established for the handshake . Wording this as an aggregate number allows for stochastic reactions and larger CONNECTIONCLOSE frames . This way , if you get a 25 - byte packet and respond with a 200 - byte packet , you can do that , but you have to respond to 3 in 8 or fewer in that way . Note that this limit only applies if the endpoint throws away decryption keys . Endpoints with keys are n't blind amplifiers . 
 closing period ( { { draining } } ) and send a packet containing a CONNECTIONCLOSE in response to any UDP datagram that is received . However , an endpoint without the packet protection keys can not identify and discard invalid packets . To avoid creating an unwitting amplification attack , such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTIONCLOSE frame . To This seems like a pretty vague requirement for a 2119 MUST . Like , I could only send it 9999/ packets and that would be compliant . 
 I think that it would be good to follow the 3x rule here also , but that 's a non - editorial change . 
 Do folks agree the PR resolves this ? 
 I think the PR resolves this and is a sensible choice . 
 Yup , the PR resolves this . 
 OK , labelling as such .
Paragraph (version A):
An endpoint is allowed to drop the packet protection keys when
entering the closing period (draining) and send a packet containing a
CONNECTION_CLOSE in response to any UDP datagram that is received.
However, an endpoint without the packet protection keys cannot
identify and discard invalid packets.  To avoid creating an unwitting
amplification attack, such endpoints MUST reduce the frequency with
which it sends packets containing a CONNECTION_CLOSE frame.  To
minimize the state that an endpoint maintains for a closing
connection, endpoints MAY send the exact same packet.
Paragraph (version B):
An endpoint is allowed to drop the packet protection keys when
entering the closing period (draining) and send a packet containing a
CONNECTION_CLOSE in response to any UDP datagram that is received.
However, an endpoint without the packet protection keys cannot
identify and discard invalid packets.  To avoid creating an unwitting
amplification attack, such endpoints MUST limit the cumulative size
of packets containing a CONNECTION_CLOSE frame to 3 times the
cumulative size of the packets that cause those packets to be sent.
To minimize the state that an endpoint maintains for a closing
connection, endpoints MAY send the exact same packet.
Draft: draft-ietf-quic-transport

Commentary: I see a couple of places where we require that values have high entropy . For instance of the packet header . The remainder of the first byte and an arbitrary number of bytes following it that are set to unpredictable values . The last 16 bytes of the datagram contain a Stateless Reset Token . and to ensure that it is easier to receive the packet than it is to guess the value correctly . In general , this means that things contain sufficient entropy ( so , for instance , you might have a value with some fixed values and some high entropy values ) . In any case , I think the first of these should be " indistinguishable from random " and the second should be " containing at least 64 bits worth of entropy " 
 LGTM
Paragraph (version A):
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header.  The remainder of the first byte
and an arbitrary number of bytes following it that are set to
unpredictable values.  The last 16 bytes of the datagram contain a
Stateless Reset Token.
Paragraph (version B):
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header.  The remainder of the first byte
and an arbitrary number of bytes following it that are set to values
that SHOULD be indistinguishable from random.  The last 16 bytes of
the datagram contain a Stateless Reset Token.
Paragraph (version A):
A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is
sufficient to ensure that it is easier to receive the packet than it
is to guess the value correctly.
Paragraph (version B):
Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that
it is easier to receive the packet than it is to guess the value
correctly.
Draft: draft-ietf-quic-transport

Commentary: This is better defined elsewhere , but it does n't hurt to repeat it . 
 Initial or Retry packet from the server , the client populates the Destination Connection ID field with an unpredictable value . This Destination Connection ID MUST be at least 8 bytes in length . Until a packet is received from the server , the client MUST use the same Destination Connection ID value on all packets in this connection . This Destination Connection ID is used to determine packet protection keys for Initial packets . I had understood that you changed keys for the later initial packets when DCID changed . No ? 
 That is correct . I guess the confusion comes from the " This " in the last sentence . We should make clear which CID it is referring to . 
 Depends why it changed . Retry starts a new connection attempt , with a new DCID , and new Initial keys . But the Initial keys do n't change when the server 's Initial provides a new SCID .
Paragraph (version A):
When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, the client
populates the Destination Connection ID field with an unpredictable
value.  This Destination Connection ID MUST be at least 8 bytes in
length.  Until a packet is received from the server, the client MUST
use the same Destination Connection ID value on all packets in this
connection.  This Destination Connection ID is used to determine
packet protection keys for Initial packets.
Paragraph (version B):
When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, the client
populates the Destination Connection ID field with an unpredictable
value.  This Destination Connection ID MUST be at least 8 bytes in
length.  Until a packet is received from the server, the client MUST
use the same Destination Connection ID value on all packets in this
connection.
Paragraph (version B):
The Destination Connection ID field from the first Initial packet
sent by a client is used to determine packet protection keys for
Initial packets.  These keys change after receiving a Retry packet;
see Section 5.2 of QUIC-TLS.
Draft: draft-ietf-quic-transport

Commentary: This seems like another instance of deciding the scope of " context . " Is the packet that the frame arrived in part of the connection context , or is it part of looking at the bytes ? 
 Even if the packet header is part of the context , that still does n't help . The RETIRECONNECTIONID frame only carries the sequence number , not the actual connection ID . You have to access connection - level information to detect this error , which makes the FRAMEENCODINGERROR a poor choice here . 
 +1 to what says . In addition this is a " MAY send " error , therefore I do not think we need to be cautious in trying to list all the possible error codes . 
 Our principle regarding error codes states that only those errors that are detectable without accessing connection state should result in a FRAMEENCODINGERROR . Since the RETIRECONNECTIONID frame contains only the sequence number of the connection ID , but not the actual connection ID itself , this should be a different error . Looking through the list of error codes , it seems like we do n't have any more specific error code here , so this would be a PROTOCOL_VIOLATION . 
 Seems OK . 
 As the proposed PR indicates , this would be a design change . 
 Agreed , this seems OK . 
 As I noted in the PR , I agree that PROTOCOL_VIOLATION seems like a more appropriate error . In addition to point , this is a semantic error , not one of encoding ( which suggests syntactic ) . 
 It seems we have a proposed resolution , marking as such . 
 PR was less than a year ago , that 's when this error code went from PROTOCOLVIOLATION to FRAMEENCODINGERROR _ 
 I agree that this seems like a more appropriate error . In addition to 's point , I will not that this is a semantic error , not one of encoding ( which suggests syntactic).This seems like a more correct error , but I also do n't have strong opinions about it .
Paragraph (version A):
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
NOT refer to the Destination Connection ID field of the packet in
which the frame is contained.  The peer MAY treat this as a
connection error of type FRAME_ENCODING_ERROR.
Paragraph (version B):
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
NOT refer to the Destination Connection ID field of the packet in
which the frame is contained.  The peer MAY treat this as a
connection error of type PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: error of type FRAMEENCODINGERROR . What about a frame of an impermissible type for this key space ? 
 This seems to only apply to 0 - RTT , but there are lots of frames which may not appear in Initial
Paragraph (version A):
Section 4 of QUIC-TLS provides more detail about these restrictions.
Note that all frames can appear in 1-RTT packets.
Paragraph (version B):
Section 4 of QUIC-TLS provides more detail about these restrictions.
Note that all frames can appear in 1-RTT packets.  An endpoint MUST
treat receipt of a frame in a packet type that is not permitted as a
connection error of type PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: This is a left - over from removing version negotiation from the draft . 
 by a client . Receiving another Initial packet implicitly acknowledges a Version Negotiation packet . This seems like old text from when we removed real VN . I think that you just need to say that no ACK is required because you only send it in response to Initial . 
 LGTM
Paragraph (version A):
A Version Negotiation packet cannot be explicitly acknowledged in an
ACK frame by a client.  Receiving another Initial packet implicitly
acknowledges a Version Negotiation packet.
Paragraph (version B):
A Version Negotiation packet is not acknowledged.  It is only sent in
response to a packet that indicates an unsupported version; see
server-pkt-handling.
Draft: draft-ietf-quic-transport

Commentary: The text as written implied that the actual timeout period was calculated using : This is silly , as  is usually smaller than the other two values , and connections would time out too fast . Splitting the text regarding the  backstop makes this clearer . 
 Was n't the intended meaning 
 I can only speak about my intent , but I did not intend to always add  to the timeout . The text was clearly more confused than I thought . 
 I actually was n't sure what you meant before , but this is what I assumed .
Paragraph (version A):
If a max_idle_timeout is specified by either peer in its transport
parameters (transport-parameter-definitions), the connection is
silently closed and its state is discarded when it remains idle for
longer than the minimum of both peers max_idle_timeout values and
three times the current Probe Timeout (PTO).
Paragraph (version B):
If a max_idle_timeout is specified by either peer in its transport
parameters (transport-parameter-definitions), the connection is
silently closed and its state is discarded when it remains idle for
longer than the minimum of both peers max_idle_timeout values.
Paragraph (version B):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).
Draft: draft-ietf-quic-invariants

Commentary: As Magnus noted , the description of the first byte is missing , and I also noticed that the Supported Version field was described as following Version , which is wrong . 
 For  in WG LC . Section 6 has a packet header structure with the field : Unused ( 7 ) All the other fields are either fixed value or kind of defined earlier . In fact I would argue they represent concepts that are defined in -transport . Thus a second part of this is if -transport needs to be normative reference for the concepts used in this document . But back to Unused : I think this field can take any value on transmission , and should be ignored on reception . Maybe this needs to be noted explicitly in Section 6 . 
 It 's very deliberate that Invariants does not normatively depend on Transport . Invariants needs to stand alone , as a description of what versionless QUIC means . Arguably , Transport could normatively depend on Invariants , but it chooses instead to restate the things it depends on and make the reference informative .
Paragraph (version A):
The Version Negotiation packet contains a list of Supported Version
fields, each identifying a version that the endpoint sending the
packet supports.  The Supported Version fields follow the Version
field.  A Version Negotiation packet contains no other fields.  An
endpoint MUST ignore a packet that contains no Supported Version
fields, or a truncated Supported Version.
Paragraph (version B):
Only the most significant bit of the first byte of a Version
Negotiation packet has any defined value.  The remaining 7 bits,
labeled Unused, can be set to any value when sending and MUST be
ignored on receipt.
Paragraph (version B):
After the Source Connection ID field, the Version Negotiation packet
contains a list of Supported Version fields, each identifying a
version that the endpoint sending the packet supports.  A Version
Negotiation packet contains no other fields.  An endpoint MUST ignore
a packet that contains no Supported Version fields, or a truncated
Supported Version.
Draft: draft-ietf-quic-tls

Commentary: This was a little clumsy . Nothing major , it just annoyed me .
Paragraph (version A):
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
TLS13) can be used to correct a client's incorrect KeyShare extension
as well as for a stateless round-trip check.  From the perspective of
QUIC, this just looks like additional messages carried in Initial
packets.  Although it is in principle possible to use this feature
for address verification in QUIC, QUIC implementations SHOULD instead
use the Retry feature (see Section 8.1 of QUIC-TRANSPORT).
HelloRetryRequest is still used to request key shares.
Paragraph (version B):
The HelloRetryRequest message (see Section 4.1.4 of TLS13) can be
used to request that a client provide new information, such as a key
share, or to validate some characteristic of the client.  From the
perspective of QUIC, HelloRetryRequest is not differentiated from
other cryptographic handshake messages that are carried in Initial
packets.  Although it is in principle possible to use this feature
for address verification, QUIC implementations SHOULD instead use the
Retry feature; see Section 8.1 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-tls

Commentary: I came back to this today and found that the ordering was inconsistent and not sufficiently clear . Changing this so that all the actions for a single endpoint were grouped seemed to be the best arrangement . All events and actions are as close as possible in the ordering to the preceding event that caused or enabled it . The application data packets are displayed with a different marking , which helps distinguish those that carry CRYPTO frames . The final implied exchange for Get Handshake was removed . This was , I think , intended to imply something about session tickets . Without explanation , it is confusing . This does n't show HANDSHAKE_DONE , nor do I think that it should , because that is something that the transport does once it gets the Handshake Complete signal . 
 LGTM , one suggestion
Paragraph (version A):
exchange-summary summarizes the exchange between QUIC and TLS for
both client and server.  Each arrow is tagged with the encryption
level used for that transmission.
Paragraph (version A):
exchange-summary shows the multiple packets that form a single
"flight" of messages being processed individually, to show what
incoming messages trigger different actions.  New handshake messages
are requested after all incoming packets have been processed.  This
process might vary depending on how QUIC implementations and the
packets they receive are structured.
Paragraph (version B):
exchange-summary summarizes the exchange between QUIC and TLS for
both client and server.  Solid arrows indicate packets that carry
handshake data; dashed arrows show where application data can be
sent.  Each arrow is tagged with the encryption level used for that
transmission.
Paragraph (version B):
exchange-summary shows the multiple packets that form a single
"flight" of messages being processed individually, to show what
incoming messages trigger different actions.  New handshake messages
are requested after incoming packets have been processed.  This
process varies based on the structure of endpoint implementations and
the order in which packets arrive; this is intended to illustrate the
steps involved in a single handshake exchange.
Draft: draft-ietf-quic-tls

Commentary: The text here was perhaps a little unclear on this point . The point is that these do n't carry information from server to client or client to server , they carry information from server ( previous ) to server ( next ) . 
 There seems to be a conflict between this assertion in Section 9.2 : the fact that 4.8 explicitly discusses how application protocols might need to have data embedded in the session ticket . ( Also , QUIC does n't use TLS address validation tokens . ) I think this is actually trying to say that receipt of the session ticket MUST NOT cause side - effect beyond setting up the connection , but it 's a broader prohibition than that . 
 I think that it says something else , namely that these are not intended to convey semantic information from client to server ( or vice versa ) . PR inbound .
Paragraph (version A):
TLS session tickets and address validation tokens are used to
carry QUIC configuration information between connections.  These
MUST NOT be used to carry application semantics.  The potential
for reuse of these tokens means that they require stronger
protections against replay.
Paragraph (version B):
TLS session tickets and address validation tokens are used to
carry QUIC configuration information between connections.
Specifically, to enable a server to efficiently recover state that
is used in connection establishment and address validation.  These
MUST NOT be used to communicate application semantics between
endpoints; clients MUST treat them as opaque values.  The
potential for reuse of these tokens means that they require
stronger protections against replay.
Draft: draft-ietf-quic-tls

Commentary: These two statements are - to the extent that I can best determine - redundant . One is better . 
 The first two sentences of QUIC - TLS , Section 4.1.4 clearly intend to say different things , but I ca n't figure out the distinction . Is there a way we could reword them to make them clearer ? 
 I think that this is not separately at all . Let 's reduce that to a single statement .
Paragraph (version A):
As keys for new encryption levels become available, TLS provides QUIC
with those keys.  Separately, as keys at a given encryption level
become available to TLS, TLS indicates to QUIC that reading or
writing keys at that encryption level are available.  These events
are not asynchronous; they always occur immediately after TLS is
provided with new handshake bytes, or after TLS produces handshake
bytes.
Paragraph (version B):
As keys at a given encryption level become available to TLS, TLS
indicates to QUIC that reading or writing keys at that encryption
level are available.  These events are not asynchronous; they always
occur immediately after TLS is provided with new handshake bytes, or
after TLS produces handshake bytes.
Draft: draft-ietf-quic-transport

Commentary: I 'd always heard this as " Authenticated Encryption with Additional Data , " so it was -tls that sounded funny . But looking at 5116 , it 's actually " Associated " data and -tls is correct . Fixing in -transport . 
 I read this as referring to  at first .
Paragraph (version A):
All QUIC packets except Version Negotiation packets use authenticated
encryption with additional data (AEAD) RFC5116 to provide
confidentiality and integrity protection.  Retry packets use AEAD to
provide integrity protection.  Details of packet protection are found
in QUIC-TLS; this section includes an overview of the process.
Paragraph (version B):
All QUIC packets except Version Negotiation packets use authenticated
encryption with associated data (AEAD) RFC5116 to provide
confidentiality and integrity protection.  Retry packets use AEAD to
provide integrity protection.  Details of packet protection are found
in QUIC-TLS; this section includes an overview of the process.