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

Commentary: I 'll leave that in your hands . 
 said : 
 Seems reasonable . I took the opportunity to reword a little . 
 Perhaps this PR should also fix the text in 8.1 to simply state and point to 14.1 in -transport . That text is redundant .
Paragraph (version A):
The TLS implementation does not need to ensure that the ClientHello
is sufficiently large.  QUIC PADDING frames are added to increase the
size of the packet as necessary.
Paragraph (version B):
The TLS implementation does not need to ensure that the ClientHello
is large enough to meet the requirements for QUIC packets.  QUIC
PADDING frames are added to increase the size of the packet as
necessary; see Section 14.1 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-tls

Commentary:  observed that this might be at odds with the definition of the interface . This is true , but the illustrative value of the current structure is valuable . More text on that might help . 
 said : 
 I think that the multiple invocations is enough to call out . However , the retrieval of bytes to send after processing some data is not necessary . For reference , the is : This does not necessarily imply that you pull after every byte provided . As the bytes here are provided in a coalesced packet , it is reasonable to defer the " Get Handshake " call until all of the bytes arrive . I know that our stack does , though this is not uniformly true . to Handshake Complete ? YES ! Thanks . That 's going to be awkward , as it involves QUIC - layer messages , but I think we can do that . ( In a separate PR though . )
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 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.
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.  This shows multiple
"Get Handshake" invocations to retrieve handshake messages at
different encryption levels.  New handshake messages are requested
after incoming packets have been processed.
Paragraph (version B):
exchange-summary shows one possible structure for a simple handshake
exchange.  The exact process varies based on the structure of
endpoint implementations and the order in which packets arrive.
Implementations could use a different number of operations or execute
them in other orders.
Draft: draft-ietf-quic-tls

Commentary: The first strikes " TLS " from encryption level The second removes misleading text about coalescing I 'm suggesting that we replace it with explanatory language about encryption levels and packet number spaces . This context is now missing as a result of moving the referenced text to -transport . 
   said : 
 I 'm going to suggest that the text I propose in addresses this first part of this . The higher / lower stuff seems like it could be better , but it 's a lot of work to do carefully . I 'm going to suggest that we could live with this , but I might leave this issue open and try to find a fix once other more pressing issues are dealt with . 
 said : 
 This is really two comments , but I think we can dispense with both at the same time as the first is really trivial : use of " TLS encryption level " is an unnecessary redundancy and inconsistent with other usage , so we can easily remove " TLS " there . start of that paragraph is cruft . I 'm going to suggest we only keep the last sentence , which was unquoted in this issue . But then I see that we are missing important context , so I 'm going to suggest a little bit of text to replace it . 
 one suggestion , but lgtm
Paragraph (version A):
QUIC carries TLS handshake data in CRYPTO frames, each of which
consists of a contiguous block of handshake data identified by an
offset and length.  Those frames are packaged into QUIC packets and
encrypted under the current TLS encryption level.  As with TLS over
TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's
responsibility to deliver it reliably.  Each chunk of data that is
produced by TLS is associated with the set of keys that TLS is
currently using.  If QUIC needs to retransmit that data, it MUST use
the same keys even if TLS has already updated to newer keys.
Paragraph (version A):
One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same packet
number space.  For instance, an endpoint can bundle a Handshake
message and an ACK for some Handshake data into the same packet.
Some frames are prohibited in different packet number spaces; see
Section 12.5 of QUIC-TRANSPORT.
Paragraph (version B):
QUIC carries TLS handshake data in CRYPTO frames, each of which
consists of a contiguous block of handshake data identified by an
offset and length.  Those frames are packaged into QUIC packets and
encrypted under the current encryption level.  As with TLS over TCP,
once TLS handshake data has been delivered to QUIC, it is QUIC's
responsibility to deliver it reliably.  Each chunk of data that is
produced by TLS is associated with the set of keys that TLS is
currently using.  If QUIC needs to retransmit that data, it MUST use
the same keys even if TLS has already updated to newer keys.
Paragraph (version B):
Each encryption level corresponds to a packet number space.  The
packet number space that is used determines the semantics of frames.
Some frames are prohibited in different packet number spaces; see
Section 12.5 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-tls

Commentary: Important enough to call out in this section . 
   said : 
 I think that we 're OK , and the text in should help avoid any need for this point . 
 said : 
 Should we split this bit out into a separate issue ? per § 4.8 TLS alerts are translated into QUIC connection errors and are not sent natively . ( The prose also says " TLS Handshake and  messages are carried directly over the QUIC transport " . ) 
 I do n't think we need to do anything in response to that . Those messages are carried by QUIC . 
 I will defer to your preference , but I do not agree that " those messages " are carried by QUIC ; QUIC does not carry TLS Alert structures . 
 a nit but lgtm
