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

Commentary: S 5.1 . says At minimum this needs to be restricted to endpoints and other elements associated with them ( like load balancers ) because they need to be able to correlate connection IDs . But this is also a very strong condition , and in some cases will basically mandate encryption . 
 It should contain " by an external observer " . I believe there is other text mentioning coordination with load balancers when constructing CID 's . It is a strong condition - without it all other work on preventing linkage is more or less useless . 
 It feels strange to me that this is an RFC8174 MUST NOT , as it 's unclear how to enforce it . That said , I agree that this text should be constrained to external observers - and clearly define who that is . 
 Maybe change to “ Connection IDs MUST NOT expose ” ? 
 Tokyo conclusion : describe what the attack is and explain that anti - correlation text exists as an answer to this . The normative language is perhaps too strong , given that it might be possible to create smaller anonymity sets and still have a reasonable answer to the attack . 
 Discussed in London , to resume work 
 how is this progressing ? 
 I believe this is an editorial issue , not design . We all know what we mean : it can encode information by use for itself and trusted intermediaries , but definitely is not correlatable . I agree that MUST is a little tricky unless we are mandating either true encryption or true randomness , which is a discussion I was hoping to defer until QUIC - LB is adopted . 
 Looks fine . This paragraph is wrapped to a shorter line - length than the standard for the document .
Paragraph (version A):
Connection IDs MUST NOT contain any information that can be used by
an external observer to correlate them with other connection IDs for
the same connection.  As a trivial example, this means the same
connection ID MUST NOT be issued more than once on the same
connection.
Paragraph (version B):
Connection IDs MUST NOT contain any information that can be used by
an external observer (that is, one that does not cooperate with the
issuer) to correlate them with other connection IDs for the same
connection.  As a trivial example, this means the same connection ID
MUST NOT be issued more than once on the same connection.
Draft: draft-ietf-quic-recovery

Commentary: Now that the PTO retransmits Initial and Handshake data , it 's possible and likely desirable to bundle multiple QUIC packets in a single datagram . This change makes it clear that is allowed . 
 nits , but lgtm
Paragraph (version A):
A Probe Timeout (PTO) triggers sending one or two probe packets when
ack-eliciting packets are not acknowledged within the expected period
of time or the handshake has not been completed.  A PTO enables a
connection to recover from loss of tail packets or acks.  The PTO
algorithm used in QUIC implements the reliability functions of Tail
Loss Probe TLP RACK, RTO RFC5681 and F-RTO algorithms for TCP
RFC5682, and the timeout computation is based on TCP's retransmission
timeout period RFC6298.
Paragraph (version B):
A Probe Timeout (PTO) triggers sending one or two probe datagrams
when ack-eliciting packets are not acknowledged within the expected
period of time or the handshake has not been completed.  A PTO
enables a connection to recover from loss of tail packets or
acknowledgements.  The PTO algorithm used in QUIC implements the
reliability functions of Tail Loss Probe TLP RACK, RTO RFC5681 and
F-RTO algorithms for TCP RFC5682, and the timeout computation is
based on TCP's retransmission timeout period RFC6298.
Paragraph (version A):
When a PTO timer expires, a sender MUST send at least one ack-
eliciting packet as a probe, unless there is no data available to
send.  An endpoint MAY send up to two ack-eliciting packets, to avoid
an expensive consecutive PTO expiration due to a single packet loss.
Paragraph (version B):
When a PTO timer expires, a sender MUST send at least one ack-
eliciting packet as a probe, unless there is no data available to
send.  An endpoint MAY send up to two full-sized datagrams containing
ack-eliciting packets, to avoid an expensive consecutive PTO
expiration due to a single lost datagram.
Draft: draft-ietf-quic-http

