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

Commentary: This is an error that can be detected in frame parsing without additional context . 
 Over on we had a discussion about whether a MAXSTREAMS frame with value exceeding 2 ^ 60 generates a FRAMEENCODING or a  error . Draft 29 Section 19.11 says : corresponding type that can be opened over the lifetime of the connection . This value can not exceed 2 ^ 60 , as it is not possible to encode stream IDs larger than 2 ^ 62 - 1 . Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAMEENCODINGERROR . but as points out , Section 4.5 says with a value greater than 2 ^ 60 , this would allow a maximum stream ID that can not be expressed as a variable - length integer ; see Section 16 . If either is received , the connection MUST be closed immediately with a connection error of type STREAMLIMITERROR Meanwhile , for the STREAMSBLOCKED frame in Section 19.15 we have : I suspect both  and I are correct , bogus MAXSTREAMS can be treated as either  or FRAME_ENCODING . If so , its probably a minor editorial fix to state either / or in both the sections . 
 suggested that it should only be a FRAMEENCODINGERROR , as it 's invalid to send a MAX_STREAMS larger than 2 ^ 60 under any circumstance , regardless of connection state , and I agree that 's the clearest application of our principles . 
 I agree that requiring the use of FRAMEENOCDINGERROR is fine . Even though we occasionally allow an endpoint to use multiple error codes when there is more than one way of checking the status ( i.e.  vs.  for STREAM frames ) , the check required in this particular case is purely unrelated to the connection state . Hence my +1 . 
 I would be happy with a single error too . I 'm not fussy about the actual code used as long as the spec is clear and consistent . That means that we 'd need to reduce STREAMS_BLOCKED to one error code too , and potentially any other situation that allows either . 
 I 'm going to drop . I agree with the comments suggesting that FRAMEENCODINGERROR is the right answer . Note that you might still receive a different error , as we permit endpoints that detect multiple errors to send any that it detects , and this case clearly justifies use of STREAMLIMITERROR .
Paragraph (version A):
If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer; see integer-
encoding.  If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR; see
immediate-close.
Paragraph (version B):
If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer; see integer-
encoding.  If either is received, the connection MUST be closed
immediately with a connection error of type FRAME_ENCODING_ERROR; see
immediate-close.
Draft: draft-ietf-quic-http

Commentary: We currently say : This text has two failings : It does n't specify whether the error is a stream error or a connection error In , it was argued that this violation is easily detected , and perhaps warrants a " MUST error " instead of a " MAY error " 
 +1 to both changes from my perspective . 
 This sounds like a design issue . Since this spins off from and I 'm going to assume from past discussion that there is sufficient interest in discussing this . 
 MUST respond with a connection error SGTM . Frames are hop - by - hop ( compared to HTTP messages being end - to - end ) , therefore we can enforce this . 
 Thanks , This had shades of the tunneling discussion before , and I was n't sure on which side of that fence you 'd land . 
 Thank you for checking . As stated above , I think we can be strict regarding HTTP frames ( especially the types ) , even though I tend to think that we need to be lax about HTTP messages ( and how they are terminated ) .
Paragraph (version A):
Frame types that were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and receipt MAY be treated as an error of
type H3_FRAME_UNEXPECTED.
Paragraph (version B):
Frame types that were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and their receipt MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED.
Draft: draft-ietf-quic-transport

Commentary: This text could be read to imply that an off - path attacker is more capable than an on - path attacker , which is rarely true . What it was meant to point out was that it is easier to move traffic onto a path that you are on . What it fails to acknowledge is that it is also easier to move traffic off a path that you are on . In other words , the treatment of this in 21.12 is more thorough and we do n't need to talk about limitations .  suggested that there is some duplication between this attack and the more comprehensive analysis in 21.12 . That is true , but these serve different purposes . This is to describe attacks and the normative requirements on endpoints necessary to avoid them . The other section is a thorough and hollistic analysis . I could n't see any truly straightforward changes . That does n't mean that we wo n't find a way to clean this up , or that it would be undesirable to have fewer words , but I 've not the time for that right now . 
 I find the text in 9.3.3 confusing , because it says : Unlike the attack described in { { on - path - spoofing } } , the attacker can ensure that the new path is successfully validated . This is odd because on - path attackers are generally regarded as stronger than on - path attackers . Why ca n't an on - path attacker complete this attack . 
 I think you 're right that the text is confusing , if not quite incorrect . An on - path attacker can rewrite a source address , causing an apparent migration , but ca n't cause path validation to succeed with that source address unless it is actually on - path from both endpoints to the spoofed addresses as well . An off - path attacker which can race packets successfully can cause migration with successful path validation to a path which includes it , becoming a limited on - path attacker . This also feels slightly duplicative of 21.12.3 ; it might be worth condensing some text between these sections .
