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

Commentary: Just to set expectations , I think that I want to reserve the ability to pick new values for these . Just as there will be a new value for the Initial salt when we publish an RFC , this probably needs a new value at the same time . 
 Retry integrity protection ( ) specifies the AES - GCM key and IV directly . While that works fine for people using TLS stacks that provide direct access to AES - GCM , it does not for people using TLS stacks that only provides access to TLS AEAD API . Previously , we have been consistent in using HKDF - Expand - Label in a specific way so that people could rely on the " TLS " stack generating AEAD contexts . I think we can resolve the concern by simply changing the hard - coded AES - GCM key and IV we specify in the TLS draft to a set of values that can be derived by using the TLS AEAD API . 
 It would be easier for me to do as suggested , but the overall effort is small . I can live with either answer . Note that the additional indirection can be hard - coded out if people find they want to prime their AES directly . Of course , you do n't need to run AES at all if you want to go that far . 
 I agree that this is not a must , even though it 's about helping some of the implementations . I would highly appreciate it if you could merge the PR before -25 ships , as I think changing the default key before shipping the first draft that adopts the GCM - based Retry protection would have the least friction . 
 This is useful , and we should merge this . I do n't think this needs to be design . 
 If this is the outcome , then this seems fine . I think this is useful -- we should merge this .
Paragraph (version A):
The secret key, K, is 128 bits equal to
0xf5ed4642e0e4c8d878bbbc8a828821c9.
Paragraph (version A):
The nonce, N, is 96 bits all set to zero.
Paragraph (version B):
The secret key, K, is 128 bits equal to
0x4d32ecdb2a2133c841e4043df27d4430.
Paragraph (version B):
The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575.
Paragraph (version B):
The secret key and the nonce are values derived by calling HKDF-
Expand-Label using
0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as
the secret, with labels being "quic key" and "quic iv" (protection-
keys).
Draft: draft-ietf-quic-recovery

Commentary: Notes that ack delays are right shifted by ackdelayexponent when transmitted in ACK frames . 
 The recovery draft currently assumes you 've already applied the ack delay exponent . It should spell that out explicitly so readers of the draft do n't miss it . Ideally it 'd be obvious if you just read transport , but that 's a long draft , so there 's no harm in stating it again . From an on - list comment by
Paragraph (version A):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for ACK delays.  For packets sent in the ApplicationData
packet number space, a peer limits any delay in sending an
acknowledgement for an ack-eliciting packet to no greater than the
value it advertised in the max_ack_delay transport parameter.
Consequently, when a peer reports an Ack Delay that is greater than
its max_ack_delay, the delay is attributed to reasons out of the
peer's control, such as scheduler latency at the peer or loss of
previous ACK frames.  Any delays beyond the peer's max_ack_delay are
therefore considered effectively part of path delay and incorporated
into the smoothed_rtt estimate.
Paragraph (version B):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for acknowledgement delays.  These delays are computed using
the ACK Delay field of the ACK frame as described in Section 19.3 of
QUIC-TRANSPORT.  For packets sent in the ApplicationData packet
number space, a peer limits any delay in sending an acknowledgement
for an ack-eliciting packet to no greater than the value it
advertised in the max_ack_delay transport parameter.  Consequently,
when a peer reports an Ack Delay that is greater than its
max_ack_delay, the delay is attributed to reasons out of the peer's
control, such as scheduler latency at the peer or loss of previous
ACK frames.  Any delays beyond the peer's max_ack_delay are therefore
considered effectively part of path delay and incorporated into the
smoothed_rtt estimate.
Draft: draft-ietf-quic-http

