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

Commentary: The transport Draft states : This guidance was to the HTTP Draft in , but was subsequently removed . 
 I guess that something to discuss in the applicability draft as well 
 Looks like made this text more generic , leaving the specifics of how to keep a connection alive ( e.g. with PING frames ) to the transport implementation . The text in question is now in Section 5.1 : It 's possible the transport draft needs a similar generalization , to recommend implementations expose a way for the application layer to control whether an connection is idle . 
 Actually there is a section on " Session resumption versus Keep - alive " in the applicability draft already . Do we need to say more ? Is that needed in the transport draft as well ? 
 In , the direction of the discussion is that PING frames are an application - layer concept that wo n't necessarily be directly under the application - layer 's control . The HTTP draft currently says : This should be reworded in terms of requesting the transport stack to keep the connection from idling out , rather than directly discussing PING frames . 
 Or maybe we just need to kinds of PING ? 
 Gah ! Not more types of PING please ! 
 KEEPTHECARRUNNING frame ( ID=0xAF )
Paragraph (version A):
HTTP clients are expected to use QUIC PING frames to keep connections
open while there are responses outstanding for requests or server
pushes.  If the client is not expecting a response from the server,
allowing an idle connection to time out is preferred over expending
effort maintaining a connection that might not be needed.  A gateway
MAY use PING to maintain connections in anticipation of need rather
than incur the latency cost of connection establishment to servers.
Servers SHOULD NOT use PING frames to keep a connection open.
Paragraph (version B):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
or server pushes, as described in Section 19.2 of QUIC-TRANSPORT.  If
the client is not expecting a response from the server, allowing an
idle connection to time out is preferred over expending effort
maintaining a connection that might not be needed.  A gateway MAY
maintain connections in anticipation of need rather than incur the
latency cost of connection establishment to servers.  Servers SHOULD
NOT actively keep connections open.
Draft: draft-ietf-quic-http

Commentary: All other frame types in section 4 explicitly call out which stream types are allowed . For example DATA : If a DATA frame is received on either control stream , the recipient MUST respond with a connection error ( Section 8) of type HTTPWRONGSTREAM . 
 FWIW this is explained in section 5 . But I agree that conistency in the frame descriptions could help .
Paragraph (version A):
The PUSH_PROMISE frame (type=0x05) is used to carry a promised
request header set from server to client, as in HTTP/2.
Paragraph (version B):
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):
If a PUSH_PROMISE frame is received on either control stream, the
recipient MUST respond with a connection error (errors) of type
HTTP_WRONG_STREAM.
Draft: draft-ietf-quic-transport

Commentary: Is this just a statement about this spec or a normative requirement on future specs ? 
 It is not an invariant . 
 There 's more to requirements on future specs than invariants . 
 It 's a statement about the current version , but it would presumptively apply to extensions to the current version that do n't redefine the base spec . 
 Perhaps it 'd be better to use to avoid confusion like this .
Paragraph (version A):
All QUIC frames are idempotent.  That is, a valid frame does not
cause undesirable side effects or errors when received more than
once.
Paragraph (version B):
All QUIC frames are idempotent in this version of QUIC.  That is, a
valid frame does not cause undesirable side effects or errors when
received more than once.
Draft: draft-ietf-quic-tls

Commentary: What exists is " earlydata " extension and its " maxearlydatasize " field .
Paragraph (version A):
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket
message that contains the "max_early_data" extension with the value
0xffffffff; the amount of data which the client can send in 0-RTT is
controlled by the "initial_max_data" transport parameter supplied by
the server.  A client MUST treat receipt of a NewSessionTicket that
contains a "max_early_data" extension with any other value as a
connection error of type PROTOCOL_VIOLATION.
Paragraph (version B):
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket
message that contains the "early_data" extension with a
max_early_data_size of 0xffffffff; the amount of data which the
client can send in 0-RTT is controlled by the "initial_max_data"
transport parameter supplied by the server.  A client MUST treat
receipt of a NewSessionTicket that contains an "early_data" extension
with any other value as a connection error of type
PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: So far , we did n't use the STREAMSTATEERROR at all 
 WFM .
