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

Commentary: This moves text from the section on 0 - RTT to the section on continuing after Retry . Though 0 - RTT is the only thing that is seriously affected in the current design , Initial packets might also be affected if we ever wanted to protect those with anything other than a static key . 
 3 says that after receiving a Retry , clients MUST NOT reset the packet number for any packet number space , and references 17.2.3 for more info . However , 17.2.3 only explains why this is the case for 0 - RTT packets . We should either narrow the prohibition or expand the explanation . 
 Or maybe move the explanation that currently exists 17.2.3 to 17.2.5.3 and use it as an example ( to avoid it being read as the only reason ) . 
 does editorial change address your issue ? 
 Yes , this is fine .
Paragraph (version A):
After a client receives a Retry packet, 0-RTT packets are likely to
have been lost or discarded by the server.  A client SHOULD attempt
to resend data in 0-RTT packets after it sends a new Initial packet.
Paragraph (version A):
A client MUST NOT reset the packet number it uses for 0-RTT packets,
since the keys used to protect 0-RTT packets will not change as a
result of responding to a Retry packet.  Sending packets with the
same packet number in that case is likely to compromise the packet
protection for all 0-RTT packets because the same key and nonce could
be used to protect different content.
Paragraph (version B):
After a client receives a Retry packet, 0-RTT packets are likely to
have been lost or discarded by the server.  A client SHOULD attempt
to resend data in 0-RTT packets after it sends a new Initial packet.
New packet numbers MUST be used for any new packets that are sent; as
described in retry-continue, reusing packet numbers could compromise
packet protection.
Paragraph (version A):
A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet; packet-0rtt contains more
information on this.
Paragraph (version B):
A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet.  In particular, 0-RTT packets
contain confidential information that will most likely be
retransmitted on receiving a Retry packet.  The keys used to protect
these new 0-RTT packets will not change as a result of responding to
a Retry packet.  However, the data sent in these packets could be
different than what was sent earlier.  Sending these new packets with
the same packet number is likely to compromise the packet protection
for those packets because the same key and nonce could be used to
protect different content.
Draft: draft-ietf-quic-transport

Commentary: In early versions of path validation , there was a requirement that PATH_CHALLENGE be sent on the same path . This is , for various reasons , either unnecessary or harmful , so we no longer have that requirement . But there was some residual text that assumed that property . This removes a paragraph citing symmetry directly , and rewords text that assumes return reachability - a property that QUIC no longer provides mechanisms for . 
 In , we removed the requirement that PATHRESPONSE be sent / received on the same path that PATHCHALLENGE was sent . However , there is still text in the document that relies on this assumption . In 8.5 , it explains that receipt of the PATHRESPONSE on another interface does n't cause validation to fail , because " It is possible that a valid PATHRESPONSE might be received in the future . " But receipt of the PATHRESPONSE , over any interface is valid , and causes the validation to succeed . In 9.2 , it suggests using path validation to demonstrate return reachability , but since PATHRESPONSE need not be sent on the same path , path validation does n't demonstrate that . 
 Note that sending the response on the old path can lead to failures in " break before make " scenarios . Shall we mention that ?
Paragraph (version A):
Note that receipt on a different local address does not result in
path validation failure, as it might be a result of a forwarded
packet (see off-path-forward) or misrouting.  It is possible that a
valid PATH_RESPONSE might be received in the future.
Paragraph (version A):
Receiving acknowledgments for data sent on the new path serves as
proof of the peer's reachability from the new address.  Note that
since acknowledgments may be received on any path, return
reachability on the new path is not established.  To establish return
reachability on the new path, an endpoint MAY concurrently initiate
path validation migrate-validate on the new path or it MAY choose to
wait for the peer to send the next non-probing frame to its new
address.
Paragraph (version B):
Receiving acknowledgments for data sent on the new path serves as
proof of the peer's reachability from the new address.  Note that
since acknowledgments may be received on any path, return
reachability on the new path is not established.  No method is
provided to establish return reachability, as endpoints independently
determine reachability on each direction of a path.  To establish
reachability on the new path, an endpoint MAY concurrently initiate
path validation migrate-validate on the new path.  An endpoint MAY
defer path validation until after a peer sends the next non-probing
frame to its new address.
Draft: draft-ietf-quic-transport

Commentary: In section 18.2 , the definition of preferred_address says : In section 1.3 , we say : The prose does not define the sequence of fields in this transport parameter . 
 Thanks for catching that I was looking at the wrong TP definition and knowing what I meant . Eyes glaze over indeed !