Paragraph (version A):
Unlike the attack described in on-path-spoofing, the attacker can
ensure that the new path is successfully validated.
Draft: draft-ietf-quic-transport

Commentary: Idle timeout does n't enter the draining period . Sending PING will reset both idle timeouts for both endpoints . 
 if it is expecting response data , but does not have or is unable to send application data . However , you ca n't necessarily reset your own idle_timeout that way because it only is reset when you have n't already sent an ack - eliciting packet after the last received packet . If this is about resetting the peer , then maybe editorial . If it is about resetting yourself , then this may be design . 
 This is both idle timeouts . The idea behind the rules regarding the local reset of the idle timer is that if you send an ack - eliciting packet , you will get an acknowledgment . You are required to send probes until you do . So you only reset the timeout on the first . 
 2 says that after the idle timeout expires , " the connection is silently closed and its state is discarded . " However , 10.2.1 says that the peer " might enter its draining state . " Based on 10.2 , I would not expect there to be a draining state ; the connection is simply gone , and you would get a stateless reset . Is the draining state used after the endpoints time out , or not ? 
 I need to find the issue , but we explicitly decided to not drain after idle timeout . 
 resolved this . 
 Couple of nits , but LGTM .
Paragraph (version A):
An endpoint that sends packets close to the effective timeout risks
having them be discarded at the peer, since the peer might enter its
draining state before these packets arrive.
Paragraph (version B):
An endpoint that sends packets close to the effective timeout risks
having them be discarded at the peer, since the idle timeout period
might have expired at the peer before these packets arrive.
Paragraph (version A):
An implementation of QUIC might provide applications with an option
to defer an idle timeout.  This facility could be used when the
application wishes to avoid losing state that has been associated
with an open connection, but does not expect to exchange application
data for some time.  With this option, an endpoint could send a PING
frame periodically to defer an idle timeout; see frame-ping.
Paragraph (version B):
An implementation of QUIC might provide applications with an option
to defer an idle timeout.  This facility could be used when the
application wishes to avoid losing state that has been associated
with an open connection, but does not expect to exchange application
data for some time.  With this option, an endpoint could send a PING
frame (frame-ping) periodically, which will cause the peer to restart
its idle timeout period.  Sending a packet containing a PING frame
restarts the idle timeout for this endpoint also if this is the first
ack-eliciting packet sent since receiving a packet.  Sending a PING
frame causes the peer to respond with an acknowledgment, which also
restarts the idle timeout for the endpoint.
Draft: draft-ietf-quic-transport

Commentary: Thanks , Julian !
Paragraph (version A):
A client stops both sending and processing Initial packets when it
sends its first Handshake packet.  A server stops sending and
processing Initial packets when it receives its first Handshake
packet.  Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged
beyond this point.  Initial packet protection keys are discarded (see
Section 4.11.1 of QUIC-TLS) along with any loss recovery and
congestion control state; see Section 6.4 of QUIC-RECOVERY.
Paragraph (version B):
A client stops both sending and processing Initial packets when it
sends its first Handshake packet.  A server stops sending and
processing Initial packets when it receives its first Handshake
packet.  Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged
beyond this point.  Initial packet protection keys are discarded (see
Section 4.9.1 of QUIC-TLS) along with any loss recovery and
congestion control state; see Section 6.4 of QUIC-RECOVERY.
Draft: draft-ietf-quic-http

Commentary: Ambiguous description with for user agents in : It 'd be better to remove or clarify rather than ambiguously allowing user agents with . A bit misleading expression with in This sentence looks to readers like that clients MAY send same requests on another connection even when the server keeps canceling or something regardless of clients ' requests . There should be additional sentences no matter if it 's the expected behavior or not . Some phrases in look verbose and confusingThe link in is wrong : should be replaced with . 
 These are separate issues , so let 's look at them separately : This is deliberately vague , and the reason is explicitly stated . They do n't affect the operation of the protocol , but user agents are allowed to make use of the associations in implementation - specific ways . This reflects HTTP/2 , where some browsers use the association and some do not . Here again , I 'm not seeing the problem . The requests have been canceled -- effectively " unsent " on this connection . If the client still needs to make those requests , they ca n't send them on this connection , but they MAY open a new connection . " received in a " -"contained in the " would help here , unless you had a suggestion for making it tighter . The final issue is unrelated to these drafts , and is something the  server does . If you see an incorrect reference in the text draft or Editor 's   , please do point them out .