Paragraph (version A):
Additional functions might be needed to configure TLS.
Paragraph (version B):
Additional functions might be needed to configure TLS.  In
particular, QUIC and TLS need to agree on which is responsible for
validation of peer credentials, such as certificate validation
(RFC5280).
Draft: draft-ietf-quic-tls

Commentary: Though I guess provisioning of a PSK depends on prior communication of a sort , there is no need to be so absolute here . 
 said : 
 I will suggest that we strike the " only " here .
Paragraph (version A):
The 0-RTT handshake is only possible if the client and server have
previously communicated.  In the 1-RTT handshake, the client is
unable to send protected Application Data until it has received all
of the Handshake messages sent by the server.
Paragraph (version B):
The 0-RTT handshake can be used if the client and server have
previously communicated.  In the 1-RTT handshake, the client is
unable to send protected Application Data until it has received all
of the Handshake messages sent by the server.
Draft: draft-ietf-quic-invariants

Commentary:   said : 
 has been merged , so we can also close this issue .
Paragraph (version A):
bad-assumptions is a non-exhaustive list of some incorrect
assumptions that might be made based on knowledge of QUIC version 1;
these do not apply to every version of QUIC.
Paragraph (version B):
bad-assumptions contains a non-exhaustive list of some incorrect
assumptions that might be made based on knowledge of QUIC version 1;
these do not apply to every version of QUIC.
Draft: draft-ietf-quic-http

Commentary: To align with " official " terminology in RFC 8499 . Cite that .
Paragraph (version A):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake.  If the server is
identified by a DNS name, clients MUST send the Server Name
Indication (SNI; RFC6066) TLS extension unless an alternative
mechanism to indicate the target host is used.
Paragraph (version B):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake.  If the server is
identified by a domain name (DNS-TERMS), clients MUST send the Server
Name Indication (SNI; RFC6066) TLS extension unless an alternative
mechanism to indicate the target host is used.
Draft: draft-ietf-quic-tls

Commentary: This is OK , but only in a limited fashion . 
 said : parameters are not delivered until the handshake is complete . In 8.2 it says that the TPs are " available " but " not fully trusted " before completion . The latter is certainly true ; but the server ca n't send 0.5 - RTT packets ( e.g. a SETTINGS frame ) without any indication of the client transport parameters . I would suggest a clarification in 4.1.3 and letting the language in 8.2 stand . 
 Proposed resolution is 
 I think the limitations could be a be clearer , but heading in a good direction . I think the changes add clarity .
Paragraph (version A):
Once the TLS handshake is complete, this is indicated to QUIC along
with any final handshake bytes that TLS needs to send.  TLS also
provides QUIC with the transport parameters that the peer advertised
during the handshake.
Paragraph (version B):
Once the TLS handshake is complete, this is indicated to QUIC along
with any final handshake bytes that TLS needs to send.  At this
stage, the transport parameters that the peer advertised during the
handshake are authenticated; see quic_parameters.
Paragraph (version A):
While the transport parameters are technically available prior to the
completion of the handshake, they cannot be fully trusted until the
handshake completes, and reliance on them should be minimized.
However, any tampering with the parameters will cause the handshake
to fail.
Paragraph (version B):
Transport parameters become available prior to the completion of the
handshake.  A server might use these values earlier than handshake
completion.  However, the value of transport parameters is not
authenticated until the handshake completes, so any use of these
parameters cannot depend on their authenticity.  Any tampering with
transport parameters will cause the handshake to fail.
Draft: draft-ietf-quic-transport

