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

Commentary: This was always intended ( and also written in the description of FRAMEENCODINGERROR ) , but did n't show up in the text somehow . 
 I agree with about the MUSTs that you shuffled around are statements of fact , not interoperability requirements , but the addition is fine .
Paragraph (version A):
QUIC payloads MUST contain at least one frame, and MAY contain
multiple frames and multiple frame types.
Paragraph (version B):
QUIC payloads MUST contain at least one frame, and MAY contain
multiple frames and multiple frame types.  Frames MUST fit within a
single QUIC packet and MUST NOT span a QUIC packet boundary.
Paragraph (version B):
An endpoint MUST treat the receipt of a frame of unknown type as a
connection error of type FRAME_ENCODING_ERROR.
Draft: draft-ietf-quic-transport

Commentary: For 
 This is talking about the case of being in " Data Recvd " and therefore ignoring RESETSTREAM . Should the last sentence instead read : " In the latter case , the receiving part of the stream remains in " Data Recvd " ? 
 That sounds right .
Paragraph (version A):
It is possible that all stream data is received when a RESET_STREAM
is received (that is, from the "Data Recvd" state).  Similarly, it is
possible for remaining stream data to arrive after receiving a
RESET_STREAM frame (the "Reset Recvd" state).  An implementation is
free to manage this situation as it chooses.  Sending RESET_STREAM
means that an endpoint cannot guarantee delivery of stream data;
however there is no requirement that stream data not be delivered if
a RESET_STREAM is received.  An implementation MAY interrupt delivery
of stream data, discard any data that was not consumed, and signal
the receipt of the RESET_STREAM immediately.  Alternatively, the
RESET_STREAM signal might be suppressed or withheld if stream data is
completely received and is buffered to be read by the application.
In the latter case, the receiving part of the stream transitions from
"Reset Recvd" to "Data Recvd".
Paragraph (version B):
It is possible that all stream data is received when a RESET_STREAM
is received (that is, from the "Data Recvd" state).  Similarly, it is
possible for remaining stream data to arrive after receiving a
RESET_STREAM frame (the "Reset Recvd" state).  An implementation is
free to manage this situation as it chooses.
Paragraph (version B):
Sending RESET_STREAM means that an endpoint cannot guarantee delivery
of stream data; however there is no requirement that stream data not
be delivered if a RESET_STREAM is received.  An implementation MAY
interrupt delivery of stream data, discard any data that was not
consumed, and signal the receipt of the RESET_STREAM.  A RESET_STREAM
signal might be suppressed or withheld if stream data is completely
received and is buffered to be read by the application.  If the
RESET_STREAM is suppressed, the receiving part of the stream remains
in "Data Recvd".
Draft: draft-ietf-quic-transport

Commentary: Section 6.3 says And then Section 15 defines two kinds of " reserved " versions , which makes the paragraph above ambiguous . ... Is the intent in Section 6.3 that a server SHOULD include a version that is reserved for forcing version negotiation ( i.e. , matches 0x?a?a?a?a ) , or SHOULD a server include a version reserved for future IETF consensus documents ( i.e. , matching 0x0000 ? ? ? ? ) . Or both ? 
 In my opinion having an implementation that advertises possible future standards versions without actually supporting them seems wrong , what happens if the other side actually supports this version ? This seems like it could deadlock or look like a bidding down attack in case the client moves to a lower version to resolve the deadlock . On the other hand , announcing standards versions helps to not ossify around the 0x?a?a?a?a pattern but to me announcing standards versions does not seem like a solution to this . 
 I think that some of the discussion recently has pushed us away from reserving versions for IETF use . Fixing that would make this a design issue , of course . I get the editorial point though . Doubling up on the use of " reserved " is unfortunate . 
 looks fine
Paragraph (version A):
For a server to use a new version in the future, clients must
correctly handle unsupported versions.  To help ensure this, a server
SHOULD include a reserved version (see versions) while generating a
Version Negotiation packet.
Paragraph (version A):
A client MAY send a packet using a reserved version number.  This can
be used to solicit a list of supported versions from a server.
Paragraph (version B):
For a server to use a new version in the future, clients need to
correctly handle unsupported versions.  To help ensure this, a server
SHOULD include a version that is reserved for forcing version
negotiation (0x?a?a?a?a as defined in versions) when generating a
Version Negotiation packet.
Paragraph (version B):
A client MAY send a packet using a version that is reserved for
forcing version negotiation.  This can be used to solicit a list of
supported versions from a server.
Draft: draft-ietf-quic-transport