Paragraph (version A):
Upon receipt of a GOAWAY frame, if the client has already sent
requests with a Stream ID greater than or equal to the identifier
received in a GOAWAY frame, those requests will not be processed.
Clients can safely retry unprocessed requests on a different
connection.  A client that is unable to retry requests loses all
requests that are in flight when the server closes the connection.
Paragraph (version B):
Upon receipt of a GOAWAY frame, if the client has already sent
requests with a Stream ID greater than or equal to the identifier
contained in the GOAWAY frame, those requests will not be
processed.  Clients can safely retry unprocessed requests on a
different connection.  A client that is unable to retry requests
loses all requests that are in flight when the server closes the
connection.
Paragraph (version A):
If a server receives a GOAWAY frame after having promised pushes
with a Push ID greater than or equal to the identifier received in
a GOAWAY frame, those pushes will not be accepted.
Paragraph (version B):
If a server receives a GOAWAY frame after having promised pushes
with a Push ID greater than or equal to the identifier contained
in the GOAWAY frame, those pushes will not be accepted.
Draft: draft-ietf-quic-http

Commentary: The application may reset a stream , for example , when a browser tab is closed or when the pushed resource is found in cache . It might close the connection when the application is closed . These are not errors per se , even though the term " stream error " and " connection error " is used for these events , and they have an associated " error code " .
Paragraph (version A):
QUIC allows the application to abruptly terminate (reset) individual
streams or the entire connection when an error is encountered.  These
are referred to as "stream errors" or "connection errors" and are
described in more detail in QUIC-TRANSPORT.
Paragraph (version B):
QUIC allows the application to abruptly terminate (reset) individual
streams or the entire connection; see Sections 2.4 and 5.3 of QUIC-
TRANSPORT.  These are referred to as "stream errors" or "connection
errors" (see Section 11 of QUIC-TRANSPORT) and have associated error
codes, but do not necessarily indicate a problem with the connection
or either implementation.  For example, a stream can be reset if the
requested resource is no longer needed.
Draft: draft-ietf-quic-transport

Commentary: The current structure is incorrect , because application error codes is a subsection of transport error codes , despite application error codes being disjoint from transport error codes . 
  . Thank you .
Paragraph (version A):
A variable-length integer error code which indicates the reason
for closing this connection.  A CONNECTION_CLOSE frame of type
0x1c uses codes from the space defined in error-codes.  A
CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version B):
A variable-length integer error code which indicates the reason
for closing this connection.  A CONNECTION_CLOSE frame of type
0x1c uses codes from the space defined in transport-error-codes.
A CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version A):
QUIC error codes are 62-bit unsigned integers.
Paragraph (version A):
This section lists the defined QUIC transport error codes that may be
used in a CONNECTION_CLOSE frame.  These errors apply to the entire
connection.
Paragraph (version B):
QUIC transport error codes and application error codes are 62-bit
unsigned integers.
Paragraph (version B):
This section lists the defined QUIC transport error codes that may be
used in a CONNECTION_CLOSE frame with a type of 0x1c.  These errors
apply to the entire connection.
Paragraph (version A):
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).
Paragraph (version B):
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: Thanks  ( and for the others too )
Paragraph (version A):
An attacker could guess values for packet numbers or Key Phase and
have an endpoint confirm guesses through timing side channels.
Similarly, guesses for the packet number length can be trialed and
exposed.  If the recipient of a packet discards packets with
duplicate packet numbers without attempting to remove packet
protection they could reveal through timing side-channels that the
packet number matches a received packet.  For authentication to be
free from side-channels, the entire process of header protection
removal, packet number recovery, and packet protection removal MUST
be applied together without timing and other side-channels.
Paragraph (version B):
An attacker could guess values for packet numbers or Key Phase and
have an endpoint confirm guesses through timing side channels.
Similarly, guesses for the packet number length can be tried and
exposed.  If the recipient of a packet discards packets with
duplicate packet numbers without attempting to remove packet
protection they could reveal through timing side-channels that the
packet number matches a received packet.  For authentication to be
free from side-channels, the entire process of header protection
removal, packet number recovery, and packet protection removal MUST
be applied together without timing and other side-channels.
Draft: draft-ietf-quic-http