Commentary: Is it worth adding a reference to RFC 8441 ? That 's an alternative that covers what people looking for this functionality were probably trying to do . 
 That 's a good point , let me craft something up and I 'll update the PR soon . 
 Ping unless you 'd like me to take it over . 
 I 'll get an update out tomorrow 
 I 'm actually not convinced that referencing 8441 will help clarify things here because the extension is H2 specific . No H3 - equivalent exists ( or at least , no H3 setting to enable the equivalent CONNECT behaviour exists ) . 
 I agree . I think referencing 8441 might just add to the confusion - even if something like 8441 certainly can be introduced . 
 Some others have shown interest for defining / framing this capability in HTTP/3 . I think that activity should consider ore broadly what text makes sense in the core document . 
 Fair enough . Let 's merge the rebased version , then , and leave the right way to do this for an H3 extension . 
 HTTP/3 makes no explicit comment about this . HTTP/2 prohibits it . So I think that we might want to add equivalent text . informational status code ( [ RFC7231 ] , Section 6.2.2 ) . multiplexed protocol .
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (RFC7230,
Section 6.7) or 101 (Switching Protocols) informational status code
(RFC7231, Section 6.2.2).
Draft: draft-ietf-quic-tls

Commentary: Issue observes that this text mentions HTTP/2 , which is n't necessary . In reviewing it , I noticed that this talks about messages that do nothing , but not really about messages that do little ( or that can be reversed to have net zero effect ) . So I expanded the text a little . 
 Thanks for improving the section 's clarity . As a follow up question , when implementations decide that excessive packets is an attack , is there a recommended actionable ( eg . sending reset , dropping the connection , do nothing ) or would that be up for implementer 's discretion ? 
 Maybe this needs to be stated explicitly , but there is no point in continuing discussion with an attacker . So while it might be considered polite to send a connection error , it is also acceptable to just drop any further incoming packets . I 'll add that here . 
 Under the section Peer Denial of Service of TLS draft , a referenced was made to HTTP/2 . I was wonder if this is in fact referring to HTTP/3 or HTTP/2 . Also curious why the section is labelled 
 That mention of h2 was a mistake . I 've made a few changes after reviewing this . ( The thing is a joke . )
Paragraph (version A):
QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses
in some contexts, but that can be abused to cause a peer to expend
processing resources without having any observable impact on the
state of the connection.  If processing is disproportionately large
in comparison to the observable effects on bandwidth or state, then
this could allow a malicious peer to exhaust processing capacity
without consequence.
Paragraph (version A):
While there are legitimate uses for some redundant packets,
implementations SHOULD track redundant packets and treat excessive
volumes of any non-productive packets as indicative of an attack.
Paragraph (version B):
QUIC and TLS both contain messages that have legitimate uses in some
contexts, but that can be abused to cause a peer to expend processing
resources without having any observable impact on the state of the
connection.
Paragraph (version B):
Messages can also be used to change and revert state in small or
inconsequential ways, such as by sending small increments to flow
control limits.
Paragraph (version B):
If processing costs are disproportionately large in comparison to
bandwidth consumption or effect on state, then this could allow a
malicious peer to exhaust processing capacity.
Paragraph (version B):
While there are legitimate uses for all messages, implementations
SHOULD track cost of processing relative to progress and treat
excessive quantities of any non-productive packets as indicative of
an attack.  Endpoints MAY respond to this condition with a connection
error, or by dropping packets.
Draft: draft-ietf-quic-transport