Commentary: The transport draft states the following ( Section 4.4 ): This verbiage , introduced in PR , is ambiguous . Byte offset may refer to the Offset field in the STREAM frame ; in this case , the definition above is incorrect . What we want to say is that the final size is one higher than the offset of the byte with the largest offset sent on the stream . If no bytes were sent , the final size is zero .
Paragraph (version A):
The final size is the amount of flow control credit that is consumed
by a stream.  Assuming that every contiguous byte on the stream was
sent once, the final size is the number of bytes sent.  More
generally, this is one higher than the largest byte offset sent on
the stream.
Paragraph (version B):
The final size is the amount of flow control credit that is consumed
by a stream.  Assuming that every contiguous byte on the stream was
sent once, the final size is the number of bytes sent.  More
generally, this is one higher than the offset of the byte with the
largest offset sent on the stream, or zero if no bytes were sent.
Draft: draft-ietf-quic-tls

Commentary: I realise this may be a bit out of context for this PR , but I ca n't find any clear definition of when the handshake is complete other than this being magically spawned from the inner workings of TLS . 
 Previous discussions have established the CFIN is HoL blocking , partially because even though it 's not strictly necessary , if client auth is in use , it 's critical to receive the client 's entire Handshake flight before the server processes 1RTT packets . I do n't think the current TLS text is sufficiently clear(and normative ) about that . Section 4.1.1 has : " Important : Until the handshake is reported as complete , the connection and key exchange are not properly authenticated at the server . Even though 1 - RTT keys are available to a server after receiving the first handshake messages from a client , the server can not consider the client to be authenticated until it receives and validates the client 's Finished message . The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered . A client can avoid the potential for head - of - line blocking that this implies by sending a copy of the CRYPTO frame that carries the Finished message in multiple packets . This enables immediate server processing for those packets . " 
 I agree , perhaps this section needs to say something along the lines of : 
 How is this not a duplicate of ? 
 Nevermind , I can fix this easily .
Paragraph (version A):
Until the handshake is reported as complete, the connection and
key exchange are not properly authenticated at the server.  Even
though 1-RTT keys are available to a server after receiving the
first handshake messages from a client, the server cannot consider
the client to be authenticated until it receives and validates the
client's Finished message.
Paragraph (version B):
Until the handshake is reported as complete, the connection and
key exchange are not properly authenticated at the server.  Even
though 1-RTT keys are available to a server after receiving the
first handshake messages from a client, the server cannot consider
the client to be authenticated until it receives and validates the
client's Finished message.  A server MUST NOT process 1-RTT
packets until the handshake is complete.  A server MAY buffer or
discard 1-RTT packets that it cannot read.
Draft: draft-ietf-quic-transport

Commentary: I know that we made this a design issue , and these do change 2119 language , but those normative requirements were implied anyway . That is , the text used can not vs. MUST NOT . 
 Furthermore , SHOULD I do some sort of rate control to avoid sending 1 SR per packet ? I was also wondering about the rate limit in SR - I too thought it was there . But now , after thinking a bit , the rate limit was probably removed because it is a DoS vector . It can force state to maintained where it is not wanted . 
 This is a weird statement to make . It is absolutely the place of the spec to do that ! If what you mean is that this is entirely optional , then I 'm happy to make it a MAY . My concern is not so much what level of force the spec uses , just that the level of force is clear . 
 Before I merge this , might want to check that I 'm not making technical changes . ( There is new 2119 language , but my view is that this is converting from implied to express , but I want to give a chance to run a consensus call if you think that 's appropriate . ) 
 Those sorts of conversions have surprised people before , and is design anyway , so let 's do run that consensus call . If it 's ready to go , add and we 'll run it up the virtual flagpole . 
 take a look at what I just proposed . 
 While there are some prohibitions , and an explicit MAY for responding to   , there is no normative statement for the usual use case for Stateless Reset . I believe it 's a SHOULD , but maybe someone thinks it 's a MUST . Relatedly , in 10.4.1 , MUST we attempt to detect   , or MAY endpoints just drop after decrypt failure ? At the end of 10.4.2 , MUST we not reuse connection IDs if there 's a static key ? ( I think the answer is yes ) 
 Thanks , this LGTM.Thank you , this addresses the original issue . One nit below .
Paragraph (version B):
A stateless reset token is used in verifying a stateless reset,
see stateless-reset.  This parameter is a sequence of 16 bytes.
This transport parameter MUST NOT be sent by a client, but MAY be
sent by a server.  A server that does not send this transport
parameter cannot use stateless reset (stateless-reset) for the
connection ID negotiated during the handshake.
Draft: draft-ietf-quic-transport