Paragraph (version A):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  The format of this transport parameter is
shown in fig-preferred-address.  This transport parameter is only
sent by a server.  Servers MAY choose to only send a preferred
address of one address family by sending an all-zero address and
port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are
encoded in network byte order.
Paragraph (version B):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  This transport parameter is only sent by a
server.  Servers MAY choose to only send a preferred address of
one address family by sending an all-zero address and port
(0.0.0.0:0 or ::.0) for the other family.  IP addresses are
encoded in network byte order.
Paragraph (version B):
The preferred_address transport parameter contains an address and
port for both IP version 4 and 6.  The four-byte IPv4 Address
field is followed by the associated two-byte IPv4 Port field.
This is followed by a 16-byte IPv6 Address field and two-byte IPv6
Port field.  After address and port pairs, a Connection ID Length
field describes the length of the following Connection ID field.
Finally, a 16-byte Stateless Reset Token field includes the
stateless reset token associated with the connection ID.  The
format of this transport parameter is shown in fig-preferred-
address.
Draft: draft-ietf-quic-transport

Commentary: Thanks to Lucas for finding the study . Note that I found at least one middlebox with a default timeout of 30s ; that was not a home gateway included in this study . 
 2 says that " experience shows " you should send packets every 15 - 30 seconds , RFC4787 notwithstanding . Ideally , we would have a source that we could reference for this " experience . " 
 Maybe see 
 I 'm going to say that while the 15s floor is a good requirement , I do n't want to cite RFC 8085 for this gem , which I think is straight - up misinformation : " NATs require a state timeout of 2 minutes or longer [ RFC4787 ] . " We do cite RFC 8085 elsewhere and that 's fine , but the fact here is that the IETF has requested that NATs provide a state timeout of 2 minutes . That does not mean that they do . 
 I have seen anecdata as well that showing 30 seconds is an important threshold . I think the ref we now have is good .
Paragraph (version A):
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter; see termination.  However, state in middleboxes
might time out earlier than that.  Though REQ-5 in RFC4787 recommends
a 2 minute timeout interval, experience shows that sending packets
every 15 to 30 seconds is necessary to prevent the majority of
middleboxes from losing state for UDP flows.
Paragraph (version B):
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter; see termination.  However, state in middleboxes
might time out earlier than that.  Though REQ-5 in RFC4787 recommends
a 2 minute timeout interval, experience shows that sending packets
every 30 seconds is necessary to prevent the majority of middleboxes
from losing state for UDP flows GATEWAY.
Draft: draft-ietf-quic-transport

Commentary: We 've been pretty disciplined about using " connection ID " , except for the text on flow labels and one mention in the diagram for preferred_address . Of course , the mentions in the flow label text were specifically for the " Destination Connection ID field " , so that is what I used there . 
 " Use of IPv6 Flow - Label and Migration " and the definition of " preferred_address " both reference " CID " without that abbreviation of Connection ID having been defined elsewhere . It 's pretty obvious , but the text for IPv6 should probably just write out connection ID in long form .
Paragraph (version A):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
destination CID.  The flow label generation MUST be designed to
minimize the chances of linkability with a previously used flow
label, as this would enable correlating activity on multiple paths;
see migration-linkability.
Paragraph (version A):
A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses,
source and destination UDP ports, destination CID, and a local
secret.
Paragraph (version B):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
Destination Connection ID field.  The flow label generation MUST be
designed to minimize the chances of linkability with a previously
used flow label, as this would enable correlating activity on
multiple paths; see migration-linkability.
Paragraph (version B):
A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses,
source and destination UDP ports, Destination Connection ID field,
and a local secret.
Draft: draft-ietf-quic-http

Commentary: raised the point that the following text might be misleading , since  allows pipelining : " HTTP/1.1 [ HTTP11 ] is a TCP mapping which uses whitespace - delimited text fields to convey HTTP messages . While these exchanges are human - readable , using whitespace for message formatting leads to parsing complexity and motivates tolerance of variant behavior . Because each connection can transfer only a single HTTP request or response at a time in each direction , multiple parallel TCP connections are often used , reducing the ability of the congestion controller to effectively manage traffic between endpoints . " suggested the following text instead : " Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1 , multiple parallel connections are often used ... " suggested the following text instead : " Because HTTP/1.x does not include a multiplexing layer , multiple TCP connections are often used to service requests in parallel . However , that has a negative impact on congestion control and network efficiency , since TCP does not share congestion control across multiple connections . " 
  's works for me .
