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

Commentary: This does n't add rationale . It does n't have to . The rationale is n't high - minded , it 's just motivated by a desire to complete this protocol . 
 Should the server just ignore it , or is is a protocol violation ? 
 I vote for protocol violation . 
 The spec says nothing ... 
 Yeah , there 's no need to vote , this is just an omission . A protocol violation ( or similar ) is what we should mandate . 
 Playing devils ' advocate : what about p2p apps ? The token says , you can call me back from that address , I will accept it . The client is not saying anything untrue . 
 I 'll bite . Yes , a P2P app that used mutual authentication in a way that would allow a former server to associate a token with an attempt to connect to a peer that was previously a client , might be able to use NEW_TOKEN . That 's a little outside our remit . I 'm going to take this as an editorial change on the understanding that a design issue could be opened to allow the asymmetry . Anyone who is serious about that should also consider the fact that NewSessionTicket in TLS is potentially symmetrical by the same logic . Which suggests that 0 - RTT is n't out of the question either . 
 On p2p there is the potential problem of relating a token to previously stored settings and observables from a previous session . This is n't well defined if the client specifies a new token . So perhaps it is better for each peer to " waste " a single 1 - RTT connection the first time in a given direction .
Paragraph (version B):
Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt
of a NEW_TOKEN frame as a connection error of type
PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-http

Commentary: I assume the intention was to forbid the same setting identifier occurring multiple times in a SETTINGS frame , regardless of the values . However , since a parameter is defined as an identifier - value pair , the current text does not forbid duplicate identifiers if the values are different . 
 An alternative below . But this is good either way . Looks fine to me , modulo the line length .
Paragraph (version A):
Parameters MUST NOT occur more than once in the SETTINGS frame.  A
receiver MAY treat the presence of the same parameter more than once
as a connection error of type HTTP_SETTINGS_ERROR.
Paragraph (version B):
The same setting identifier MUST NOT occur more than once in the
SETTINGS frame.  A receiver MAY treat the presence of duplicate
setting identifiers as a connection error of type
HTTP_SETTINGS_ERROR.
Draft: draft-ietf-quic-transport

Commentary: Byte order of IP addresses in PreferredAddress is not explicitly stated . In practice , most OSs keep them in network byte order , and the spec says integers are in network byte order , however the fields for ip addresses are defined as opaque data . The byte order should be stated on this spec .
Paragraph (version A):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  The format of this transport parameter is the
PreferredAddress struct shown in fig-preferred-address.  This
transport parameter is only sent by a server.  Servers MAY choose
to only send a preferred address of one address family by sending
an all-zero address and port (0.0.0.0:0 or ::.0) for the other
family.
Paragraph (version B):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  The format of this transport parameter is the
PreferredAddress struct shown in fig-preferred-address.  This
transport parameter is only sent by a server.  Servers MAY choose
to only send a preferred address of one address family by sending
an all-zero address and port (0.0.0.0:0 or ::.0) for the other
family.  IP addresses are encoded in network byte order.
Draft: draft-ietf-quic-http