Commentary: As discussed , this is a ) hard to do in all cases , b ) impossible to do in many , and c ) not that useful . 
 good 
 When multiple connections share the same network path or multiple connection IDs are used for the same path , using the spin bit is complicated by the difficulty in correlating forward and reverse flows . There is currently text that uses RFC 6919 language in the draft recommending coordination of the spin to avoid this problem . However , as , this coordination seems difficult and therefore unlikely . It also creates a strong signal that indicates that all the connections on the path are terminated at the same endpoint on both ends . Maybe we do n't want to be generating that signal . Also , because this coordination ca n't be guaranteed , the on - path observer is forced to build code for correlating / segregating measurements by connection ID in the case where there is no coordination . Maybe it 's best just to remove this recommendation entirely . 
 +1 to removing the recommendation , or changing the statement to just a caution ( e.g. , if you are to coalesce connections that spin , then you 'd better be aware of ... ) . FWIW I am not sure if I agree with this observation . IIUC , the connections sharing a 5 - tuple will be terminated by the same endpoint on both ends ; it is impossible for a middlebox to coalesce multiple QUIC connections . It is impossible because CIDs can change mid - connection , and a middlebox can not determine to where the packets containing the new CID must be sent . 
 There definitely needs to be a degree of coordination between the middlebox and the endpoints , but that does n't mean that you ca n't use something like the quic - lb stuff on either end ( or both ends ) . 
 Yes , I think it is better to remove that recommendation , but perhaps replace it with a note to observers .
Paragraph (version A):
In case multiple connections share the same network path, as
determined by having the same source and destination IP address and
UDP ports, endpoints should try to co-ordinate across all connections
to ensure a clear signal to any on-path measurement points.
Draft: draft-ietf-quic-invariants

Commentary: I noticed this earlier today when trying to resolve conflicts relating to the connection ID change . 
 Suggestions accepted . 
 A couple of changes
Paragraph (version A):
The next byte contains the length in bytes of the two Connection IDs
(see connection-id) that follow.  Each length is encoded as a 4-bit
unsigned integer.  The length of the Destination Connection ID (DCIL)
occupies the high bits of the byte and the length of the Source
Connection ID (SCIL) occupies the low bits of the byte.  An encoded
length of 0 indicates that the connection ID is also 0 bytes in
length.  Non-zero encoded lengths are increased by 3 to get the full
length of the connection ID; the final value is therefore either 0 or
between 4 and 18 bytes in length (inclusive).  For example, a byte
with the value 0xe0 describes a 17 byte Destination Connection ID and
a zero byte Source Connection ID.
Paragraph (version A):
The connection ID lengths are followed by two connection IDs.  The
connection ID associated with the recipient of the packet (the
Destination Connection ID) is followed by the connection ID
associated with the sender of the packet (the Source Connection ID).
Paragraph (version B):
The next byte contains the length in bytes of the Destination
Connection ID (see connection-id) field that follows it.  This length
is encoded as an 8-bit unsigned integer.  The Destination Connection
ID field follows the DCID Len field and is between 0 and 255 bytes in
length.
Paragraph (version B):
The next byte contains the length in bytes of the Source Connection
ID field that follows it.  This length is encoded as a 8-bit unsigned
integer.  The Source Connection ID field follows the SCID Len field
and is between 0 and 255 bytes in length.
Paragraph (version A):
The byte following the version contains the lengths of the two
connection ID fields that follow it.  These lengths are encoded as
two 4-bit unsigned integers.  The Destination Connection ID Length
(DCIL) field occupies the 4 high bits of the byte and the Source
Connection ID Length (SCIL) field occupies the 4 low bits of the
byte.  An encoded length of 0 indicates that the connection ID is
also 0 bytes in length.  Non-zero encoded lengths are increased by
3 to get the full length of the connection ID, producing a length
between 4 and 18 bytes inclusive.  For example, a byte with the
value 0x50 describes an 8-byte Destination Connection ID and a
zero-length Source Connection ID.
Paragraph (version B):
The byte following the version contains the length in bytes of the
Destination Connection ID field that follows it.  This length is
encoded as an 8-bit unsigned integer.  In QUIC version 1, this
value MUST NOT exceed 20.  Endpoints that receive a version 1 long
header with a value larger than 20 MUST drop the packet.  Servers
SHOULD be able to read longer connection IDs from other QUIC
versions in order to properly form a version negotiation packet.
Draft: draft-ietf-quic-recovery

Commentary: I IANA considerations , analogous to those in the HTTP doc for the stream type . 
 We have space for private transport parameters and a process for assigning new standard transport parameters . However , since we do not apply GREASE to transport parameters , we leave ourselves open to that flexibility ossifying . I 'm happy to produce a PR to address this in the spec . 
 During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter . I think applying GREASE to transport parameters is a great idea . 
 Discussed in London , to prepare a PR 
 any progress here ? 
 I have prepared something . I can open a pr 
 sorry I totally dropped the ball here ! I had text ages ago and was circling back today finally . Thanks for seeing to it . 
 Thanks Marten!Thanks for writing this up!Need to fix the examples , but otherwise looks good .
Paragraph (version A):
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets.  The maximum ack delay is communicated in the
max_ack_delay transport parameter; see Section 18.1 of QUIC-
TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint
promises to never delay acknowledgments of an ack-eliciting packet by
more than the indicated value.  If it does, any excess accrues to the
RTT estimate and could result in spurious retransmissions from the
peer.  For Initial and Handshake packets, a max_ack_delay of 0 is
used.
Paragraph (version B):
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets.  The maximum ack delay is communicated in the
max_ack_delay transport parameter; see Section 18.2 of QUIC-
TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint
promises to never delay acknowledgments of an ack-eliciting packet by
more than the indicated value.  If it does, any excess accrues to the
RTT estimate and could result in spurious retransmissions from the
peer.  For Initial and Handshake packets, a max_ack_delay of 0 is
used.
Paragraph (version A):
New transport parameters can be used to negotiate new protocol
behavior.  An endpoint MUST ignore transport parameters that it does
not support.  Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter.
Paragraph (version B):
New transport parameters can be used to negotiate new protocol
behavior.  An endpoint MUST ignore transport parameters that it does
not support.  Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter.  As
described in transport-parameter-grease, some identifiers are
reserved in order to exercise this requirement.
Paragraph (version B):
Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored.  These transport parameters
have no semantics, and may carry arbitrary values.
Paragraph (version B):
Additionally, each value of the format "31 * N + 27" for integer
values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by
IANA.
Draft: draft-ietf-quic-tls

Commentary: Since empty STREAM frames are valid .
Paragraph (version A):
QUIC prohibits the sending of empty "STREAM" frames unless they are
marked with the FIN bit.  This prevents "STREAM" frames from being
sent that only waste effort.
Draft: draft-ietf-quic-transport

Commentary: FWIW , the state that was implied was the creation of a new connection . That 's not realistic in QUICv1 however , so this is good . 
 I 'm not following why in general this would create state . If the handshake has occurred MSL ago , and you just refuse to create state on short packets with unknown CIDs s , why is n't that enough ? 
 This was written when there was some uncertainty about what packets might look like . I think that we can truncate this sentence . Basically , you can drop state earlier , but it will mean that you wo n't be able to attribute any laggardly packets properly .
Paragraph (version A):
Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to be
handled poorly.  Endpoints that have some alternative means to ensure
that late-arriving packets on the connection do not create QUIC
state, such as those that are able to close the UDP socket, MAY use
an abbreviated draining period which can allow for faster resource
recovery.  Servers that retain an open socket for accepting new
connections SHOULD NOT exit the closing or draining period early.
Paragraph (version B):
Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to generate
an unnecessary stateless reset.  Endpoints that have some alternative
means to ensure that late-arriving packets on the connection do not
induce a response, such as those that are able to close the UDP
socket, MAY use an abbreviated draining period which can allow for
faster resource recovery.  Servers that retain an open socket for
accepting new connections SHOULD NOT exit the closing or draining
period early.
Draft: draft-ietf-quic-transport

Commentary: This consists of two related commits : Defines the minimal set of operations which a QUIC implementation MUST expose to the application , introducing terms for them which do n't rely on the specific wire formatting Changes HTTP/3 to use these terms instead of referring to specific QUIC frames Note that this does n't remove all references to QUIC frames , but the remaining references are explanatory -- they describe what will happen at the transport layer after taking a particular action , rather than being part of the normative text . ( But if you find one of these you think needs to go , please include that in this review . ) This is a design , because exposing this functionality is mandatory . I 'm not sure how you would previously have created a usable QUIC implementation without these operations , but you were n't previously required to have them all . 
 and I think this is mergeable from an HTTP standpoint . Since it 's technically a requirements change ( requiring that functionality be exposed ) , it probably needs to be marked for a consensus call when you think it 's ready . 
 Define terms for the operations which an application can cause a transport to take , and for the events of which the application can be notified by the transport . This should in the process . This issue should : Eliminate the term " trigger " when talking about QUIC frames Try not to mention specific QUIC frames at all Remove " send a QUIC RESETSTREAM " from   " sends a STOPSENDING with HTTPREQUESTCANCELLED , a server MAY send the error code HTTPREQUESTREJECTED in the corresponding RESET_STREAM " from 4.1.2 Reword references to sending values in particular transport parameters I believe those essential functions are : On the connection : Open a connection , specifying certain properties that translate to transport parameters Receive incoming connections , which will possess certain properties based on the peer 's transport parameters Participate in deciding whether to accept 0 - RTT based on embedded data Provide data to be embedded in resumption tokens Cooperate to control keep - alive , either by sending PINGs directly or by telling the transport that the connection ca n't be allowed to time out Immediate close On the stream : Read data Write data , understanding at what point flow control credit has been committed Close the sending part  closure of the receiving part The events we depend on are connection closure and stream closure . This is largely editorial , since it 's mostly defining terminology , but we 'll also likely be mandating that QUIC stacks expose these features , so that 's normative / design . ( Obviously the 0 - RTT ones will be " if implemented " requirements . ) 
 Some small suggestions , but looks good overall .
Paragraph (version B):
If the stream is in the "Recv or "Size Known" states, the transport
SHOULD signal this by sending a STOP_SENDING frame to prompt closure
of the stream in the opposite direction.  This typically indicates
that the receiving application is no longer reading data it receives
from the stream, but it is not a guarantee that incoming data will be
ignored.
Draft: draft-ietf-quic-transport

Commentary: The subject of the sentence is the singular noun value .
Paragraph (version A):
STREAM frames implicitly create a stream and carry stream data.  The
STREAM frame takes the form 0b00001XXX (or the set of values from
0x08 to 0x0f).  The value of the three low-order bits of the frame
type determine the fields that are present in the frame.
Paragraph (version B):
STREAM frames implicitly create a stream and carry stream data.  The
STREAM frame takes the form 0b00001XXX (or the set of values from
0x08 to 0x0f).  The value of the three low-order bits of the frame
type determines the fields that are present in the frame.
Draft: draft-ietf-quic-transport

Commentary: Once again , thanks !
Paragraph (version A):
Application protocol error codes are 62-bit unsigned integers, but
the management of application error codes are left to application
protocols.  Application protocol error codes are used for the
RESET_STREAM frame (frame-reset-stream), the STOP_SENDING frame
(frame-stop-sending), and the CONNECTION_CLOSE frame with a type of
0x1d (frame-connection-close).
Paragraph (version B):
Application protocol error codes are 62-bit unsigned integers, but
the management of application error codes is left to application
protocols.  Application protocol error codes are used for the
RESET_STREAM frame (frame-reset-stream), the STOP_SENDING frame
(frame-stop-sending), and the CONNECTION_CLOSE frame with a type of
0x1d (frame-connection-close).
Draft: draft-ietf-quic-tls

Commentary: A followup for an old discussion that never landed .
Paragraph (version A):
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).
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 close the connection with an
error of type 0x16d (equivalent to a fatal TLS missing_extension
alert, see tls-errors).