Commentary: got messed up with my latest update . Suggesting closing that PR and discussing it here instead . 
 This does n't seem to have any changes related to the reviews on ? 
 There are several changes , removed text on allowing administrators to explicitly enable spinning on particular connections . Updated structure and clearer text compared to . I now also text clarifying that it is OPTIONAL to implement spin bit . 
 I 'm going to merge this soon , with one very important change and one editorial one . I'd like to make some editorial changes , but let 's get this in and we can iron it out later .
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 Unpredictable
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 B):
A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer.  The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame.  The "ack_delay_exponent" defaults
to 3, or a multiplier of 8 (see transport-parameter-definitions).
Scaling in this fashion allows for a larger range of values with a
shorter encoding at the cost of lower resolution.
Draft: draft-ietf-quic-tls

Commentary: All of them have defaults . 
 If you mean " Is sending  mandatory " , I do n't think so . An endpoint that does n't receive a TP assumes the default value . An endpoint that uses a default value does not need to advertise it . 
 The issue could have been more precisely worded . The question was about the entire QUIC transport parameters extension . Individual parameters are still clearly optional . We should be very crisp about that . Up until -18 , this was mandatory , but we do n't need the version parameters any more . 
 One nice property of making the TLS transport parameters extensions mandatory is that it helps mitigate cross - protocol attacks : QUIC servers can abort the connection if it 's missing and TLS over TCP servers can abort if the extension is present . 
 I think we can call the entire extension as an option . As to point , I 'm not sure if it helps in practice . TLS 1.3 stacks that run on top of TCP does not have ( and it 's doubtful if all of them would have ) the capability to detect and raise an error when it sees the QUIC TP extension . 
 Our defense for cross - protocol attacks is ALPN . Then key separation , and probably other things . While layers of defense is generally a good idea , transport parameters do n't need to be another secondary layer . 
 I agree with and points . This was more of a belt - and - suspenders approach . That said , I still think every single deployment will actually send transport parameters , therefore requiring the extension to be present sounds simpler to implement . But I do n't feel too strongly about this . 
 The question arose when we realized that you can have a perfectly functional stack with the defaults . And it was non- trivial sending any . However , if the client does n't send any , it prevents the server from sending any . That seems bad . 
 That argument is more compelling than mine . 
 Discussed in Prague ; no pushback against making them mandatory . 
 can you make that into a PR ? 
 There already is a PR , it just was n't tagged properly as closing this issue .
Paragraph (version A):
The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake.
Paragraph (version B):
The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake.  Endpoints
MUST send the quic_transport_parameters extension; endpoints that
receive ClientHello or EncryptedExtensions messages without the
quic_transport_parameters extension MUST terminate the TLS handshake
with a fatal missing_extension alert (an error of 0x16d).
Draft: draft-ietf-quic-transport

Commentary: concurrent - streams TP is long dead 
 OK with changes . LGTM
Paragraph (version A):
The number of active streams is limited by the concurrent stream
limit transport parameter, as explained in controlling-concurrency.
If chosen judiciously, this limit mitigates the effect of the stream
commitment attack.  However, setting the limit too low could affect
performance when applications expect to open large number of streams.
Paragraph (version B):
The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in controlling-concurrency.  If chosen
judiciously, these limits mitigate the effect of the stream
commitment attack.  However, setting the limit too low could affect
performance when applications expect to open large number of streams.
Draft: draft-ietf-quic-transport

Commentary: Saying it " terminates a stream " dangerously makes it sound like it has the same meaning as HTTP/2 , which is false . 
 Thanks for all these little patches Martin , they are a real help .
Paragraph (version A):
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
terminate a stream.
Paragraph (version B):
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
terminate the sending part of a stream.
Draft: draft-ietf-quic-transport

Commentary: missing prepositions
Paragraph (version A):
A variable-length integer representing the total number packets
received with the ECT(0) codepoint.
Paragraph (version A):
A variable-length integer representing the total number packets
received with the ECT(1) codepoint.
Paragraph (version A):
A variable-length integer representing the total number packets
received with the CE codepoint.
Paragraph (version B):
A variable-length integer representing the total number of packets
received with the ECT(0) codepoint.
Paragraph (version B):
A variable-length integer representing the total number of packets
received with the ECT(1) codepoint.
Paragraph (version B):
A variable-length integer representing the total number of packets
received with the CE codepoint.
Draft: draft-ietf-quic-transport

Commentary: Some infrastructures are likely to load balance on port as well as address . 
 " Address " has been taken to mean IP and port in other contexts , but no harm in being extra precise here .
Paragraph (version A):
The disable migration transport parameter is included if the
endpoint does not support connection migration (migration).  Peers
of an endpoint that sets this transport parameter MUST NOT send
any packets, including probing packets (probing), from a local
address other than that used to perform the handshake.  This
parameter is a zero-length value.
Paragraph (version B):
The disable migration transport parameter is included if the
endpoint does not support connection migration (migration).  Peers
of an endpoint that sets this transport parameter MUST NOT send
any packets, including probing packets (probing), from a local
address or port other than that used to perform the handshake.
This parameter is a zero-length value.
Draft: draft-ietf-quic-transport

