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

Commentary: , requires transport stacks to support abrupt closure of a stream even after the stream has been cleanly closed . This reflects the possibility to transition from " Data Sent " ( stream has ended ) to " Reset Sent " by sending a RESETSTREAM . Based on the state diagram in the transport doc , if an implementation was already in the " Data Recvd " state , they would n't actually send a RESETSTREAM , as they 're already in a terminal state ; a reset call would be a no - op or an error of some kind . However , points out that in a handle - based API , this essentially means that handles for closed streams have to be recognizable as such for the lifetime of the connection . This might be burdensome for some implementations . Should we reword the requirement here to say that it 's permitted if the stream has n't yet reached the " Data Recvd " state . 
 This was clearly just a miss on the wording . I do n't think that the intent was ever to require that streams be kept around indefinitely . Sure , some stacks might be able to send RESET_STREAM at a whim , but it 's not necessary
Paragraph (version A):
reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (frame-reset-stream), even if the stream was already ended.
Paragraph (version B):
reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (frame-reset-stream), if the stream was not already in a
terminal state.
Paragraph (version B):
abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (frame-stop-sending).
Draft: draft-ietf-quic-recovery

Commentary: From discussion on people prefer the normative text to apply to the initial congestion window , not the specific value recommended in the recovery document . 
 I approve of this editorial change
Paragraph (version A):
Sending multiple packets into the network without any delay between
them creates a packet burst that might cause short-term congestion
and losses.  Implementations MUST either use pacing or limit such
bursts to the minimum of 10 * kMaxDatagramSize and max(2*
kMaxDatagramSize, 14720)), the same as the recommended initial
congestion window.
Paragraph (version B):
Sending multiple packets into the network without any delay between
them creates a packet burst that might cause short-term congestion
and losses.  Implementations MUST either use pacing or limit such
bursts to the initial congestion window, which is recommended to be
the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize,
14720)).
Draft: draft-ietf-quic-transport

Commentary: The use of " this " here was a bit ambiguous
Paragraph (version A):
The server includes a connection ID of its choice in the Source
Connection ID field.  This value MUST not be equal to the Destination
Connection ID field of the packet sent by the client.  A client MUST
discard a Retry packet that contains a Source Connection ID field
that is identical to the Destination Connection ID field of its
Initial packet.  The client MUST use this connection ID in the
Destination Connection ID field of subsequent packets that it sends.
Paragraph (version B):
The server includes a connection ID of its choice in the Source
Connection ID field.  This value MUST not be equal to the Destination
Connection ID field of the packet sent by the client.  A client MUST
discard a Retry packet that contains a Source Connection ID field
that is identical to the Destination Connection ID field of its
Initial packet.  The client MUST use the value from the Source
Connection ID field of the Retry packet in the Destination Connection
ID field of subsequent packets that it sends.
Draft: draft-ietf-quic-recovery

Commentary: This section was well out of date . Also , this covers what needs to be retained across this transition better . Basically , the only thing that needs to go is the congestion and loss recovery state . The rest can stay ; in fact , the crypto handshake has to stay . 
 Follow - up to . As suggests , we might want to add text to the transport draft that enumerates what is reset : all state except for connection IDs , packet numbers and , optionally , an RTT measurement . 
 Thanks , nice update !
Paragraph (version A):
A Retry or Version Negotiation packet causes a client to send another
Initial packet, effectively restarting the connection process and
resetting congestion control and loss recovery state, including
resetting any pending timers.  Either packet indicates that the
Initial was received but not processed.  Neither packet can be
treated as an acknowledgment for the Initial.
Paragraph (version A):
The client MAY however compute an RTT estimate to the server as the
time period from when the first Initial was sent to when a Retry or a
Version Negotiation packet is received.  The client MAY use this
value to seed the RTT estimator for a subsequent connection attempt
to the server.
Paragraph (version B):
A Retry packet causes a client to send another Initial packet,
effectively restarting the connection process.  A Retry packet
indicates that the Initial was received, but not processed.  A Retry
packet MUST NOT be treated as an acknowledgment.
Paragraph (version B):
Clients that receive a Retry packet reset congestion control and loss
recovery state, including resetting any pending timers.  Other
connection state, in particular cryptographic handshake messages, is
retained; see Section 17.2.5 of QUIC-TRANSPORT.
Paragraph (version B):
The client MAY compute an RTT estimate to the server as the time
period from when the first Initial was sent to when a Retry or a
Version Negotiation packet is received.  The client MAY use this
value in place of its default for the initial RTT estimate.
Draft: draft-ietf-quic-transport