Commentary: The initial request was simply to add sub - headings . I still feel like Security Considerations is a bit of a hodge - podge , and would welcome concrete suggestions or PRs for tightening it up . 
 Can you add a sub - heading ( # # ) for each of these considerations , like in the transport draft ? Originally posted by in
Paragraph (version A):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS.  Note that where HTTP/2 employs PADDING frames
and Padding fields in other frames to make a connection more
resistant to traffic analysis, HTTP/3 can either rely on transport-
layer padding or employ the reserved frame and stream types discussed
in frame-grease and stream-grease.
Paragraph (version B):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS; the considerations from Section 10 of HTTP2 apply
in addition to those listed here.
Paragraph (version B):
Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in frame-grease and stream-
grease.  These methods of padding produce different results in terms
of the granularity of padding, the effect of packet loss and
recovery, and how an implementation might control padding.
Draft: draft-ietf-quic-http

Commentary: I went with " Default " because that and " Initial Value " now have specific , related ( but distinct ) usages in the context of pre - SETTINGS settings . Swapping them seems like it would create unnecessary confusion . 
 Yeah that makes sense on a reread of section 7.2.5.2 
 Not a new issue but : RFC 7540 has a column for . I think it makes sense that HTTP/3 does similar . Originally posted by in
Paragraph (version B):
The value of the setting unless otherwise indicated.  SHOULD be
the most restrictive possible value.
Draft: draft-ietf-quic-qpack

Commentary: On receiving duplicate QPACK streams , the error should be  which matches with control stream duplicates . 
 Technically should have a corresponding issue , but yes . Nice spot !
Paragraph (version A):
HTTP/3 endpoints contain a QPACK encoder and decoder.  Each endpoint
MUST initiate at most one encoder stream and at most one decoder
stream.  Receipt of a second instance of either stream type MUST be
treated as a connection error of type HTTP_WRONG_STREAM_COUNT.  These
streams MUST NOT be closed.  Closure of either unidirectional stream
type MUST be treated as a connection error of type
HTTP_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
HTTP/3 endpoints contain a QPACK encoder and decoder.  Each endpoint
MUST initiate at most one encoder stream and at most one decoder
stream.  Receipt of a second instance of either stream type MUST be
treated as a connection error of type HTTP_STREAM_CREATION_ERROR.
These streams MUST NOT be closed.  Closure of either unidirectional
stream type MUST be treated as a connection error of type
HTTP_CLOSED_CRITICAL_STREAM.
Draft: draft-ietf-quic-transport

Commentary: The Stream Commitment Attack part was in draft - ietf - quic - transport-03 , when unidirectional streams were not used . In draft - ietf - quic - transport-08 , streams were split into unidirectional and bidirectional , but this example of stream commitment attack was missed . 
 Thanks , I 've done some editorializing , and merging .
Paragraph (version A):
Normally, clients will open streams sequentially, as explained in
stream-id.  However, when several streams are initiated at short
intervals, transmission error may cause STREAM DATA frames opening
streams to be received out of sequence.  A receiver is obligated to
open intervening streams if a higher-numbered stream ID is received.
Thus, on a new connection, opening stream 2000001 opens 1 million
streams, as required by the specification.
Paragraph (version B):
Normally, clients will open streams sequentially, as explained in
stream-id.  However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence.  On receiving a higher-
numbered stream ID, a receiver is required to open all intervening
streams of the same type (see stream-recv-states).  Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.
Draft: draft-ietf-quic-transport

Commentary: Specify that ECN counts in the ACK frame to be in the same pn_space of the ACK frame . Change pseudocode in recovery - draft to reflect that . 
 This only changes pseudocode and no normative text , so I 'm inclined to mark it editorial and merge it . 
 Are ECN counts in ACK frames per pnspace or unified across pnspaces ? I 've observed different behaviors of public servers regarding that . [ 13.3.1 . ECN Counts ] seems to suggest they are per pnspace : However , [ 19.3.2 . ECN Counts ] says : Pseudocode in the recovery draft ( Appendix B. Congestion Control Pseudocode ) also has a global ecnce_counter . 
 Thanks for the issue , PR looks good . 
 Thanks ! want to take a look ?
Paragraph (version A):
A variable-length integer representing the total number of packets
received with the ECT(0) codepoint.
Paragraph (version A):
A variable-length integer representing the total number of packets
received with the ECT(1) codepoint.
Paragraph (version A):
A variable-length integer representing the total number of 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 in the packet number space of
the ACK frame.
Paragraph (version B):
A variable-length integer representing the total number of packets
received with the ECT(1) codepoint in the packet number space of
the ACK frame.
Paragraph (version B):
A variable-length integer representing the total number of packets
received with the CE codepoint in the packet number space of the
ACK frame.
Draft: draft-ietf-quic-transport

Commentary: Is that not implied by the text here ? 
 Kind of , but this text talks about the sender 's perspective . Furthermore , checking for duplicates is inherently racy if you 're using tokens for new connections while the old connection is still alive . 
 You know , I think that I put some proposed fixes for this in with rather than this branch . Moved it over here . you approved , so I hope that moving that commit over here works for you . 
 Sec 13.2 of QUIC Transport explains what to do for the loss of a packet for every stream type except NEW_TOKEN . IMO it 's nice but not critical to repair this loss , but I care less about how we resolve it than that we write it up . 
 Somewhat related question : Does this section fit better in the recovery draft ? 
 I do n't think so . This talks about the repair semantics of these frames , not the process of detecting loss . Recovery does n't care about the distinction between PING and STREAM when it comes to repair . 
 LGTM , but do we need some text saying that when receiving a NEW_TOKEN frame , you MUST make sure that it 's not a duplicate ? Otherwise , a client might just save the token twice , and effectively reuse the token .
Paragraph (version B):
NEW_TOKEN frames are retransmitted if the packet containing them
is lost.  No special support is made for detecting reordered and
duplicated NEW_TOKEN frames other than a direct comparison of the
frame contents.
Paragraph (version B):
An endpoint might receive multiple NEW_TOKEN frames that contain the
same token value.  Endpoints are responsible for discarding duplicate
values, which might be used to link connection attempts; see
validate-future.
Draft: draft-ietf-quic-transport

Commentary: Thanks !  me to it . 
 In quic - transport-22 section 19.6 it says CRYPTO frames can be sent in all packet types . However in quic - tls-22 section 4 it says the CRYPTO frames ca n't be sent in 0 - RTT packets . Also in quic - tls-22 section 8.3 , similar statement . Maybe the statement in quic - transport-22 needs to be corrected ?
Paragraph (version A):
The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages.  It can be sent in all packet types.  The CRYPTO
frame offers the cryptographic protocol an in-order stream of bytes.
CRYPTO frames are functionally identical to STREAM frames, except
that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream.
Paragraph (version B):
The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages.  It can be sent in all packet types except 0-RTT.
The CRYPTO frame offers the cryptographic protocol an in-order stream
of bytes.  CRYPTO frames are functionally identical to STREAM frames,
except that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream.
Draft: draft-ietf-quic-recovery

Commentary: Yes , this was going to be my follow up question . Also what about the ECN paragraph just below it ? 
 The current spec would not cause an ack to be triggered if non - ack - eliciting packets are received out of order . I think that 's important . If the packet that was lost was another ack - only packet , this would cause unnecessary acks , and doing this at both ends could cause a minor ack storm . out - of - order is defined in the draft above . I think it 's less than ideal , but it 's not ambiguous . I 've rephrased the ECN section just a bit to be clearer . Does that help ? 
 I 'll merge this . If folks have any pending questions , happy to take them on in a new PR . 
 What does it mean for a subsequent packet to arrive out of order ? If I received packets 10 , 11 , 13 , then clearly 13 is out of order . If I received 14 now , would that also be considered out of order ? Would 15 be?This text is moving drafts in , so it might make sense to land that first ? Or I I can pull this change in after it lands . What about the case where you receive an in order ack eliciting packet and then an out of order ack only packet ? Should you still rely on delayed ack timer or send an ack immediately ?
Paragraph (version A):
In order to accelerate loss recovery and reduce timeouts, the
receiver SHOULD send an immediate ACK after it receives an out-of-
order packet.  It could send immediate ACKs for in-order packets for
a period of time that SHOULD NOT exceed 1/8 RTT unless more out-of-
order packets arrive.  If every packet arrives out-of- order, then an
immediate ACK SHOULD be sent for every received packet.
Paragraph (version B):
In order to accelerate loss recovery and reduce timeouts, an endpoint
SHOULD immediately send an ACK frame when it receives an out-of-order
packet that is ACK-eliciting.  The endpoint MAY continue sending ACK
frames immediately on each subsequently received packet, but the
endpoint SHOULD return to acknowledging every other packet after a
period of 1/8 x RTT, unless more ACK-eliciting packets are received
out of order.  If every subsequent ACK-eliciting packet arrives out
of order, then an ACK frame SHOULD be sent immediately for every
received ACK-eliciting packet.
Paragraph (version B):
If a packet is received with the ECN Congestion Experienced (CE)
codepoint in the IP header, the endpoint SHOULD respond with an ACK
frame immediately, even if the packet is received in order.  Doing so
reduces the peer's response time to congestion events.
Paragraph (version B):
If multiple packets are already available at an endpoint, the
endpoint MAY process them all before sending an ACK frame in
response.  The endpoint can determine whether an acknowledgement
should be sent immediately or delayed after processing the batch.
Draft: draft-ietf-quic-tls

Commentary: I 'm pretty sure this was obsoleted when version negotiation was removed ( along with initial / negotiated / supported versions from transport parameters ) . If you think the TLS handshake is still validating protocol version selection , feel free to reject this PR .
Paragraph (version A):
QUIC uses the TLS handshake for more than just negotiation of
cryptographic parameters.  The TLS handshake validates protocol
version selection, provides preliminary values for QUIC transport
parameters, and allows a server to perform return routability checks
on clients.
Paragraph (version B):
QUIC uses the TLS handshake for more than just negotiation of
cryptographic parameters.  The TLS handshake provides preliminary
values for QUIC transport parameters and allows a server to perform
return routability checks on clients.
Draft: draft-ietf-quic-tls

Commentary: Mention that application data could be conveyed in other frame types than STREAM frames . ( E.g. the proposed DATAGRAM draft sends application data in DATAGRAM frames . ) 
 This was correct at the time , because only STREAM carried application semantics , but that 's too constraining , even now . Thanks .
Paragraph (version A):
Unlike TLS over TCP, QUIC applications which want to send data do not
send it through TLS "application_data" records.  Rather, they send it
as QUIC STREAM frames which are then carried in QUIC packets.
Paragraph (version B):
Unlike TLS over TCP, QUIC applications which want to send data do not
send it through TLS "application_data" records.  Rather, they send it
as QUIC STREAM frames or other frame types which are then carried in
QUIC packets.
Draft: draft-ietf-quic-qpack

Commentary: Since post - base index has a section separate from relative index , I do not consider post - base index a type of relative index , but a distinct category . Update text accordingly . If the consensus is that this is not the case , relative index and post - base index sections should be reworded , and a new term should be introduced for non - post - base relative index .
Paragraph (version A):
A reference point for relative indices.  Dynamic references are
made relative to a Base in header blocks.
Paragraph (version B):
A reference point for relative and post-base indices.  References
to dynamic table entries in header blocks are relative to a Base.
Paragraph (version A):
For example, with a Required Insert Count of 9, a decoder receives a
S bit of 1 and a Delta Base of 2.  This sets the Base to 6 and
enables post-base indexing for three entries.  In this example, a
regular index of 1 refers to the 5th entry that was added to the
table; a post-base index of 1 refers to the 8th entry.
Paragraph (version B):
For example, with a Required Insert Count of 9, a decoder receives a
S bit of 1 and a Delta Base of 2.  This sets the Base to 6 and
enables post-base indexing for three entries.  In this example, a
relative index of 1 refers to the 5th entry that was added to the
table; a post-base index of 1 refers to the 8th entry.
Draft: draft-ietf-quic-qpack

Commentary: Add MUST to sentence about requirement on decoder to emit a Header Acknowledgement instruction every time it decodes a header block with non - zero Required   . 
 That 's a good point , I have n't thought about it . Would changing " When the decoder finishes decoding ... " to " After the decoder finishes decoding ... " be sufficient to allow for delayed ACKs ? 
 Works for me . 
 Done . Thanks for raising this issue . 
 You ca n't coalesce   like you can Insert Count Increment or transport Acks . The only overhead savings comes from when these are sent to the peer - eg : transport overhead . The text only says the  , and does n't really describe how quickly it has to be conveyed . But I do n't really have a problem with when vs. after either . 
 This does n't allow for a delay in sending an ack . That delay might be useful in reducing overheads . That might be a new issue though .
Paragraph (version A):
When the decoder finishes decoding a header block containing dynamic
table references, it MUST emit a Header Acknowledgement instruction
(header-acknowledgement).  A stream may carry multiple header blocks
in the case of intermediate responses, trailers, and pushed requests.
The encoder interprets each Header Acknowledgement instruction as
acknowledging the earliest unacknowledged header block containing
dynamic table references sent on the given stream.
Paragraph (version B):
After the decoder finishes decoding a header block containing dynamic
table references, it MUST emit a Header Acknowledgement instruction
(header-acknowledgement).  A stream may carry multiple header blocks
in the case of intermediate responses, trailers, and pushed requests.
The encoder interprets each Header Acknowledgement instruction as
acknowledging the earliest unacknowledged header block containing
dynamic table references sent on the given stream.
Draft: draft-ietf-quic-qpack

Commentary: The definition of a blocking entry has two parts : insertion not acknowledged , or not all references acknowledged . Update text in two places to include the part about acknowledging the insertion , lest a reader forget about it .
Paragraph (version A):
The Header Acknowledgement and Stream Cancellation instructions
permit the encoder to remove references to entries in the dynamic
table.  When entries have zero references they are no longer
considered blocking (see blocked-insertion).
Paragraph (version B):
The Header Acknowledgement and Stream Cancellation instructions
permit the encoder to remove references to entries in the dynamic
table.  When an entry with absolute index lower than the Known
Received Count has zero references, then it is no longer considered
blocking (see blocked-insertion).
Draft: draft-ietf-quic-qpack

Commentary: Emphasize that SETTINGSQPACKBLOCKED_STREAMS is set by the decoder . Move normative sentence on decoder encountering excessive number of blocked streams to this paragraph . Split note to separate paragraph . 
 : +1 : This reads much better to me .
Paragraph (version A):
The SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration)
specifies an upper bound on the number of streams which can be
blocked.  An encoder MUST limit the number of streams which could
become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all
times.  Note that the decoder might not become blocked on every
stream which risks becoming blocked.
Paragraph (version B):
The decoder specifies an upper bound on the number of streams which
can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting (see
configuration).  An encoder MUST limit the number of streams which
could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS
at all times.  If an decoder encounters more blocked streams than it
promised to support, it MUST treat this as a connection error of type
HTTP_QPACK_DECOMPRESSION_FAILED.
Paragraph (version B):
Note that the decoder might not become blocked on every stream which
risks becoming blocked.
Paragraph (version A):
If the decoder encounters more blocked streams than it promised to
support, it MUST treat this as a connection error of type
HTTP_QPACK_DECOMPRESSION_FAILED.