Commentary: said : 14 " Thus , modern IPv4 and all IPv6 network paths will be able to support QUIC . " Generally true , but should be qualified for the presence of arbitrary numbers of tunnels . 
 This is not one that I have an answer to currently . We could just wave this away as Martin suggests , but I 'm not sure that is best . What do tunneling protocols say about ensuring the IPv6 minimum MTU ? 
 I do n't know what the IETF tunneling protocols say about MTU , but I do n't expect them to violate IPv6 minimum MTU ( someone should correct me if I 'm wrong ) . The problem here might not be about what allowances we make for tunneling -- I do n't want to create a list of exceptions in this document -- but about wording . I propose changing " will be able to support " to " are expected to support " . As long as we are not making assumptions that violate permissions afforded by spec or practice , I think we 're good . 
 Thanks . This is weaker , but truer .
Paragraph (version A):
QUIC assumes a minimum IP packet size of at least 1280 bytes.  This
is the IPv6 minimum size (IPv6) and is also supported by most modern
IPv4 networks.  Assuming the minimum IP header size of 40 bytes for
IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this
results in a maximum datagram size of 1232 bytes for IPv6 and 1252
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths will be
able to support QUIC.
Paragraph (version B):
QUIC assumes a minimum IP packet size of at least 1280 bytes.  This
is the IPv6 minimum size (IPv6) and is also supported by most modern
IPv4 networks.  Assuming the minimum IP header size of 40 bytes for
IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this
results in a maximum datagram size of 1232 bytes for IPv6 and 1252
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are
expected to be able to support QUIC.
Draft: draft-ietf-quic-transport

Commentary: Thanks , !
Paragraph (version A):
An endpoint MAY drop packet protection keys when entering the closing
state and send a packet containing a CONNECTION_CLOSE frame in
response to any UDP datagram that is received.  However, an endpoint
that discards packet protection keys cannot identify and discard
invalid packets.  To avoid being used for an amplication attack, such
endpoints MUST limit the cumulative size of packets it sends to three
times the cumulative size of the packets that are received and
attributed to the connection.  To minimize the state that an endpoint
maintains for a closing connection, endpoints MAY send the exact same
packet in response to any received packet.
Paragraph (version B):
An endpoint MAY drop packet protection keys when entering the closing
state and send a packet containing a CONNECTION_CLOSE frame in
response to any UDP datagram that is received.  However, an endpoint
that discards packet protection keys cannot identify and discard
invalid packets.  To avoid being used for an amplification attack,
such endpoints MUST limit the cumulative size of packets it sends to
three times the cumulative size of the packets that are received and
attributed to the connection.  To minimize the state that an endpoint
maintains for a closing connection, endpoints MAY send the exact same
packet in response to any received packet.
Draft: draft-ietf-quic-http

Commentary: Maybe leftovers from , or newly text . 
 I 'm sure the document was touched by his noodly appendage of the Octocat : octocat : 
 How did those slip through!?Yes , I think these are mostly new / imported from other docs . Thanks , !
Paragraph (version A):
To allow for better compression efficiency, the "Cookie" field
(RFC6265) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single octet string using the two-octet delimiter
of 0x3b, 0x20 (the ASCII string "; ") before being passed into a
context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection,
or a generic HTTP server application.
Paragraph (version B):
To allow for better compression efficiency, the "Cookie" field
(RFC6265) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single byte string using the two-byte delimiter
of 0x3b, 0x20 (the ASCII string "; ") before being passed into a
context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection,
or a generic HTTP server application.
Draft: draft-ietf-quic-http

Commentary: Do Not Deploy note plus changelog . 
 one nit , but lgtm
Paragraph (version B):
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
version is still a work in progress.  For trial deployments, please
use earlier versions.
Draft: draft-ietf-quic-transport

Commentary: Note : Do n't merge until the last minute . 
 I want to do more than just approve this , but this 'll have to do
Paragraph (version A):
The version number for the final version of this specification
(0x00000001), is reserved for the version of the protocol that is
published as an RFC.
Paragraph (version A):
Version numbers used to identify IETF drafts are created by adding
the draft number to 0xff000000.  For example, draft-ietf-quic-
transport-13 would be identified as 0xff00000d.
Paragraph (version A):
Implementors are encouraged to register version numbers of QUIC that
they are using for private experimentation on the GitHub wiki at
<https://github.com/quicwg/base-drafts/wiki/QUIC-Versions>.
Draft: draft-ietf-quic-recovery

Commentary: rightly noted lack of clarity ( ) , which this PR attempts to fix . There 's a new MUST here , but I think it was again implicit . EDIT : Removed this MUST since notes correctly that this is a definition , not an action .
Paragraph (version A):
a prior RTT sample existed when both packets were sent.
Paragraph (version B):
a prior RTT sample existed when these two packets were sent.
Draft: draft-ietf-quic-transport

Commentary: IANA 's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved , and what note should be present if not . They should not , lest it be challenging to actually download the registry page within the lifetime of the human race . This rewords the restriction and clarifies that the restriction should be the note . 
 Can you add the same text to 22.2 ( Transport parameter registry ) in the transport doc as well ? 
 said 
 We believe the note , updated based on IANA feedback during Last Call , is sufficient . Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity ; see . The purpose is described in , to exercise the requirement to ignore unknown frame types ( a.k.a . GREASE ) . Proposal is to make no change ; this was already covered during IANA review . 
 If IANA has agreed , then I am fine with it . BTW , I was not asking to make those zillions of reservations but leaving a note in the registry ;-) 
 It 's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage , closing with no action . 
 Please see the for full context . This issue is tracking the following IANA question : 
 Copying my e - mail reply here : unknown values ; having an explicit list encourages an explicitly defined reaction . This also applies to and , where the latter has better wording . 
 replied to IANA . Closing this issue . 
 Actually , said in response to the e - mail that this guidance should be in the document : Let 's re - open to track . I do n't think all instances of this question need separate issues , though . 
 So the related questions were : Should the GREASE values be listed in the registry as Reserved ? No , because some rough estimation suggests it would take a few millennia to download the registry page if this were the case . Should there be a note indicating which values can not be assigned ? I 'm of two minds , because while I really do n't want people embedding the formula into their parsers , I do want people embedding the formula into their generators . says no Reserved listing , yes note . 
 I think this is proposal ready .