Commentary: I really appreciate all of these PRs . It 's easy to miss these things with larger changes .
Paragraph (version A):
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
packet loss, however an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet.  An endpoint SHOULD NOT
send a PATH_CHALLENGE more frequently than it would an Initial
packet, ensuring that connection migration is no more load on a new
path than establishing a new connection.
Paragraph (version B):
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
packet loss.  However, an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet.  An endpoint SHOULD NOT
send a PATH_CHALLENGE more frequently than it would an Initial
packet, ensuring that connection migration is no more load on a new
path than establishing a new connection.
Draft: draft-ietf-quic-transport

Commentary: this is editorial , I believe . 
 Thanks . 
 Thanks for the fix !
Paragraph (version A):
Packet loss, in particular loss of a Handshake packet from the
server, can cause a situation in which the server cannot send when
the client has no data to send and the anti-amplification limit is
reached.  In order to avoid this causing a handshake deadlock,
clients SHOULD send a packet upon a crypto retransmission timeout, as
described in QUIC-RECOVERY.  If the client has no data to retransmit
and does not have Handshake keys, it SHOULD send an Initial packet in
a UDP datagram of at least 1200 bytes.  If the client has Handshake
keys, it SHOULD send a Handshake packet.
Paragraph (version B):
Packet loss, in particular loss of a Handshake packet from the
server, can cause a situation in which the server cannot send when
the client has no data to send and the anti-amplification limit is
reached.  In order to avoid this causing a handshake deadlock,
clients SHOULD send a packet upon a probe timeout, as described in
QUIC-RECOVERY.  If the client has no data to retransmit and does not
have Handshake keys, it SHOULD send an Initial packet in a UDP
datagram of at least 1200 bytes.  If the client has Handshake keys,
it SHOULD send a Handshake packet.
Draft: draft-ietf-quic-recovery

Commentary: As suggested by in
Paragraph (version A):
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 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 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 persistent congestion is established, the sender's congestion
window MUST be reduced to the minimum congestion window
(kMinimumWindow).  This response of collapsing the congestion window
on persistent congestion is functionally similar to a sender's
response on a Retransmission Timeout (RTO) in TCP RFC5681 after Tail
Loss Probes (TLP) TLP.
Paragraph (version B):
When persistent congestion is established, the sender's congestion
window MUST be reduced to the minimum congestion window
(kMinimumWindow).  This response of collapsing the congestion window
on persistent congestion is functionally similar to a sender's
response on a Retransmission Timeout (RTO) in TCP RFC5681 after Tail
Loss Probes (TLP) RACK.
Draft: draft-ietf-quic-qpack

Commentary: This was suggested by  at 
 Sure .
Paragraph (version A):
QPACK implementations MUST be able to decode integers up to 62 bits
long.
Paragraph (version B):
QPACK implementations MUST be able to decode integers up to and
including 62 bits long.
Draft: draft-ietf-quic-http

Commentary: At the interim , we talked about this not being an interop requirement , but " a really good idea " which still warrants RFC2119 language . So , keeping the all - caps , but taking the suggestion to make it active voice . 
 That was never an interoperability requirement , just a suggestion . So I think that this should be reverted . Originally posted by in Look at a better way to phrase this guidance , while still retaining the guidance . ( Note this text has also been touched by other PRs in the meantime . )
Paragraph (version A):
All client-initiated bidirectional streams are used for HTTP requests
and responses.  A bidirectional stream ensures that the response can
be readily correlated with the request.  This means that the client's
first request occurs on QUIC stream 0, with subsequent requests on
stream 4, 8, and so on.  In order to permit these streams to open, an
HTTP/3 server SHOULD configure non-zero minimum values for the number
of permitted streams and the initial stream flow control window.  It
is RECOMMENDED that at least 100 requests be permitted at a time, so
as to not unnecessarily limit parallelism.
Paragraph (version B):
All client-initiated bidirectional streams are used for HTTP requests
and responses.  A bidirectional stream ensures that the response can
be readily correlated with the request.  This means that the client's
first request occurs on QUIC stream 0, with subsequent requests on
stream 4, 8, and so on.  In order to permit these streams to open, an
HTTP/3 server SHOULD configure non-zero minimum values for the number
of permitted streams and the initial stream flow control window.  So
as to not unnecessarily limit parallelism, at least 100 requests
SHOULD be permitted at a time.
Draft: draft-ietf-quic-http