Paragraph (version A):
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text
fields to convey HTTP messages.  While these exchanges are human-
readable, using whitespace for message formatting leads to parsing
complexity and motivates tolerance of variant behavior.  Because each
connection can transfer only a single HTTP request or response at a
time in each direction, multiple parallel TCP connections are often
used, reducing the ability of the congestion controller to
effectively manage traffic between endpoints.
Paragraph (version B):
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text
fields to convey HTTP messages.  While these exchanges are human-
readable, using whitespace for message formatting leads to parsing
complexity and motivates tolerance of variant behavior.  Because
HTTP/1.x does not include a multiplexing layer, multiple TCP
connections are often used to service requests in parallel.  However,
that has a negative impact on congestion control and network
efficiency, since TCP does not share congestion control across
multiple connections.
Draft: draft-ietf-quic-invariants

Commentary: Or MAY , but let 's leave this probabilistic , because in practice there is no uncertainty : packets are protected . I 've changed the header of the section because it is n't just about the header : the subsections are about the specific headers , but this one is about packets as a whole .
Paragraph (version B):
QUIC packets might be integrity protected, including the header.
However, QUIC Version Negotiation packets are not integrity
protected; see vn.
Paragraph (version A):
QUIC versions are identified with a 32-bit integer, encoded in
network byte order.  Version 0 is reserved for version negotiation
(see version-negotiation).  All other version numbers are potentially
valid.
Paragraph (version B):
QUIC versions are identified with a 32-bit integer, encoded in
network byte order.  Version 0 is reserved for version negotiation
(see vn).  All other version numbers are potentially valid.
Draft: draft-ietf-quic-tls

Commentary: The text implied the opposite .
Paragraph (version A):
Each encryption level is associated with a different sequence of
bytes, which is reliably transmitted to the peer in CRYPTO frames.
When TLS provides handshake bytes to be sent, they are appended to
the handshake bytes for the current encryption level.  Any packet
that includes the CRYPTO frame is protected using keys from the
corresponding encryption level.
Paragraph (version B):
Each encryption level is associated with a different sequence of
bytes, which is reliably transmitted to the peer in CRYPTO frames.
When TLS provides handshake bytes to be sent, they are appended to
the handshake bytes for the current encryption level.  The encryption
level then determines the type of packet that the resulting CRYPTO
frame is carried in; see packet-types-keys.
Draft: draft-ietf-quic-transport

Commentary: After considering this a little more it seems helpful to bring some of the special handling rules up into the summary . We do n't really give up - front treatment of ack - eliciting , probing , and other important distinctions , so an extra column seemed useful . A table of this size just fits in the text format . 
 I had almost exactly those changes in a previous version . It was a near thing . 
 That is super helpful , and is the direction I was hoping for ! 
 In Section Frame Types and Formats , there is a very useful summary of frame types by packet type . As a person with a CC and transport protocol interest , it would be really nice to have had a summary table of key properties that included whether each frame type is ack - eliciting ; whether transmission is controlled by flow - control ; and whether transmission is controlled by congestion - control . Is there any chance we can add an extra column say to this table ? 
 The problem with the table is that it is already essentially the full width available to us . That makes the addition of more information quite difficult . The rules for most of these are simple enough that I 'm not sure that the table is the best way to present it . That is : ack - eliciting : all except ACK , PADDING congestion - controlled : all except ACK flow controlled : only STREAM 
 I would n't want to mess - up the table format to include the info . However , it would be really nice to have the info in a compact way close to the table somehow so that readers quickly confirm this . Would a note below the table possibly work , saying just this ?
Paragraph (version B):
Packets containing only frames with this marking are not ack-
eliciting; see generating-acks.
Paragraph (version B):
Packets containing only frames with this marking do not count
toward bytes in flight for congestion control purposes; see QUIC-
RECOVERY.
Paragraph (version B):
Packets containing only frames with this marking can be used to
probe new network paths during connection migration; see probing.
Paragraph (version B):
The content of frames with this marking are flow controlled; see
flow-control.
Paragraph (version B):
The "Pkts" and "Spec" columns in frame-types do not form part of the
IANA registry; see iana-frames.
Paragraph (version A):
The initial contents of this registry are tabulated in frame-types.
Note that the registry does not include the "Packets" column from
frame-types.
Paragraph (version B):
The initial contents of this registry are tabulated in frame-types.
Note that the registry does not include the "Pkts" and "Spec" columns
from frame-types.
Draft: draft-ietf-quic-invariants

Commentary: My WGLC feedback for -invariants is mostly nits , so I figured I 'd go straight to a PR . There 's one piece of this that might be non - editorial ; feel free to kick to an issue if you prefer . In one section , we say that different versions " might " define authentication for VN packets . Later , we say that QUIC versions MUST define such a mechanism . Resolving in favor of the MUST , I 've changed the other occurrence to a more definitive statement that QUIC versions do so . 
 Thanks  .