Commentary: Pleasantly , the same formula we 've used for grease values elsewhere in HTTP/3 does not collide with any currently - assigned error code , so I 've just reused it . ( We 'll need to be cautious about 0x119 , though . ) The same logic could be applied to transport error codes , but there 's not much point . If you 're intolerant of the way your peer closed the connection , you might erroneously ... close the connection ? Editorial - ish : A recommendation which reserves some error code space we have n't used ; modifies the IANA instructions . Does n't mandate or prohibit anything new . 
 Constraining the recommendation on grease streams , because sending any error code potentially generates an error code that has semantics to your peer of which you are unaware . 
 The discussion on made us conclude that the reason for doing this is that we want to safeguard our ability to define new error codes . Greasing might help with that . 
 Since you 'd probably want want the grease to not sacrifice connections it might make sense to couple grease error codes to H3 grease streams . Also , what about greasing of transport - level error codes ? Ca n't play the stream tricks there . 
 Unknown error codes are supposed to be equivalent to H3NOERROR . Perhaps a recommendation ( SHOULD ) to substitute a grease code with non - zero probability when you would have sent NO_ERROR ? And MAY use them when terminating grease streams , sure . 
 Looks fine to me . I wonder how much this will end up doing anything ... LG , but I think it 's worth accepting Martin 's suggestion .
Paragraph (version A):
The payload and length of the stream are selected in any manner the
implementation chooses.
Paragraph (version B):
The payload and length of the stream are selected in any manner the
implementation chooses.  Implementations MAY terminate these streams
cleanly, or MAY abruptly terminate them.  When terminating abruptly,
the error code H3_NO_ERROR or a reserved error code (http-error-
codes) SHOULD be used.
Paragraph (version B):
Error codes of the format "0x1f * N + 0x21" for integer values of N
are reserved to exercise the requirement that unknown error codes be
treated as equivalent to H3_NO_ERROR (extensions).  Implementations
SHOULD select an error code from this space with some probability
when they would have sent H3_NO_ERROR.
Paragraph (version B):
Additionally, each code of the format "0x1f * N + 0x21" for integer
values of N (that is, "0x21", "0x40", ..., through
"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
Draft: draft-ietf-quic-http

Commentary: using mostly the text proposed in that issue . 
 On proposes a change to GOAWAY that reduces the exposure of the QUIC API to HTTP/3 . The paragraph in question also suggests behaviour that relies on exposure of QUIC transport information : . This seems to be the only occurence of round - trip time in the HTTP/3 document . I think we can editorialize ourselves out of this . For some HTTP/3 implementations , the RTT could be readily accessible , for others maybe not . 
 The other issue of the last two sentences ( quoted below ) is that they do not suggest how an endpoint should choose last Stream ID of the second GOAWAY frame . 
 Regarding how we should change , maybe something like below would be sufficient . My observation is that we can drop " at least one round - trip time " because the text that directly precede that implies that already . " After allowing time for any in - flight requests to reach the server , the server MAY send another GOAWAY frame that carries the greatest request stream ID it has seen . This ensures that a connection can be cleanly shut down without losing requests . " 
 The text implies a little bit of interaction with the QUIC Stream ID space . Because we had to change GOAWAY to signal the first unprocessed Stream ID , the HTTP layer needs to be able to get " the next " stream ID from QUIC in a given space . But as to the general issue , I do n't object to removing the specific dependency ; anyone reading should be able to conclude that you need to allow an RTT for the requests to arrive , and if they have access to that value , they 'll use it . 
 Seems alright . Thanks !
Paragraph (version A):
A server that is attempting to gracefully shut down a connection can
send an initial GOAWAY frame with the last Stream ID set to the
maximum possible value for a client-initiated, bidirectional stream
(i.e. 2^62-4 in case of QUIC version 1).  This GOAWAY frame signals
to the client that shutdown is imminent and that initiating further
requests is prohibited.  After allowing time for any in-flight
requests (at least one round-trip time), the server would send
another GOAWAY frame with an updated last Stream ID.  This ensures
that a connection can be cleanly shut down without causing requests
to fail.
Paragraph (version B):
A server that is attempting to gracefully shut down a connection can
send an initial GOAWAY frame with the last Stream ID set to the
maximum possible value for a client-initiated, bidirectional stream
(i.e. 2^62-4 in case of QUIC version 1).  This GOAWAY frame signals
to the client that shutdown is imminent and that initiating further
requests is prohibited.  After allowing time for any in-flight
requests to reach the server, the server can send another GOAWAY
frame indicating which requests it will accept before the end of the
connection.  This ensures that a connection can be cleanly shut down
without causing requests to fail.
Draft: draft-ietf-quic-transport

Commentary: From    comment on the QUIC mailing list . There might be a better way to state this , but I think this is more accurate .
Paragraph (version A):
An endpoint measures the delays intentionally introduced between when
an ack-eliciting packet is received and the corresponding
acknowledgment is sent.  The endpoint encodes this delay for the
largest acknowledged packet in the Ack Delay field of an ACK frame
(see frame-ack).  This allows the receiver of the ACK to adjust for
any intentional delays, which is important for getting a better
estimate of the path RTT when acknowledgments are delayed.  A packet
might be held in the OS kernel or elsewhere on the host before being
processed.  An endpoint MUST NOT include delays that is does not
control when populating the Ack Delay field in an ACK frame.
Paragraph (version B):
An endpoint measures the delays intentionally introduced between when
the packet with the largest packet number is received and an
acknowledgment is sent.  The endpoint encodes this delay in the Ack
Delay field of an ACK frame (see frame-ack).  This allows the
receiver of the ACK to adjust for any intentional delays, which is
important for getting a better estimate of the path RTT when
acknowledgments are delayed.  A packet might be held in the OS kernel
or elsewhere on the host before being processed.  An endpoint MUST
NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame.
Draft: draft-ietf-quic-recovery

Commentary: 9 and 4.9.1 are now 4.10 and 4.10.1 , I believe .
Paragraph (version A):
When packet protection keys are discarded (see Section 4.9 of QUIC-
TLS), all packets that were sent with those keys can no longer be
acknowledged because their acknowledgements cannot be processed
anymore.  The sender MUST discard all recovery state associated with
those packets and MUST remove them from the count of bytes in flight.
Paragraph (version B):
When packet protection keys are discarded (see Section 4.10 of QUIC-
TLS), all packets that were sent with those keys can no longer be
acknowledged because their acknowledgements cannot be processed
anymore.  The sender MUST discard all recovery state associated with
those packets and MUST remove them from the count of bytes in flight.
Paragraph (version A):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  Initial secrets however
might be destroyed sooner, as soon as handshake keys are available
(see Section 4.9.1 of QUIC-TLS).
Paragraph (version B):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  Initial secrets however
might be destroyed sooner, as soon as handshake keys are available
(see Section 4.10.1 of QUIC-TLS).
Paragraph (version A):
A client stops both sending and processing Initial packets when it
sends its first Handshake packet.  A server stops sending and
processing Initial packets when it receives its first Handshake
packet.  Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged
beyond this point.  Initial packet protection keys are discarded (see
Section 4.9.1 of QUIC-TLS) along with any loss recovery and
congestion control state (see Section 6.5 of QUIC-RECOVERY).
Paragraph (version B):
A client stops both sending and processing Initial packets when it
sends its first Handshake packet.  A server stops sending and
processing Initial packets when it receives its first Handshake
packet.  Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged
beyond this point.  Initial packet protection keys are discarded (see
Section 4.10.1 of QUIC-TLS) along with any loss recovery and
congestion control state (see Section 6.5 of QUIC-RECOVERY).
Draft: draft-ietf-quic-transport

Commentary: Section 9.4 of draft - ietf - quic - transport : An endpoint might set a separate timer when a PATHCHALLENGE is sent , which is cancelled when the corresponding PATHRESPONSE is received . If the timer fires before the PATHRESPONSE is received , the endpoint might send a new PATHCHALLENGE , and restart the timer for a longer period of time . GF : Possibly so , but what value has this timeout ? To avoid potential congestion collapse , I think this needs to be conservative enough to deal with paths with significant RTT variance , or where there is a change of base RTT . 1 sec , then 3 seconds , and then exponentially backed - off would be expected for TCP SYNs , and I suggest could be appropriate . 
 The suggestion is to move some of this text to recovery(ie : Handshakes and New Paths ) and reference that text from transport . 
 As  pointed out , this specifies a separate timer , which fits fine with the model that there 's one timer per path . 
 This can be simpler -- just add the new sentence . I 've made suggestions .
Paragraph (version A):
A sender can make exceptions for probe packets so that their loss
detection is independent and does not unduly cause the congestion
controller to reduce its sending rate.  An endpoint might set a
separate timer when a PATH_CHALLENGE is sent, which is cancelled when
the corresponding PATH_RESPONSE is received.  If the timer fires
before the PATH_RESPONSE is received, the endpoint might send a new
PATH_CHALLENGE, and restart the timer for a longer period of time.
Paragraph (version B):
A sender can make exceptions for probe packets so that their loss
detection is independent and does not unduly cause the congestion
controller to reduce its sending rate.  An endpoint might set a
separate timer when a PATH_CHALLENGE is sent, which is cancelled if
the corresponding PATH_RESPONSE is received.  If the timer fires
before the PATH_RESPONSE is received, the endpoint might send a new
PATH_CHALLENGE, and restart the timer for a longer period of time.
This timer SHOULD be set as described in Section 5.3 of QUIC-RECOVERY
and MUST NOT be more aggressive.
Draft: draft-ietf-quic-http

Commentary: As discussed in Singapore , this ties HTTP/3 to QUIC version 1 until someone writes down how another QUIC version is used . 
 We 've removed the text saying that application protocols can constrain which QUIC versions they can run over . We need to discuss where the correlation between ALPN tokens and version numbers gets considered . Some proposals discussed in Cupertino : ALPN tokens imply one specific QUIC version . This leads to a possible error case , where an ALPN token is offered / accepted over another QUIC version . Application protocols can restrict which QUIC versions they run over . This implies that the QUIC version being spoken must be considered when selecting an ALPN token . 
 Discussed with this is fine in the TLS draft , but the HTTP/3 draft needs to have a firmer opinion . Right now it says " anything with TLS 1.3 " . 
 The discussion in Singapore seemed to end with the conclusion that HTTP/3 would be defined to refer to QUIC version 1 exclusively . But we decided not to answer the broader question of what ALPN actually refers to . That was considered too broad a topic for the QUIC WG to address without involving TLS , HTTP , and others .
Paragraph (version B):
Draft versions MUST use the corresponding draft transport version as
their transport.  For example, the application protocol defined in
draft-ietf-quic-http-25 uses the transport defined in draft-ietf-
quic-transport-25.
Paragraph (version A):
HTTP/3 relies on QUIC as the underlying transport.  The QUIC version
being used MUST use TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST indicate the target domain name during
the TLS handshake.  This may be done using the Server Name Indication
(SNI) RFC6066 extension to TLS or using some other mechanism.
Paragraph (version B):
HTTP/3 relies on QUIC version 1 as the underlying transport.  The use
of other QUIC transport versions with HTTP/3 MAY be defined by future
specifications.
Paragraph (version B):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST indicate the target domain name during
the TLS handshake.  This may be done using the Server Name Indication
(SNI) RFC6066 extension to TLS or using some other mechanism.
Draft: draft-ietf-quic-transport

Commentary: Typically we use " in { { } } " or " ( see { { } } ) " , so this lines up with that .
Paragraph (version A):
This document defines QUIC Version Negotiation packets version-
negotiation, which can be used to negotiate the QUIC version used
between two endpoints.  However, this document does not specify how
this negotiation will be performed between this version and
subsequent future versions.  In particular, Version Negotiation
packets do not contain any mechanism to prevent version downgrade
attacks.  Future versions of QUIC that use Version Negotiation
packets MUST define a mechanism that is robust against version
downgrade attacks.
Paragraph (version B):
This document defines QUIC Version Negotiation packets in version-
negotiation, which can be used to negotiate the QUIC version used
between two endpoints.  However, this document does not specify how
this negotiation will be performed between this version and
subsequent future versions.  In particular, Version Negotiation
packets do not contain any mechanism to prevent version downgrade
attacks.  Future versions of QUIC that use Version Negotiation
packets MUST define a mechanism that is robust against version
downgrade attacks.
Draft: draft-ietf-quic-transport

Commentary: Make the rules on matching packets to connections consistent with our existing advice on use of zero - length connection IDs . cc for review 
 : : If only the local address is used , the described multiplexing is impossible . Multiplexing zero - length connection IDs is useful for reducing overhead when remote clients are known to not use the described features , so I think this language should be updated to refer to the 4 - tuple rather than only the local connection . 
 I do n't think that these are completely inconsistent , though there is an unstated section in those quotes from Section 5.2 : that the implementation has followed the advice and provided a unique local address where it uses a zero - length connection ID . This needs a little care , but we could just remove " local " and this would be OK , but it 's probably best to be a little less crude . 
 I think literally " the packet matches the address and port of a connection " would be much too vague , particularly due to the singular forms used . 
 Thanks !
Paragraph (version A):
If the Destination Connection ID is zero length and the packet
matches the local address and port of a connection where the endpoint
used zero-length connection IDs, QUIC processes the packet as part of
that connection.
Paragraph (version B):
If the Destination Connection ID is zero length and the addressing
information in the packet matches the addressing information the
endpoint uses to identify a connection with a zero-length connection
ID, QUIC processes the packet as part of that connection.  An
endpoint can use just destination IP and port or both source and
destination addresses for identification, though this makes
connections fragile as described in connection-id.
Draft: draft-ietf-quic-transport

Commentary: This does n't caption inline formulae , but it should cover everything else . I 've also removed instances of " as follows " in favour of direct references . 
 Thanks!Thanks for fixing this !
Paragraph (version A):
This document describes the core QUIC protocol and is structured as
follows.
Paragraph (version B):
An ACK frame is shown in ack-format.
Paragraph (version B):
ACK Ranges are structured as shown in ack-range-format.
Paragraph (version B):
ECN Counts are only parsed when the ACK frame type is 0x03.  There
are 3 ECN counts, as shown in ecn-count-format.
Paragraph (version B):
The RESET_STREAM frame is shown in fig-reset-stream.
Paragraph (version B):
The STOP_SENDING frame is shown in fig-stop-sending.
Paragraph (version B):
The CRYPTO frame is shown in fig-crypto.
Paragraph (version B):
The NEW_TOKEN frame is shown in fig-new-token.
Paragraph (version B):
The STREAM frames are shown in fig-stream.
Paragraph (version B):
The MAX_DATA frame is shown in fig-max-data.
Paragraph (version B):
The MAX_STREAM_DATA frame is shown in fig-max-stream-data.
Paragraph (version B):
The DATA_BLOCKED frame is shown in fig-data-blocked.
Paragraph (version B):
The STREAM_DATA_BLOCKED frame is shown in fig-stream-data-blocked.
Paragraph (version B):
The STREAMS_BLOCKED frames are shown in fig-streams-blocked.
Paragraph (version B):
The NEW_CONNECTION_ID frame is shown in fig-new-connection-id.
Paragraph (version B):
The RETIRE_CONNECTION_ID frame is shown in fig-retire-connection-id.
Paragraph (version B):
The PATH_CHALLENGE frame is shown in fig-path-challenge.
Paragraph (version B):
The CONNECTION_CLOSE frames are shown in fig-connection-close.