Paragraph (version A):
Additionally, each value of the format "31 * N + 27" for integer
values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be
assigned by IANA.
Paragraph (version B):
Each value of the format "31 * N + 27" for integer values of N (that
is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned
by IANA and MUST NOT appear in the listing of assigned values.
Draft: draft-ietf-quic-http

Commentary: Mostly because QUIC does n't prevent all forms of request forgery . Thankfully , this is dealt with in detail in the transport draft . 
 this looks good . Can you also change one sentence in Sec 1.2 , from : to . 
   wrote : all this is assumed to be provided by QUIC . Section 10.2 says that all QUIC packets are encrypted ; I 'm not sure if that 's true , or if QUIC has an option for " non - modifiable " without encryption . 
 Actually , we now know that this is not true , so this really needs to be fixed : -- from . The real solution here is to cite of the transport draft . 
 The version of QUIC required by this draft is always encrypted ; that seems sufficient for the original issue . issue is distinct , and worth fixing . I 'll use this issue to track it . 
 ... and we could add some text stating the integrity point in Section 1.2 . suggests : " comparable integrity and confidentiality to TLS over TCP " 
 Could we make some progress on this one ? 
 Progress made ; the PR now needs review .
Paragraph (version A):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, QUIC has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS13) at the transport layer, offering
comparable security to running TLS over TCP, with the improved
connection setup latency of TCP Fast Open (TFO).
Paragraph (version B):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, QUIC has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS13) at the transport layer, offering
comparable confidentiality and integrity to running TLS over TCP,
with the improved connection setup latency of TCP Fast Open (TFO).
Paragraph (version A):
The use of ALPN in the TLS and QUIC handshakes establishes the target
application protocol before application-layer bytes are processed.
Because all QUIC packets are encrypted, it is difficult for an
attacker to control the plaintext bytes of an HTTP/3 connection,
which could be used in a cross-protocol attack on a plaintext
protocol.
Paragraph (version B):
The use of ALPN in the TLS and QUIC handshakes establishes the target
application protocol before application-layer bytes are processed.
This ensures that endpoints have strong assurances that peers are
using the same protocol.
Paragraph (version B):
This does not guarantee protection from all cross-protocol attacks.
Section 21.5 of QUIC-TRANSPORT describes some ways in which the
plaintext of QUIC packets can be used to perform request forgery
against endpoints that don't use authenticated transports.
Draft: draft-ietf-quic-recovery

Commentary: In the Recovery genart review ,   wrote : 
 Based on the proposed PR , I 'm marking this as editorial . 
 In the Recovery genart review ,   wrote : 
 Based on the proposed PR , I 'm marking this as editorial .
Paragraph (version A):
QUIC is a new multiplexed and secure transport protocol atop UDP,
specified in QUIC-TRANSPORT.  This document describes congestion
control and loss recovery for QUIC.  Mechanisms described in this
document follow the spirit of existing TCP congestion control and
loss recovery mechanisms, described in RFCs, various Internet-drafts,
or academic papers, and also those prevalent in TCP implementations.
Paragraph (version B):
QUIC is a secure general-purpose transport protocol, described in
QUIC-TRANSPORT).  This document describes loss detection and
congestion control mechanisms for QUIC.
Paragraph (version A):
TCP conflates transmission order at the sender with delivery order at
the receiver, which results in retransmissions of the same data
carrying the same sequence number, and consequently leads to
"retransmission ambiguity".  QUIC separates the two.  QUIC uses a
packet number to indicate transmission order.  Application data is
sent in one or more streams and delivery order is determined by
stream offsets encoded within STREAM frames.
Paragraph (version B):
TCP conflates transmission order at the sender with delivery order at
the receiver, resulting in the retransmission ambiguity problem
(RETRANSMISSION).  QUIC separates transmission order from delivery
order: packet numbers indicate transmission order, and delivery order
is determined by the stream offsets in STREAM frames.