Paragraph (version A):
An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error PROTOCOL_VIOLATION.
Paragraph (version B):
An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
Receipt of a STOP_SENDING frame is invalid for a locally-initiated
stream that has not yet been created or is in the "Ready" state (see
stream-send-states).  Receiving a STOP_SENDING frame for a locally-
initiated stream that is "Ready" or not yet created MUST be treated
as a connection error of type PROTOCOL_VIOLATION.  An endpoint that
receives a STOP_SENDING frame for a receive-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.
Paragraph (version B):
Receipt of a STOP_SENDING frame is invalid for a locally-initiated
stream that has not yet been created or is in the "Ready" state (see
stream-send-states).  Receiving a STOP_SENDING frame for a locally-
initiated stream that is "Ready" or not yet created MUST be treated
as a connection error of type STREAM_STATE_ERROR.  An endpoint that
receives a STOP_SENDING frame for a receive-only stream MUST
terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
An endpoint that receives a STREAM frame for a send-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.
Paragraph (version B):
An endpoint that receives a STREAM frame for a send-only stream MUST
terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
An endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION.
Paragraph (version A):
An endpoint that receives a MAX_STREAM_DATA frame for a send-only
stream it has not opened MUST terminate the connection with error
PROTOCOL_VIOLATION.
Paragraph (version B):
An endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version B):
An endpoint that receives a MAX_STREAM_DATA frame for a send-only
stream it has not opened MUST terminate the connection with error
STREAM_STATE_ERROR.
Paragraph (version A):
An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION.
Paragraph (version B):
An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Draft: draft-ietf-quic-transport

Commentary: As discussed on the issue , 640k should be enough for anyone .
Paragraph (version A):
Definitions for each of the defined transport parameters are included
in transport-parameter-definitions.  Any given parameter MUST appear
at most once in a given transport parameters extension.  An endpoint
MUST treat receipt of duplicate transport parameters as a connection
error of type TRANSPORT_PARAMETER_ERROR.
Paragraph (version B):
Definitions for each of the defined transport parameters are included
in transport-parameter-definitions.  An endpoint MUST treat receipt
of a transport parameter with an invalid value as a connection error
of type TRANSPORT_PARAMETER_ERROR.  Any given parameter MUST appear
at most once in a given transport parameters extension.  An endpoint
MUST treat receipt of duplicate transport parameters as a connection
error of type TRANSPORT_PARAMETER_ERROR.
Paragraph (version A):
The maximum ACK delay is an integer value indicating the maximum
amount of time in milliseconds by which the endpoint will delay
sending acknowledgments.  This value SHOULD include the receiver's
expected delays in alarms firing.  For example, if a receiver sets
a timer for 5ms and alarms commonly fire up to 1ms late, then it
should send a max_ack_delay of 6ms.  If this value is absent, a
default of 25 milliseconds is assumed.
Paragraph (version B):
The maximum ACK delay is an integer value indicating the maximum
amount of time in milliseconds by which the endpoint will delay
sending acknowledgments.  This value SHOULD include the receiver's
expected delays in alarms firing.  For example, if a receiver sets
a timer for 5ms and alarms commonly fire up to 1ms late, then it
should send a max_ack_delay of 6ms.  If this value is absent, a
default of 25 milliseconds is assumed.  Values of 2^14 or greater
are invalid.
Draft: draft-ietf-quic-recovery

Commentary: Replaces part of Fixes part of
Paragraph (version A):
When keys for an packet number space are discarded, any packets sent
with those keys are removed from the count of bytes in flight.  No
loss events will occur any in-flight packets from that space, as a
result of discarding loss recovery state (see discard-initial).  Note
that it is expected that keys are discarded after those packets would
be declared lost, but Initial secrets are destroyed earlier.
Paragraph (version B):
When keys for a packet number space are discarded, any in-flight
packets sent with those keys are removed from the count of bytes in
flight.  Loss recovery state is also discarded, so no loss events
will occur for any in-flight packets from that space (see discard-
initial).  Note that it is expected that keys are discarded after
those packets would be declared lost, but Initial secrets are
destroyed earlier.
Paragraph (version B):
When 0-RTT is rejected, all in-flight 0-RTT packets are removed from
the count of bytes in flight.  Loss recovery state is also discarded,
so no loss events will occur for any in-flight 0-RTT packets.
Paragraph (version B):
If a server accepts 0-RTT, but does not buffer 0-RTT packets that
arrive before Initial packets, early 0-RTT packets will be declared
lost, but that is expected to be infrequent.
Draft: draft-ietf-quic-transport

Commentary: Thanks .
Paragraph (version A):
An endpoint received a STREAM frame containing data that exceeded
the previously established final offset.  Or an endpoint received
a RESET_STREAM frame containing a final offset that was lower than
the maximum offset of data that was already received.  Or an
endpoint received a RESET_STREAM frame containing a different
final offset to the one already established.
Paragraph (version B):
An endpoint received a STREAM frame containing data that exceeded
the previously established final offset.  Or an endpoint received
a STREAM frame or a RESET_STREAM frame containing a final offset
that was lower than the maximum offset of data that was already
received.  Or an endpoint received a STREAM frame or a
RESET_STREAM frame containing a different final offset to the one
already established.
Draft: draft-ietf-quic-transport

