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

Commentary: Just so you do n't have to read the whole RFC7301 . 
 Yeah I was thinking about that . I wonder if it would make sense for the client to simply send PROTOCOL_VIOLATION instead of a TLS alert . 
 I a clarification to allow clients to send noapplicationnegotiated as well . Should I send an email to the mailing list for discussion now that the new process is in effect ? 
 Unfortunately yes . This is a design change so it will need an issue as well . I like it and we should do it , but can you add the error code we would use in CONNECTION_CLOSE to the text ? 
 ok , error code , created issue ( ) and sent email to the list . 
 thanks , suggestions accepted . 
 PR a requirement for end - points to terminate a connection if ALPN negotiation fails , but does n't specify an error code for this situation . RFC7301 defines the alert that must be used by TLS servers , so QUIC servers should probably use that as well . As for clients , RFC7301 does n't specify a behaviour , but it also does n't forbid use of in clients , and it seems better if QUIC clients use the same error code as the servers . Proposed wording change is in . 
 My : +1 : goes to making the change , though I would like to confirm that it would n't be illegal for a client to close the connection with error after it sends ClientFinished . I ask this because depending on the design of the TLS stack , the QUIC stack might not be able to see the result of ALPN before the TLS stack generates a ClientFinished ( note that EE.ALPN and ServerFinished might arrive in one packet ) . It 's my understanding that the intent of the issue is to not allow the client to send any application data on ALPN failure . Assuming that 's true , sending the alert after ClientFinished should be fine . 
 Yes , I think that would be fine . I do n't think that we would be able to guarantee that the alert goes out before sending ClientFinished either . It 's certainly possible , but I can see how it might be tricky . 
 This was fixed with . 
 a few nits
Paragraph (version A):
QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation.  TLS uses Application Layer Protocol
Negotiation (ALPN) RFC7301 to select an application protocol.  Unless
another mechanism is used for agreeing on an application protocol,
endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints
MUST abort a connection if an application protocol is not negotiated.
Draft: draft-ietf-quic-transport

Commentary: The deleted parenthetical is not accurate , and is unnecessary : 0 - RTT and 1 - RTT with various key phases share a PN space without sharing keys . I prefer the MUST NOT in coalescing , but if there are objections I can revert it . 
 Thanks  . 
 All good apart from the MUST NOT . I 'm with Martin -- everything else looks fine .
Paragraph (version A):
Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK
frame (frame-ack).  When present in a long or short header however,
packet numbers are reduced and encoded in 1 to 4 bytes, see packet-
encoding).
Paragraph (version A):
Version Negotiation (packet-version) and Retry packet-retry packets
do not include a packet number.
Paragraph (version A):
Initial space: All Initial packets packet-initial are in this
space.
Paragraph (version A):
Handshake space: All Handshake packets packet-handshake are in
this space.
Paragraph (version A):
Application data space: All 0-RTT and 1-RTT encrypted packets
packet-protected are in this space.
Paragraph (version B):
Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK
frame (frame-ack).  When present in a long or short header however,
packet numbers are reduced and encoded in 1 to 4 bytes (see packet-
encoding).
Paragraph (version B):
Version Negotiation (packet-version) and Retry (packet-retry) packets
do not include a packet number.
Paragraph (version B):
Initial space: All Initial packets (packet-initial) are in this
space.
Paragraph (version B):
Handshake space: All Handshake packets (packet-handshake) are in
this space.
Paragraph (version B):
Application data space: All 0-RTT and 1-RTT encrypted packets
(packet-protected) are in this space.
Paragraph (version A):
A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection (that is, under the same cryptographic
keys).  If the packet number for sending reaches 2^62 - 1, the sender
MUST close the connection without sending a CONNECTION_CLOSE frame or
any further packets; an endpoint MAY send a Stateless Reset
(stateless-reset) in response to further packets that it receives.
Paragraph (version B):
A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection.  If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without
sending a CONNECTION_CLOSE frame or any further packets; an endpoint
MAY send a Stateless Reset (stateless-reset) in response to further
packets that it receives.
Draft: draft-ietf-quic-http

Commentary: Simply making this consistent through the document by doing the minimal change and removing leading 0s . Happy to add them if we prefer . 
 Works for me .
Paragraph (version A):
The PRIORITY (type=0x02) frame specifies the client-advised priority
of a request, server push or placeholder.
Paragraph (version B):
The PRIORITY (type=0x2) frame specifies the client-advised priority
of a request, server push or placeholder.
Paragraph (version A):
The PUSH_PROMISE frame (type=0x05) is used to carry a promised
request header set from server to client on a request stream, as in
HTTP/2.
Paragraph (version B):
The PUSH_PROMISE frame (type=0x5) is used to carry a promised request
header set from server to client on a request stream, as in HTTP/2.
Draft: draft-ietf-quic-transport