Commentary: The HTTP draft currently specifies Is it intentional that a client MUST remember SETTINGS values that it does n't support ( to check that the server did n't omit a setting ) ? 
 The comment about checking for omitted settings says ... " omits a value that was previously specified to have a non - default value " . In order for a client to know what the default value is for that setting , surely the client must support that setting , right ? 
 You 're right that for the client to know whether or not it 's the default value it needs to support the setting ( or at least know about it ) . Suppose the server sends SETTING BLORP ( which the client knows nothing about ) with value X in the original SETTINGS , but omits it on the 0 - RTT resumed connection . As currently specified , if value X is not the default value , the client MUST close the connection , but if it is the default value , then that 's fine . ( Meaning the client needs to know all possible default values for all possible settings . ) I think this needs an editorial fix to apply something like " a setting the client understands " to the bit about omitting a value as well . 
 Oh , I see your reading now . Interesting ! Good point about an editorial tweak . 
 I think this could affect reserved settings ( aka grease ) too , just in a slightly different way . Some editorial tweak to address the problem would be good .
Paragraph (version A):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings which differ from their default values.  If a
server accepts 0-RTT, but then sends a SETTINGS frame which reduces a
setting the client understands or omits a value that was previously
specified to have a non-default value, this MUST be treated as a
connection error of type H3_SETTINGS_ERROR.
Paragraph (version B):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings which differ from their default values.  If a
server accepts 0-RTT but then sends settings that are not compatible
with the previously specified settings, this MUST be treated as a
connection error of type H3_SETTINGS_ERROR.  If a server accepts
0-RTT but then sends a SETTINGS frame that omits a setting value that
the client understands (apart from reserved setting identifiers) that
was previously specified to have a non-default value, this MUST be
treated as a connection error of type H3_SETTINGS_ERROR.
Draft: draft-ietf-quic-http

Commentary: This changes HTTPUNEXPECTEDFRAME , which is used only once , to HTTPFRAMEUNEXPECTED that is used multiple times . 
 During the London interim , it was noted that error codes refer to things being " malformed , " " bad , " " invalid , " and " unexpected . " Pick one and use it consistently , or establish precise definitions for each . This applies to both the current document and . 
 The three words are not equivalent : while both " malformed " and " invalid " are " bad , " " malformed " is not the same as " invalid . " 
 Minor correction here , " bad " is only used in . The only instance of " bad " in current document is a substring of example " 0x1abadaba " . I 'll fix the PR before it lands , whatever order we end up doing things in . 
 The different value - judgement terms are corrected by the flurry of settings PRs that already did . HTTPFRAMEERROR has replaced malformed , and UNEXPECTEDFRAME and WRONGSTREAM are reasonably descriptive ( though see , ) . We do still have some variation between HTTPTHINGDESCRIPTOR , HTTPTHINGERROR , and HTTPDESCRIPTORTHING ( e.g. HTTPUNEXPECTEDFRAME versus HTTPREQUESTREJECTED ) that might be worth reconciling . Is it worth turning into HTTPFRAMEUNEXPECTED ? 
 Resolved by and something prior to it . 
 oops , thanks
Paragraph (version A):
Frame types which 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 HTTP_UNEXPECTED_FRAME.
Paragraph (version B):
Frame types which 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 HTTP_FRAME_UNEXPECTED.
Draft: draft-ietf-quic-http

Commentary: The constraints of 8.1.2.1 apply to all requests , but I missed that there are additional requirements in 8.1.2.3 for requests and 8.1.2.4 for responses . I 've broadened the statement to " the restrictions on the use of pseudo - headers in Section 8.1.2 " to sweep them all up . Does anyone think we need pointers to each specific subsection ? At Lucas 's suggestion , I 've also cross - referenced handling of malformed messages here , since those restrictions talk about what is malformed in a given context . 
 I 'm carefully parsing the wording in quic - http sec . 4.1.1 and do n't think it 's right : In RFC 7540 , 8.1.2.1 says This notably does NOT include the further restrictions in 8.1.2.3 : I am far from an expert on HTTP headers , but I suspect it 's not right that clients could send quantities of : method , : scheme , and : path other than 1 . We should probably fix the section reference , though I have n't reviewed 8.1.2 carefully enough to know exactly how that should read . 
 Good point . 
 The cited HTTP/2 sections mention malformed requests and response , so we probably also want to add some text to the H3 spec that links to it 's section 4.1.3 on how to deal with these .