Commentary: Quoted from draft 17 , value specifying the initial flow control limit for unidirectional streams . This limit applies to newly created bidirectional streams It should be - This limit applies to newly created unidirectional ...
Paragraph (version A):
This parameter is an integer value specifying the initial flow
control limit for unidirectional streams.  This limit applies to
newly created bidirectional streams opened by the endpoint that
receives the transport parameter.  In client transport parameters,
this applies to streams with an identifier with the least
significant two bits set to 0x3; in server transport parameters,
this applies to streams with the least significant two bits set to
0x2.
Paragraph (version B):
This parameter is an integer value specifying the initial flow
control limit for unidirectional streams.  This limit applies to
newly created unidirectional streams opened by the endpoint that
receives the transport parameter.  In client transport parameters,
this applies to streams with an identifier with the least
significant two bits set to 0x3; in server transport parameters,
this applies to streams with the least significant two bits set to
0x2.
Draft: draft-ietf-quic-tls

Commentary: draft - tls typo : replace mention of packet number protection with header protection
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
packet number protection keys.
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.
Draft: draft-ietf-quic-transport

Commentary: I think the text is a leftover from time before we introduced STOP_SENDING . 
 There was an earlier draft where RST could be used for both locally and peer initiated streams . Not sure if that is relevant here .
Paragraph (version A):
The final offset is the count of the number of bytes that are
transmitted on a stream.  For a stream that is reset, the final
offset is carried explicitly in a RESET_STREAM frame.  Otherwise, the
final offset is the offset of the end of the data carried in a STREAM
frame marked with a FIN flag, or 0 in the case of incoming
unidirectional streams.
Paragraph (version B):
The final offset is the count of the number of bytes that are
transmitted on a stream.  For a stream that is reset, the final
offset is carried explicitly in a RESET_STREAM frame.  Otherwise, the
final offset is the offset of the end of the data carried in a STREAM
frame marked with a FIN flag.
Draft: draft-ietf-quic-transport

Commentary: Corrects some minor inconsistencies .
Paragraph (version A):
A stateless reset will be interpreted by a recipient as a packet with
a short header.  For the packet to appear as valid, the Random Bits
field needs to include at least 182 bits of data (or 24 bytes, less
the two fixed bits).  This is intended to allow for a Destination
Connection ID of the maximum length permitted, with a minimal packet
number, and payload.  The Stateless Reset Token corresponds to the
minimum expansion of the packet protection AEAD.  More unpredictable
bytes might be necessary if the endpoint could have negotiated a
packet protection scheme with a larger minimum AEAD expansion.
Paragraph (version B):
A stateless reset will be interpreted by a recipient as a packet with
a short header.  For the packet to appear as valid, the Random Bits
field needs to include at least 182 bits of data (or 23 bytes, less
the two fixed bits).  This is intended to allow for a Destination
Connection ID of the maximum length permitted, with a minimal packet
number, and payload.  The Stateless Reset Token corresponds to the
minimum expansion of the packet protection AEAD.  More unpredictable
bytes might be necessary if the endpoint could have negotiated a
packet protection scheme with a larger minimum AEAD expansion.
Paragraph (version A):
The Frame Type field uses a variable length integer encoding (see
integer-encoding) with one exception.  To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest
possible encoding.  Though a two-, four- or eight-byte encoding of
the frame types defined in this document is possible, the Frame Type
field for these frames is encoded on a single byte.  For instance,
though 0x4007 is a legitimate two-byte encoding for a variable-length
integer with a value of 7, PING frames are always encoded as a single
byte with the value 0x07.  An endpoint MAY treat the receipt of a
frame type that uses a longer encoding than necessary as a connection
error of type PROTOCOL_VIOLATION.
Paragraph (version B):
The Frame Type field uses a variable length integer encoding (see
integer-encoding) with one exception.  To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest
possible encoding.  Though a two-, four- or eight-byte encoding of
the frame types defined in this document is possible, the Frame Type
field for these frames is encoded on a single byte.  For instance,
though 0x4007 is a legitimate two-byte encoding for a variable-length
integer with a value of 7, PING frames are always encoded as a single
byte with the value 0x01.  An endpoint MAY treat the receipt of a
frame type that uses a longer encoding than necessary as a connection
error of type PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-http