Commentary: What data can and can not be retried safely ? 
 That 's not something that QUIC knows . HTTP does though . As advice , I do n't think that this needs much more expansion , but I 'd be happy to take a PR . 
 I 'm not so sure this is a HTTP - only issue . Unlike TLS 1.3 , there is QUIC data being sent under encryption , and that might have side effects . 
 LGTM , one nit . ( " using applications " is fine , it 's just a bit awkward . )
Paragraph (version A):
The value for an idle timeout can be asymmetric.  The value
advertised by an endpoint is only used to determine whether the
connection is live at that endpoint.  An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the
packets arrive.  If a peer could timeout within an Probe Timeout
(PTO, see Section 6.2.2 of QUIC-RECOVERY), it is advisable to test
for liveness before sending any data that cannot be retried safely.
Paragraph (version B):
The value for an idle timeout can be asymmetric.  The value
advertised by an endpoint is only used to determine whether the
connection is live at that endpoint.  An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the
packets arrive.  If a peer could timeout within an Probe Timeout
(PTO, see Section 6.2.2 of QUIC-RECOVERY), it is advisable to test
for liveness before sending any data that cannot be retried safely.
Note that it is likely that only applications or application
protocols will know what information can be retried.
Draft: draft-ietf-quic-transport

Commentary: This does n't seem implementable without a list of all the things that were sufficient . 
 That is the list . If you think it should be reworded , I 'm happy to take a PR .
Paragraph (version A):
An endpoint MAY transition from the closing period to the draining
period if it can confirm that its peer is also closing or draining.
Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is
receiving a stateless reset.  The draining period SHOULD end when the
closing period would have ended.  In other words, the endpoint can
use the same end time, but cease retransmission of the closing
packet.
Paragraph (version B):
An endpoint MAY transition from the closing period to the draining
period if it receives a CONNECTION_CLOSE frame or stateless reset,
both of which indicate that the peer is also closing or draining.
The draining period SHOULD end when the closing period would have
ended.  In other words, the endpoint can use the same end time, but
cease retransmission of the closing packet.
Draft: draft-ietf-quic-http

Commentary: Another attempt to group related concepts in this section which hopefully ( This is technically design , because previously - required server behavior is now only recommended . ) 
 Why do I have to explicitly cancel after GOAWAY ? Given that GOAWAY already tells the client this , what 's the point ? 
 GOAWAY tells the client that those requests are n't going to be serviced , but the streams will continue to exist . If the cleanup period is significant , having the streams open is a bad idea . However , attaching SHOULD to this is unnecessary , I think that we might instead just note that clients are free to do as they please with streams that wo n't be answered . 
 Discussed in Tokyo ; this does n't need to be required server behavior , but recommended ( or RECOMMENDED ) as a method to clean up state . Should have a reminder cross - reference to request rejection . 
 Lgtm now
Paragraph (version A):
Once GOAWAY is sent, the server MUST reject requests sent on streams
with an identifier greater than or equal to the indicated last Stream
ID.  Clients MUST NOT send new requests on the connection after
receiving GOAWAY, although requests might already be in transit.  A
new connection can be established for new requests.
Paragraph (version A):
If the client has sent requests on streams with a Stream ID greater
than or equal to that indicated in the GOAWAY frame, those requests
are considered rejected (request-cancellation).  Clients SHOULD
cancel any requests on streams above this ID.  Servers MAY also
reject requests on streams below the indicated ID if these requests
were not processed.
Paragraph (version A):
Requests on Stream IDs less than the Stream ID in the GOAWAY frame
might have been processed; their status cannot be known until they
are completed successfully, reset individually, or the connection
terminates.
Paragraph (version B):
Clients MUST NOT send new requests on the connection after receiving
GOAWAY; a new connection MAY be established to send additional
requests.
Paragraph (version B):
Some requests might already be in transit.  If the client has already
sent requests on streams with a Stream ID greater than or equal to
that indicated in the GOAWAY frame, those requests will not be
processed and MAY be retried by the client on a different connection.
The client MAY cancel these requests.  It is RECOMMENDED that the
server explicitly reject such requests (see request-cancellation) in
order to clean up transport state for the affected streams.
Paragraph (version B):
Requests on Stream IDs less than the Stream ID in the GOAWAY frame
might have been processed; their status cannot be known until a
response is received, the stream is reset individually, or the
connection terminates.  Servers MAY reject individual requests on
streams below the indicated ID if these requests were not processed.
Draft: draft-ietf-quic-recovery

Commentary: From reading the text , it was not clear that the timer is set based on the last ( and not the first ) crypto packet sent . 
 LGTM . I 've reworded a bit .
Paragraph (version A):
When crypto packets are sent, the sender MUST set a timer for the
crypto timeout period.  Upon timeout, the sender MUST retransmit all
unacknowledged CRYPTO data if possible.
Paragraph (version B):
When a crypto packet is sent, the sender MUST set a timer for the
crypto timeout period.  This timer MUST be updated when a new crypto
packet is sent.  Upon timeout, the sender MUST retransmit all
unacknowledged CRYPTO data if possible.
Draft: draft-ietf-quic-transport

Commentary: This is fine , but I think that we want chairs to call it . 
 This falls under the new process , so it 's upto the chairs . 
 Based on the discussion in I think this has rough consensus . Tagging as such and reassigning . 
 Slow down , we 're not in the new process yet . And , in either case , consensus needs to be determined on - list , not in issues . 
 Currently , the t is in units of seconds . This seems to be too restrictive and not very future proof . Additionally , from an API perspective , most other timers are settable on the millisecond scale , so it creates a kind of ugly discrepancy between all the different timers settable by the app if just one of them has units of seconds . I propose we change the units from seconds to milliseconds . The change both for implementations and spec should be minimal , and it makes things ( timers ) a little more consistent . 
 This seems sensible to me both for consistency and I can imagine cases when one would want to specify a fraction(ie : 1/2 of a second ) . 
 Agreed . A second is an eternity for a intra - datacenter connection for example . For future proofing all time units should be at least msec IMO . 
 Do n't we want to specify a minimum value now ? 
 No , I do n't think so . Even before , if you had a greater than 1 sec RTT ( somehow ... ) if you set an idle timeout of 1 second it would cause you problems . I think bottom line you be smart about your idle timeout values . If you set too small a value you can unnecessarily kill your own connection . 
 As says , actual idle timeout depends on RTT , and that ’s what we have adopted in . 
 This SGTM . 
 I support this 
 I think this has rough consensus . Tagging as such and reassigning . 
 LG , but I do n't know what process this falls under . I 'll let and decide .
Paragraph (version A):
The idle timeout is a value in seconds that is encoded as an
integer, see (idle-timeout).  If this parameter is absent or zero
then the idle timeout is disabled.
Paragraph (version B):
The idle timeout is a value in milliseconds that is encoded as an
integer, see (idle-timeout).  If this parameter is absent or zero
then the idle timeout is disabled.
Draft: draft-ietf-quic-transport

Commentary: It 's untrue that any stream could be created by any endpoint .
Paragraph (version A):
Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled.  Any stream can
be initiated by either endpoint.  QUIC does not provide any means of
ensuring ordering between bytes on different streams.
Paragraph (version B):
Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled.  QUIC does not
provide any means of ensuring ordering between bytes on different
streams.
Draft: draft-ietf-quic-transport

Commentary: For and 
 Thanks 
 Note that section 17.2.3 . 0 - RTT does not mention 0 - RTT CID but the following section 7.2.4 . Handshake Packet does mention Handshake CID 's . In existing draft . 
 LGTM , given the incorporated changes .
Paragraph (version A):
The client populates the Source Connection ID field with a value of
its choosing and sets the SCIL field to match.
Paragraph (version B):
The client populates the Source Connection ID field with a value of
its choosing and sets the SCIL field to indicate the length.
Paragraph (version B):
The first flight of 0-RTT packets use the same Destination and Source
Connection ID values as the client's first Initial.
Paragraph (version A):
On first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets.  That means that a
client might change the Destination Connection ID twice during
connection establishment, once in response to a Retry and once in
response to the first Initial packet from the server.  Once a client
has received an Initial packet from the server, it MUST discard any
packet it receives with a different Source Connection ID.
Paragraph (version B):
On first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets, including any
subsequent 0-RTT packets.  That means that a client might change the
Destination Connection ID twice during connection establishment, once
in response to a Retry and once in response to the first Initial
packet from the server.  Once a client has received an Initial packet
from the server, it MUST discard any packet it receives with a
different Source Connection ID.
Draft: draft-ietf-quic-tls

Commentary: This includes the suggestion from to remove the 0 - RTT text . Plus some text explaining the choice of label .
Paragraph (version A):
In using TLS, the central key schedule of TLS is used.  As a result
of the TLS handshake messages being integrated into the calculation
of secrets, the inclusion of the QUIC transport parameters extension
ensures that handshake and 1-RTT keys are not the same as those that
might be produced by a server running TLS over TCP.  However, 0-RTT
keys only include the ClientHello message and might therefore use the
same secrets.  To avoid the possibility of cross-protocol key
synchronization, additional measures are provided to improve key
separation.
Paragraph (version A):
To preserve this separation, a new version of QUIC SHOULD define new
labels for key derivation for packet protection key and IV, plus the
header protection keys.
Paragraph (version A):
The initial secrets also use a key that is specific to the negotiated
QUIC version.  New QUIC versions SHOULD define a new salt value used
in calculating initial secrets.
Paragraph (version B):
In using TLS, the central key schedule of TLS is used.  As a result
of the TLS handshake messages being integrated into the calculation
of secrets, the inclusion of the QUIC transport parameters extension
ensures that handshake and 1-RTT keys are not the same as those that
might be produced by a server running TLS over TCP.  To avoid the
possibility of cross-protocol key synchronization, additional
measures are provided to improve key separation.
Paragraph (version B):
To preserve this separation, a new version of QUIC SHOULD define new
labels for key derivation for packet protection key and IV, plus the
header protection keys.  This version of QUIC uses the string "quic".
Other versions can use a version-specific label in place of that
string.
Paragraph (version B):
The initial secrets use a key that is specific to the negotiated QUIC
version.  New QUIC versions SHOULD define a new salt value used in
calculating initial secrets.
Draft: draft-ietf-quic-tls

Commentary: I suspect these are uncontroversial . 
 All three Mart[ie]ns now agree , no further objections allowed . 
 LGTM , with the one change altered .
Paragraph (version A):
The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of TLS13 is used, using the hash
function from the negotiated cipher suite.  Other versions of TLS
MUST provide a similar function in order to be used QUIC.
Paragraph (version B):
The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of TLS13 is used, using the hash
function from the negotiated cipher suite.  Other versions of TLS
MUST provide a similar function in order to be used with QUIC.
Paragraph (version A):
The value of initial_salt is a 20 byte sequence shown in the figure
in hexadecimal notation.  Future versions of QUIC SHOULD generate a
new salt value, thus ensuring that the keys are different for each
version of QUIC.  This prevents a middlebox that only recognizes one
version of QUIC from seeing or modifying the contents of handshake
packets from future versions.
Paragraph (version B):
The value of initial_salt is a 20 byte sequence shown in the figure
in hexadecimal notation.  Future versions of QUIC SHOULD generate a
new salt value, thus ensuring that the keys are different for each
version of QUIC.  This prevents a middlebox that only recognizes one
version of QUIC from seeing or modifying the contents of packets from
future versions.
Paragraph (version A):
The "extension_data" field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in
use.  The quic_transport_parameters extension carries a
TransportParameters when the version of QUIC defined in QUIC-
TRANSPORT is used.
Paragraph (version B):
The "extension_data" field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in
use.  The quic_transport_parameters extension carries a
TransportParameters struct when the version of QUIC defined in QUIC-
TRANSPORT is used.
Draft: draft-ietf-quic-qpack

Commentary: A couple of clarifications that can be useful to people who are looking at * PACK for the first time like myself . Not sure about the normative language though . I can reword it if necessary . 
 Let 's see how handles it : We could simply add similar verbiage to Sections and 4.5.5 . of the QPACK draft instead . 
 I can add something like that , but TBH I do n't think that the HPACK wording would have helped me , so I 'd rather keep my clarification ( that says " ignore value " ) as well . 
 This wording seems fine .
Paragraph (version B):
All entries in the static table have a name and a value.  However,
values can be empty (that is, have a length of 0).
Paragraph (version B):
Only the header field name stored in the static or dynamic table is
used.  Any header field value MUST be ignored.
Draft: draft-ietf-quic-transport

Commentary: by discarding packets which are " inconsistent with the state of the connection . " Previously , this was only a failure to remove packet protection ; incorrect version is as another example inconsistency . Note that this phrasing does n't rule out upward - VN like , since receiving an expected upgrade is not inconsistent with your local state . 
 I 'm wondering if there is a difference between failed decryption and version number . If the versions differ , it does n't really make sense to try to read a subsequent coalesced packet , unless you want to do trial and error since the concepts of coalescing and length fields are not defined in the general case . Even if you understand the version , two version can not ( or should not ? ) exist in the same datagram . If packet protection fails on the same version , it might just be a timing issue , or the ( to me ) dreaded path probe with prefixed knowingly invalid handshake . 
 That 's an interesting question . The Length field is version - specific . If you include it , you can have no expectation that a peer which does n't speak that version will even be able to find anything further in the datagram -- as far as it knows , the remainder of the datagram is that connection . But that actually has a potential use . On receipt , if the logic first attempts to chunk up the datagram and the subsequent packet is the correct version for the connection , then acknowledging that second coalesced packet implies that you support the first packet 's version .
Paragraph (version A):
Packets that are matched to an existing connection, but for which the
endpoint cannot remove packet protection, are discarded.
Paragraph (version B):
Packets that are matched to an existing connection are discarded if
the packets are inconsistent with the state of that connection.  For
example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet
protection is unsuccessful once the expected keys are available.