Commentary: Updating a little old text . 
 Nice .
Paragraph (version A):
The frame types defined in this specification are listed in frame-
types.  The Frame Type in STREAM frames is used to carry other frame-
specific flags.  For all other frames, the Frame Type field simply
identifies the frame.  These frames are explained in more detail in
frame-formats.
Paragraph (version B):
The frame types defined in this specification are listed in frame-
types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED,
and CONNECTION_CLOSE frames is used to carry other frame-specific
flags.  For all other frames, the Frame Type field simply identifies
the frame.  These frames are explained in more detail in frame-
formats.
Draft: draft-ietf-quic-transport

Commentary: Builds on . 
 Initial packets need to be in 1200 byte datagrams for DoS amplification reasons . We have an exception for the case where an ACK for a Handshake packet has been received from the peer . In that case , we remove the requirement to pad . That condition is extraordinarily obscure , especially if we are suggesting that endpoints not send any more Initial packets once they have Handshake keys . Removing this text is the right answer . 
 +1 to the proposed resolution .
Paragraph (version A):
Clients MUST ensure that UDP datagrams containing Initial packets are
sized to at least 1200 bytes, adding padding to packets in the
datagram as necessary.  Once a client has received an acknowledgment
for a Handshake packet it MAY send smaller datagrams.  Sending padded
datagrams ensures that the server is not overly constrained by the
amplification restriction.
Paragraph (version B):
Clients MUST ensure that UDP datagrams containing only Initial
packets are sized to at least 1200 bytes, adding padding to packets
in the datagram as necessary.  Sending padded datagrams ensures that
the server is not overly constrained by the amplification
restriction.
Draft: draft-ietf-quic-transport

Commentary:  ? 
 One suggestion , but looks good overall .
Paragraph (version A):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  Stream IDs are unique to a stream.  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.  Stream
IDs are encoded as variable-length integers (see integer-encoding).
Paragraph (version B):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection.  Stream IDs
are encoded as variable-length integers (see integer-encoding).  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.
Draft: draft-ietf-quic-http

Commentary: in the PRIORITY frame 
 I agree , this does n't seem to mesh with the discussion on the issue . If nothing else , it introduces the inconsistency pointed out , but the gist of the issue seems to be that a receiver MAY check that it 's zero . 
 Are you in favor of changing MUST to MAY , should I discard the PR , or have I misunderstood your comment completely ? 
 MUST = MAY 
 PR kicked up a bit more controversy than expected , so I 'm opening an issue . Currently he Empty bits it the PRIORITY frame MUST be zero and MUST be ignored by the receiver . In most other areas , we 're killing connections for this kind of violation . Then again , HTTP/3 is a different protocol from QUIC . What do people think ? 
 Closing the connection SGTM . 
 I can live with must be zero and connection error if not . 
 Which means drop requirement to ignore them . 
 I 'd keep the requirement to ignore them on receipt -- why require more unnecessary checking ? 
 That works , but then state that their value is completely meaningless and should not be interpreted as anything 
 you want to add verbiage in addition to this ? 
 Looking back to HTTP/2 , it had this to say about in - frame PADDING in DATA frames . Padding octets MUST be set to zero when sending . A receiver is not obligated to verify padding but MAY treat non - zero padding as a connection error ( Section 5.4.1 ) of type PROTOCOL_ERROR . 
 That is probably OK here as well . Though the need is less acute for a 4 bit field . Padding in DATA can be arbitrarily large . Either way , the hope would be that at least a few implementations check and enforce . 
 I do n't see how this agrees with the field requirement that empty bits are ignored Empty : A four - bit field which MUST be zero when sent and MUST be ignored on receipt .
Paragraph (version A):
zero MUST be treated as a connection error of type
HTTP_MALFORMED_FRAME.
Paragraph (version B):
zero MAY be treated as a connection error of type
HTTP_MALFORMED_FRAME.
Draft: draft-ietf-quic-http

Commentary: I believe UNEXPECTED_FRAME is the preferred type . 
 I actually prefer the wording in duplicate push section and wonder if we should port that to PUSH_PROMISE too
Paragraph (version A):
A client MUST NOT send a DUPLICATE_PUSH frame.  A server MUST treat
the receipt of a DUPLICATE_PUSH frame as a connection error of type
HTTP_MALFORMED_FRAME.
Paragraph (version B):
A client MUST NOT send a DUPLICATE_PUSH frame.  A server MUST treat
the receipt of a DUPLICATE_PUSH frame as a connection error of type
HTTP_UNEXPECTED_FRAME.