Commentary: Not sure if this is enough , but it enacts  's suggested fix . 
 Yup , that 's what I had in mind . 
 Why is this limited to being prior to the push stream being created , given that you specify how the server handles it if it has created the stream . 
 I do n't read this as saying that you have to avoid it . The point is that you also have to reset / STOPSENDING on the stream if it exists , so there is no real point to using CANCELPUSH in addition . 
 Sounds like the intent is that CANCELPUSH should be used between the client receiving a PUSHPROMISE and before receiving the stream ( i.e. when it is ambiguous as to whether the stream has been created by the server from the clients perspective ) . I think replacing " created " with " received " would make this more clear .
Paragraph (version A):
The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a
server push prior to the push stream being created.  The CANCEL_PUSH
frame identifies a server push by Push ID (see frame-push-promise),
encoded as a variable-length integer.
Paragraph (version B):
The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a
server push prior to the push stream being received.  The CANCEL_PUSH
frame identifies a server push by Push ID (see frame-push-promise),
encoded as a variable-length integer.
Draft: draft-ietf-quic-transport

Commentary: Gah . These numbers will haunt me ...
Paragraph (version A):
Reducing the size of a Stateless Reset below the recommended minimum
size of 37 bytes could mean that the packet could reveal to an
observer that it is a Stateless Reset.  Conversely, refusing to send
a Stateless Reset in response to a small packet might result in
Stateless Reset not being useful in detecting cases of broken
connections where only very small packets are sent; such failures
might only be detected by other means, such as timers.
Paragraph (version B):
Reducing the size of a Stateless Reset below the recommended minimum
size of 39 bytes could mean that the packet could reveal to an
observer that it is a Stateless Reset.  Conversely, refusing to send
a Stateless Reset in response to a small packet might result in
Stateless Reset not being useful in detecting cases of broken
connections where only very small packets are sent; such failures
might only be detected by other means, such as timers.
Paragraph (version A):
An endpoint can increase the odds that a packet will trigger a
Stateless Reset if it cannot be processed by padding it to at least
38 bytes.
Paragraph (version B):
An endpoint can increase the odds that a packet will trigger a
Stateless Reset if it cannot be processed by padding it to at least
40 bytes.
Draft: draft-ietf-quic-transport

Commentary: If connection for incoming packet can not be found , check whether this is a stateless reset packet . 
 states : This only works for endpoints whose SCID is zero length . If SCID is not zero length , the connection corresponding to the stateless reset packet will not be found . This latter case should be included in the stateless reset detection algorithm . 
 OK with the requested changes .
Paragraph (version A):
An endpoint detects a potential stateless reset when a packet with a
short header either cannot be decrypted or is marked as a duplicate
packet.  The endpoint then compares the last 16 bytes of the packet
with the Stateless Reset Token provided by its peer, either in a
NEW_CONNECTION_ID frame or the server's transport parameters.  If
these values are identical, the endpoint MUST enter the draining
period and not send any further packets on this connection.  If the
comparison fails, the packet can be discarded.
Paragraph (version B):
An endpoint detects a potential stateless reset when a incoming
packet with a short header either cannot be associated with a
connection, cannot be decrypted, or is marked as a duplicate packet.
The endpoint then compares the last 16 bytes of the packet with the
Stateless Reset Token provided by its peer, either in a
NEW_CONNECTION_ID frame or the server's transport parameters.  If
these values are identical, the endpoint MUST enter the draining
period and not send any further packets on this connection.  If the
comparison fails, the packet can be discarded.
Draft: draft-ietf-quic-http

Commentary: Section 2.3 , paragraph 2 still uses " hq " 
 Good spot , PR fixes this 
 Whoops !
Paragraph (version A):
QUIC connections are established as described in QUIC-TRANSPORT.
During connection establishment, HTTP/3 support is indicated by
selecting the ALPN token "hq" in the TLS handshake.  Support for
other application-layer protocols MAY be offered in the same
handshake.
Paragraph (version B):
QUIC connections are established as described in QUIC-TRANSPORT.
During connection establishment, HTTP/3 support is indicated by
selecting the ALPN token "h3" in the TLS handshake.  Support for
other application-layer protocols MAY be offered in the same
handshake.
Draft: draft-ietf-quic-transport

Commentary: Upside - down .
Paragraph (version A):
All QUIC packets except Version Negotiation and Retry packets use
authenticated encryption with additional data (AEAD) RFC5119 to
provide confidentiality and integrity protection.  Details of packet
protection are found in QUIC-TLS; this section includes an overview
of the process.
Paragraph (version B):
All QUIC packets except Version Negotiation and Retry packets use
authenticated encryption with additional data (AEAD) RFC5116 to
provide confidentiality and integrity protection.  Details of packet
protection are found in QUIC-TLS; this section includes an overview
of the process.