Paragraph (version A):
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with
the ':' character (ASCII 0x3a) to convey the target URI, the method
of the request, and the status code for the response.  These pseudo-
header fields are defined in Section 8.1.2.3 and 8.1.2.4 of HTTP2.
Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in HTTP2.  The
restrictions on the use of pseudo-header fields in Section 8.1.2.1 of
HTTP2 also apply to HTTP/3.
Paragraph (version B):
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with
the ':' character (ASCII 0x3a) to convey the target URI, the method
of the request, and the status code for the response.  These pseudo-
header fields are defined in Section 8.1.2.3 and 8.1.2.4 of HTTP2.
Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in HTTP2.  The
restrictions on the use of pseudo-header fields in Section 8.1.2 of
HTTP2 also apply to HTTP/3.  Messages which are considered malformed
under these restrictions are handled as described in malformed.
Draft: draft-ietf-quic-http

Commentary: The Stream Types registry ( ) currently lists two types only ( 0 - control , 1 - push ) . While working on a dissector for the base HTTP/3 protocol , I ran across 2 and 3 . It turns out these are defined in the QPACK document ( ) with 2 - QPACK Encoder Stream , 3 - QPACK Decoder Stream . Since QPACK has already been referenced multiple times from the -http document , what about mentioning ( or registering ) the two codepoints in the -http document and reference to the -qpack document for the definition ? 
 We can , and as QPACK is a required component of HTTP/3 , you 'd probably need to support QPACK for that to work . However , this is an extensible space and your dissector would need to tolerate other types it might not recognize , or that are by future extensions . So the fact that there are definitions in other documents not mentioned by HTTP/3 is to be expected .
Paragraph (version A):
Some stream types are reserved (stream-grease).  Two stream types are
defined in this document: control streams (control-streams) and push
streams (push-streams).  Other stream types can be defined by
extensions to HTTP/3; see extensions for more details.
Paragraph (version B):
Some stream types are reserved (stream-grease).  Two stream types are
defined in this document: control streams (control-streams) and push
streams (push-streams).  QPACK defines two additional stream types.
Other stream types can be defined by extensions to HTTP/3; see
extensions for more details.
Draft: draft-ietf-quic-recovery

Commentary: In section " Time Threshold " , is used for the first time . I guess that would reference the same value before called ? If that 's the case they should be named the same . Further down in the same paragraph " smoothed SRTT " is used which is even more confusing . SRTT is used a few more times further down . 
 There was a cleanup a while ago to ensure definitions such as SRTT happened before use , but that might have been lost in recovery to transport migration ? 
 : +1 :
Paragraph (version A):
the latest RTT sample is higher than the SRTT, perhaps due to a
sustained increase in the actual RTT, but the smoothed SRTT has
not yet caught up.
Paragraph (version B):
the latest RTT sample is higher than the smoothed RTT, perhaps due
to a sustained increase in the actual RTT, but the smoothed RTT
has not yet caught up.
Paragraph (version A):
This document does not specify a pacer, but it is RECOMMENDED that a
sender pace sending of all in-flight packets based on input from the
congestion controller.  For example, a pacer might distribute the
congestion window over the SRTT when used with a window-based
controller, and a pacer might use the rate estimate of a rate-based
controller.
Paragraph (version B):
This document does not specify a pacer, but it is RECOMMENDED that a
sender pace sending of all in-flight packets based on input from the
congestion controller.  For example, a pacer might distribute the
congestion window over the smoothed RTT when used with a window-based
controller, and a pacer might use the rate estimate of a rate-based
controller.
Draft: draft-ietf-quic-recovery

Commentary: The recommendation for a 25ms delayed ack time is in transport , not recovery , so remove it from recovery . Should this paragraph be moved to transport ? 
 I think that it 's fine to just cut this . 
 This paragraph did n't seem to relate to anything else in the document : Is it left - over from a previous version ? 
 Thanks for pointing this out . The intent was to explain why 25ms was chosen , given it 's smaller than most TCP implementations default delayed ack time . There were more exceptions before , but now there 's only the one , which makes the preceding paragraph awkward as well . " The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet . Exceptions follow . " 
 I realized that the 25ms recommendation is in transport , so this is just out of place now . 
 Ah , I see , I remember I went looking for it in transport , but I think I looked for " delayed ack " and did n't come up with anything fitting . I 've got no concrete suggestion how to resolve it but moving the notice to transport in some form would probably make sense .
Paragraph (version A):
The majority of constants were derived from best common practices
among widely deployed TCP implementations on the internet.
Exceptions follow.
Paragraph (version A):
A shorter delayed ack time of 25ms was chosen because longer delayed
acks can delay loss recovery and for the small number of connections
where less than packet per 25ms is delivered, acking every packet is
beneficial to congestion control and loss recovery.