Commentary: I totally misread this passage , so let 's make it more emphatic which side of the stream we 're talking about . 
 In Section 6.2.3 , we recommend the following about the reserved unidirectional stream types : However , this has a fatal flaw -- it recommends special handling for the grease types , which is precisely the behavior we 're trying to disincent with grease . Instead , I think we should move the recommendation to use reserved error codes to the guidance on what to do with unknown stream types , which is currently : This has the same net effect on the grease streams . The change in behavior is on actual unknown - but - real stream types , which will now get grease error codes in response . 
 +1 lets do this ( as an individual ) 
 Actually , scratch that -- it 's a misreading . This is a statement about how the sender of the stream should close them , not about behavior on receipt at all . I 'll take this as editorial to emphasize that this is purely about how to send them .
Paragraph (version A):
The payload and length of the stream are selected in any manner the
implementation chooses.  Implementations MAY terminate these streams
cleanly, or MAY abruptly terminate them.  When terminating abruptly,
the error code H3_NO_ERROR or a reserved error code (http-error-
codes) SHOULD be used.
Paragraph (version B):
The payload and length of the stream are selected in any manner the
sending implementation chooses.  When sending a reserved stream type,
the implementation MAY either terminate the stream cleanly or reset
it.  When resetting the stream, either the H3_NO_ERROR error code or
a reserved error code (http-error-codes) SHOULD be used.
Draft: draft-ietf-quic-recovery

Commentary: This is said above , but this paragraph also supplies a why .
Paragraph (version B):
Loss detection is separate per packet number space, unlike RTT
measurement and congestion control, because RTT and congestion
control are properties of the path, whereas loss detection also
relies upon key availability.
Draft: draft-ietf-quic-transport

Commentary: I noticed the 0 - RTT specific text in and thought a general clarification would be better . Conveniently , I do n't think anyone has gotten this wrong in their implementation . 
 Thanks  , this is much clearer .
Paragraph (version A):
The sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest
acknowledged packet and packet number being sent.  A peer receiving
the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher-
numbered packets have been received.  An endpoint SHOULD use a large
enough packet number encoding to allow the packet number to be
recovered even if the packet arrives after packets that are sent
afterwards.
Paragraph (version B):
Prior to receiving an acknowledgement for a packet number space, the
full packet number MUST be included.
Paragraph (version B):
After an acknowledgement is received for a packet number space, the
sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest
acknowledged packet and packet number being sent.  A peer receiving
the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher-
numbered packets have been received.  An endpoint SHOULD use a large
enough packet number encoding to allow the packet number to be
recovered even if the packet arrives after packets that are sent
afterwards.
Paragraph (version A):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete.  Consequently, a server might expect 0-RTT
packets to start with a packet number of 0.  Therefore, in
determining the length of the packet number encoding for 0-RTT
packets, a client MUST assume that all packets up to the current
packet number are in flight, starting from a packet number of 0.
Thus, 0-RTT packets could need to use a longer packet number
encoding.
Paragraph (version B):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete.
Draft: draft-ietf-quic-transport

Commentary: Specify that when the spec says that a " client only receives acknowledgments for its 0 - RTT packets once the handshake is complete " , it means " as defined in the Handshake Complete section of { { QUIC - TLS } } . " . 
 is complete . Consequently , a server might expect 0 - RTT packets to start with a However , this is not necessarily strictly true , because you might have the ACKs in 0.5RTT . Now you might say that the TLS stack reports the handshake as complete as soon as it receives Finished but that 's an implementation detail 
 I think that this is true . The server can send before then , but we require that the client not install 1 - RTT keys until it considers the handshake complete . 
 That 's not entirely true . It 's the server that needs to hold back keys ( namely , the 1 - RTT read key ) until the handshake completes . The client can use keys as soon as they become available . 
 I think is correct in sense that the following three events happen at the same moment on the client side : handshake is declared complete TLS stack provides the 1 - RTT read and write keys TLS stack provides ClientFinished 
 Martin is correct . There are two different forms of handshake completion : complete when 1rtt can be sent and received , confirmed when the peer is known to be complete . The client can not receive  acks before installing 1rtt keys , hence before hanshake is complete . 
 We 've generally used section numbers for this .
Paragraph (version A):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete.
Paragraph (version B):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete, as defined Section 4.1.1 of QUIC-TLS.