Paragraph (version A):
The next byte contains the length in bytes of the Source Connection
ID field that follows it.  This length is encoded as a 8-bit unsigned
integer.  The Source Connection ID field follows the Source
Connection ID Length field and is between 0 and 255 bytes in length.
Paragraph (version B):
The next byte contains the length in bytes of the Source Connection
ID field that follows it.  This length is encoded as an 8-bit
unsigned integer.  The Source Connection ID field follows the Source
Connection ID Length field and is between 0 and 255 bytes in length.
Paragraph (version A):
Version Negotiation packets do not use integrity or confidentiality
protection.  A specific QUIC version might authenticate the packet as
part of its connection establishment process.
Paragraph (version B):
Version Negotiation packets do not use integrity or confidentiality
protection.  Specific QUIC versions define mechanisms to authenticate
the packet as part of the connection establishment process.
Draft: draft-ietf-quic-transport

Commentary: The text in 2.1 is more complete , so we do n't need this . 
 When I read 3.0 I was a bit confused , because when the discussion of streams takes place in section 2.1 , the requirement on stream ID ordering is already mentioned , but the reminder of what the types are is fresh in the mind . Perhaps this should be revised .
Paragraph (version A):
An endpoint MUST open streams of the same type in increasing order of
stream ID.
Draft: draft-ietf-quic-transport

Commentary: one nit
Paragraph (version A):
A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams.  When deciding the streams
to which resources are dedicated, the implementation SHOULD use the
information provided by the application.
Paragraph (version B):
A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams.  An implementation uses
information provided by the application to determine how to allocate
resources to active streams.
Draft: draft-ietf-quic-transport

Commentary: should merge this . 
 I 'm assuming that you checked the others , and therefore surprised we got the others right .
Paragraph (version A):
Implementations MUST support buffering at least 4096 bytes of data
received in out of order CRYPTO frames.  Endpoints MAY choose to
allow more data to be buffered during the handshake.  A larger limit
during the handshake could allow for larger keys or credentials to be
exchanged.  An endpoint's buffer size does not need to remain
constant during the life of the connection.
Paragraph (version B):
Implementations MUST support buffering at least 4096 bytes of data
received in out-of-order CRYPTO frames.  Endpoints MAY choose to
allow more data to be buffered during the handshake.  A larger limit
during the handshake could allow for larger keys or credentials to be
exchanged.  An endpoint's buffer size does not need to remain
constant during the life of the connection.
Draft: draft-ietf-quic-http

Commentary: Actually , as 3.1 is " to bre removed before publication " , the expansion and ref should be in 3.2.1 .
Paragraph (version A):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the ALPN token defined in connection-
establishment.
Paragraph (version B):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the Application Layer Protocol
Negotiation (ALPN) RFC7301 token defined in connection-establishment.
Draft: draft-ietf-quic-http

Commentary: ABNF does not seem to be used in this document .
Paragraph (version A):
Field definitions are given in Augmented Backus-Naur Form (ABNF), as
defined in RFC5234.
Draft: draft-ietf-quic-transport

Commentary: The section for " Values of Transport Parameters for 0 - RTT " specifies which parameters a client MUST or MUST NOT remember . It does not do the same for a server . ( It implies that ones a client MUST NOT remember also do n't need to be remembered by a server , and it lists a subset of the remaining as ones the server MUST remember . ) This commit adds the remaining parameters to a list that the server need not remember . 
 This still looks good with the latest commit  pushed . 
 The " Values of Transport Parameters for 0 - RTT " section lists some , but not all , of the transport parameters defined in the spec . As currently written , it is ambiguous whether a server needs to remember the parameters not listed . ( A list of parameters that the client MUST NOT remember , and therefore the server need not remember , is provided , as well as a list that the server MUST remember so it does n't lower limits . ) As far as I understand the definitions of the remaining parameters , there is n't any need for a server to remember them . However , instead of requiring implementors to read through all of the transport parameter definitions and infer this on their own , it would be easier on implementors to spell this out in this section . ( This is required for definitions of new parameters . ) 
 I like the latest text !
Paragraph (version B):
A server MAY store and recover the previously sent values of the
max_idle_timout, max_udp_payload_size, and disable_active_migration
parameters and reject 0-RTT if it selects smaller values.  Lowering
the values of these parameters while also accepting 0-RTT data could
degrade the performance of the connection.  Specifically, lowering
the max_udp_payload_size could result in dropped packets leading to
worse performance compared to rejecting 0-RTT data outright.