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

Commentary: I believe these two cases are both 3*PTO to allow the PTO to expire at least once before declaring path validation failure and idle timeout . 
 Thanks for your suggestions , I 'm quite happy with this now . 
 says in : This is reasonable . I do n't know which document needs the text though . 
 This looks like it should go into -recovery , since -transport mostly only refers to as a TP , except in Section 13.2.1 ( " sending - acknowledgements " ) , but that text is very general . 
 I would suggest that this should go where a value of X PTOs is suggested for each specific timer . 
 Relabeling , since ended up being against -transport and not -recovery .
Paragraph (version B):
This timeout allows for multiple PTOs to expire prior to failing path
validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE
frame does not cause path validation failure.
Paragraph (version A):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).
Paragraph (version B):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).  This allows for multiple PTOs to expire
prior to idle timeout, ensuring the idle timeout does not expire as a
result of a single packet loss.
Draft: draft-ietf-quic-transport

Commentary: It should refer to Table 1 . 
 Thanks , !
Paragraph (version A):
An endpoint limits the cumulative number of incoming streams a peer
can open.  Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened; see long-packet-types.
Initial limits are set in the transport parameters; see transport-
parameter-definitions.  Subsequent limits are advertised using
MAX_STREAMS frames; see frame-max-streams.  Separate limits apply to
unidirectional and bidirectional streams.
Paragraph (version B):
An endpoint limits the cumulative number of incoming streams a peer
can open.  Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened; see stream-id-types.
Initial limits are set in the transport parameters; see transport-
parameter-definitions.  Subsequent limits are advertised using
MAX_STREAMS frames; see frame-max-streams.  Separate limits apply to
unidirectional and bidirectional streams.
Draft: draft-ietf-quic-http

Commentary: Looks like this is the new location of the text .
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 9.9 of
HTTP11) or 101 (Switching Protocols) informational status code
(Section 10.2.2 of SEMANTICS).
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.7 of
!SEMANTICS) or 101 (Switching Protocols) informational status code
(Section 10.2.2 of SEMANTICS).
Draft: draft-ietf-quic-http

Commentary: Probably editorial since this is what was previously intended , but still touching a MUST . 
 states : The case when the client has not sent a  frame is not covered . ( In this case , the client should treat the receipt of any frame with a Push ID as an error . ) 
 There is some other text that kinda marks the error case : One interpretation is that since any value of ID is greater than , then the error condition holds . But I agree with  that we could probably make this clearer with some editorializing . 
 That 's a big stretch . Does it hold in languages that have a , such as JavaScript ? E.g. , can one write ? 
 Since it starts as unset , and  can only increase the value then in this world , 0 must be greater than unset 
 What is " unset ? " & lt;DmitriModeIf 0 is a valid value , then " unset " means , which is not smaller than 0 . That is , it is not true that , which is what the text says.&lt;/DmitriMode 
 Sure , but then it makes it very hard to send a  that does n't decrease the value . I think we agree that it would help the doc to fix your original nitpick . 
 Unset is negative one ? The frame sets a boolean ? This seems easy enough to implement in practice , but you 're correct that the doc is effectively using a nullable type . I see a couple possible doc fixes . The most minimal change is to simply state that it is also an error to receive anything that uses a Push ID if no  frame has been sent . That 's compatible and consistent with the intent of the current design . Alternatively , we could define  to tell the recipient how many  IDs they can use ; 0 is the initial value , and sending 0 leaves push disabled . That 's consistent with QUIC 's MAXSTREAMS et al . but would be a breaking change . 
 I vote for the simplest approach : 
 +1 let 's keep it simple 
  ? 
 Yes , this is an editorial issue .
Paragraph (version A):
The Push ID space begins at zero, and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use Push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream with a Push ID that is greater than the maximum Push ID
as a connection error of type H3_ID_ERROR.
Paragraph (version B):
The Push ID space begins at zero, and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use Push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream as a connection error of type H3_ID_ERROR when no
MAX_PUSH_ID frame has been sent or when the stream references a Push
ID that is greater than the maximum Push ID.
Draft: draft-ietf-quic-transport

Commentary: See the issue for the sorry history of this mistake . 
 This issue has a long and storied history . We were originally of the view that only one packet needed to include a token ( which you can see in the discussion of ) . However , the resolution of that issue in was very clear : every Initial packet needs to include a token . That introduced a regression as it grouped the token with the connection ID , and we caught that in . However , the fix to that in reverted the token changes along with the connection ID changes . Since then , this error has gone unnoticed . Most people will have seen the stronger normative requirement : To my knowledge , every implementation includes the token in every Initial packet , changing only when a Retry is received . We should reconcile the text . 
 FWIW , that 's what the interop runner tests for in the Retry test case . 
 : Yes , that 's what sent us off on this chase :-)
Paragraph (version A):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet; see negotiating-connection-ids.
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client MUST use
the same cryptographic handshake message it included in this packet.
A server MAY treat a packet that contains a different cryptographic
handshake message as a connection error or discard it.
Paragraph (version B):
Subsequent Initial packets from the client include the connection ID
and token values from the Retry packet.  The client copies the Source
Connection ID field from the Retry packet to the Destination
Connection ID field and uses this value until an Initial packet with
an updated value is received; see negotiating-connection-ids.  The
value of the Token field is copied to all subsequent Initial packets;
see validate-retry.
Paragraph (version B):
Other than updating the Destination Connection ID and Token fields,
the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet.  A client MUST use the same
cryptographic handshake message it included in this packet.  A server
MAY treat a packet that contains a different cryptographic handshake
message as a connection error or discard it.
Draft: draft-ietf-quic-transport

Commentary: The original text here might be read to imply that a server ca n't send Retry if it receives an Initial that contains a token that came from NEW_TOKEN . That 's wrong .
Paragraph (version A):
Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (packet-retry)
containing a token.  This token MUST be repeated by the client in all
Initial packets it sends for that connection after it receives the
Retry packet.  In response to processing an Initial containing a
token, a server can either abort the connection or permit it to
proceed.
Paragraph (version B):
Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (packet-retry)
containing a token.  This token MUST be repeated by the client in all
Initial packets it sends for that connection after it receives the
Retry packet.
Paragraph (version B):
In response to processing an Initial containing a token that was
provided in a Retry packet, a server cannot send another Retry
packet; it can only refuse the connection or permit it to proceed.
Draft: draft-ietf-quic-recovery

Commentary: This avoids redefinition of the conditions for handshake confirmation . It 's fewer words , even with the extra references . 
 The draft should use " handshake confirmed " and point to the TLS draft instead of describing the conditions individually in various places .
Paragraph (version A):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgement is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgements until it
receives a HANDSHAKE_DONE frame or an acknowledgement for one of its
Handshake or 1-RTT packets.
Paragraph (version B):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgement is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgements until the
handshake is confirmed; see Section 4.1.2 of QUIC-TLS.
Paragraph (version A):
Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgement for one of its Handshake or 1-RTT packets and has not
received a HANDSHAKE_DONE frame, even if there are no packets in
flight.  When the PTO fires, the client MUST send a Handshake packet
if it has Handshake keys, otherwise it MUST send an Initial packet in
a UDP datagram of at least 1200 bytes.
Paragraph (version B):
Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgement for one of its Handshake packets and the handshake is
not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no
packets in flight.  When the PTO fires, the client MUST send a
Handshake packet if it has Handshake keys, otherwise it MUST send an
Initial packet in a UDP datagram of at least 1200 bytes.
Draft: draft-ietf-quic-transport

Commentary: This is the maximal version of a clarification of this text . 
 WFM , and resolves the original NiT. 
 ( Broken out of . ) Of course it may not be able to immediately send anything:- ) , but I suspect this needs to not delay ? 
 These frames are n't subject to flow control , so the only reason it would be unable to send something is congestion control . The frame that it echos back needs to be enqueued for sending ; if it takes some time to actually hit the network , that 's fine . 
 Seems resolved by the PR 
 For the benefit of others reviewing this : This seems to refer to . 
 This LG , but so did the old text .
Paragraph (version A):
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame.
Paragraph (version B):
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by
echoing the data contained in the PATH_CHALLENGE frame in a
PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a
packet containing a PATH_RESPONSE frame unless constrained by
congestion control.
Draft: draft-ietf-quic-transport

Commentary: ( Broken out of . ) I assert the new path may not have the same RTT , because the path could traverse a different set of network devices or be subject to different policies that influence forwarding behaviour . These are not currently listed here , but are the basis for some later text in 9.3.1 . Can we mention here ? 
 Is the RTT not included in the reset of the congestion controller ? 
 Section 9.4 reads : " The capacity available on the new path might not be the same as the old path . Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path . " 
 I sent a PR to add " and RTT estimate " to the sentence quoted to make this completely clear .
Paragraph (version A):
When migrating, the new path might not support the endpoint's current
sending rate.  Therefore, the endpoint resets its congestion
controller, as described in migration-cc.
Paragraph (version B):
When migrating, the new path might not support the endpoint's current
sending rate.  Therefore, the endpoint resets its congestion
controller and RTT estimate, as described in migration-cc.
Draft: draft-ietf-quic-transport

Commentary: : 
 ( Broken out of . ) what does ‘ absent ’ mean in this clause , could you reword ?
Paragraph (version A):
A client MUST NOT use remembered values for the following parameters:
ack_delay_exponent, max_ack_delay, initial_source_connection_id,
original_destination_connection_id, preferred_address,
retry_source_connection_id, and stateless_reset_token.  The client
MUST use the server's new values in the handshake instead, and absent
new values from the server, the default value.
Paragraph (version B):
A client MUST NOT use remembered values for the following parameters:
ack_delay_exponent, max_ack_delay, initial_source_connection_id,
original_destination_connection_id, preferred_address,
retry_source_connection_id, and stateless_reset_token.  The client
MUST use the server's new values in the handshake instead; if the
server does not provide new values, the default value is used.
Draft: draft-ietf-quic-transport

Commentary: ( Broken out of . ) A receiver maintains a cumulative sum of It would have helped me , had this explained what was intended by “ control violations ” - I think it means to detect when the sender sends more than permitted by the flow control limit . I think the control part comes in a later sentence ? ( Is this measured against the largest advertised offset , or the current offset ? … given what is written about reducing the advertised value ? )
Paragraph (version A):
A receiver can advertise a larger limit for a connection by sending a
MAX_DATA frame, which indicates the maximum of the sum of the
absolute byte offsets of all streams.  A receiver maintains a
cumulative sum of bytes received on all streams, which is used to
check for flow control violations.  A receiver might use a sum of
bytes consumed on all streams to determine the maximum data limit to
be advertised.
Paragraph (version B):
A receiver can advertise a larger limit for a connection by sending a
MAX_DATA frame, which indicates the maximum of the sum of the
absolute byte offsets of all streams.  A receiver maintains a
cumulative sum of bytes received on all streams, which is used to
check for violations of the advertised connection or stream data
limits.  A receiver might use a sum of bytes consumed on all streams
to determine the maximum data limit to be advertised.
Draft: draft-ietf-quic-qpack

Commentary: Per discussion on Slack , expanding this discussion in the Security Considerations to be more accurate . Editorial , since these are purely statements about the properties of the design . 
 This is true , but this is also obvious , at least once you start implementing the encoder . Too , there is the natural limit on dynamic references : it is the function of the product of the number of allowed streams and the number of entries in the dynamic table ( which itself is a function of the table size ) . I am concerned that this new verbiage puts the wrong thought into the head of the implementer ; we should not encourage this . Limiting the number of dynamic table references ( done out of memory conservation zeal ) affects compression performance directly -- it worsens it . Perhaps we can tack on the following sentence to the end of the paragraph : 
 I 'm OK with that , though I would qualify with " compression performance " , as performance has other dimensions that the extra state might impinge upon . 
 Another thing to note is that sometimes dynamic table references do not have to have their own objects in the encoder . For examples , they are in ls - qpack . ( Everyone reading this in 2022 : you 're welcome ) 
 Yeah , compression performance qualification is a good suggestion .
Paragraph (version A):
A decoder can limit the amount of state memory used for blocked
streams by setting an appropriate value for the maximum number of
blocked streams.  In HTTP/3, this is realized by setting an
appropriate value for the QPACK_BLOCKED_STREAMS parameter.  An
encoder can limit the amount of state memory by only using as many
blocked streams as it wishes to support; no signaling to the decoder
is required.
Paragraph (version B):
A decoder can limit the amount of state memory used for blocked
streams by setting an appropriate value for the maximum number of
blocked streams.  In HTTP/3, this is realized by setting an
appropriate value for the QPACK_BLOCKED_STREAMS parameter.  Streams
which risk becoming blocked consume no additional state memory on the
encoder.
Paragraph (version B):
An encoder allocates memory to track all dynamic table references in
unacknowledged field sections.  An implementation can directly limit
the amount of state memory by only using as many references to the
dynamic table as it wishes to track; no signaling to the decoder is
required.  However, limiting references to the dynamic table will
reduce compression effectiveness.
Draft: draft-ietf-quic-recovery

Commentary: We may want to revert this once lands 
 ~ still allows you to reduce the cwnd on entering recovery , so I think this text is still good.~ Now that I 've seen your changes to , reverting this makes sense . 
 It might pay to reconcile : { { vars - of - interest } } ) to be larger than the congestion window , unless the packet is sent on a PTO timer expiration ; see { { pto } } . And now exceeds the recently reduced congestion window . Now , you might implement the latter using PTO machinery , but that text does n't really suggest that in any way . 
 Where does this second sentence come from ? I 'm pretty sure I have n't implemented anything like this in quic - go . Should I ? 
 That sentence is the the definition of the . We have n't implemented that either , and I was wondering if it truly helps . 
 For TCP this second case if important because as long as you do n't retransmit the lost packet you will not get any ACK that acknowledges new data . I guess we do n't need that for QUIC . 
 The second sentence was later in , and the MUST was n't updated , so I 'll fix that . Chromium currently implements PRR(RFC6937 ) , which is a more complex variant of this which is designed to keep the ACK clock going . I thought we discussed adding an informative reference to PRR when we this text , and I 'm not sure why we did n't . 
 seems to be the wrong issue you are pointed to ... 
 Good catch , it 's 
 Thanks . Simple :)
Paragraph (version A):
An endpoint MUST NOT send a packet if it would cause bytes_in_flight
(see vars-of-interest) to be larger than the congestion window,
unless the packet is sent on a PTO timer expiration; see pto.
Paragraph (version B):
An endpoint MUST NOT send a packet if it would cause bytes_in_flight
(see vars-of-interest) to be larger than the congestion window,
unless the packet is sent on a PTO timer expiration (see pto) or when
entering recovery (see recovery-period).
Draft: draft-ietf-quic-transport

Commentary: This sentence structure was unnecessarily byzantine . 
 is hard to read . [ A D ] [ A D ] ] [ A D ] ] ...
Paragraph (version A):
An endpoint might send a CONNECTION_CLOSE frame in an Initial packet
or in response to unauthenticated information received in Initial or
Handshake packets.  Such an immediate close might expose legitimate
connections to a denial of service.  QUIC does not include defensive
measures for on-path attacks during the handshake; see handshake-dos.
However, at the cost of reducing feedback about errors for legitimate
peers, some forms of denial of service can be made more difficult for
an attacker if endpoints discard illegal packets rather than
terminating a connection with CONNECTION_CLOSE.  For this reason,
endpoints MAY discard packets rather than immediately close if errors
are detected in packets that lack authentication.
Paragraph (version B):
An endpoint can send a CONNECTION_CLOSE frame in an Initial packet.
This might be in response to unauthenticated information received in
Initial or Handshake packets.  Such an immediate close might expose
legitimate connections to a denial of service.  QUIC does not include
defensive measures for on-path attacks during the handshake; see
handshake-dos.  However, at the cost of reducing feedback about
errors for legitimate peers, some forms of denial of service can be
made more difficult for an attacker if endpoints discard illegal
packets rather than terminating a connection with CONNECTION_CLOSE.
For this reason, endpoints MAY discard packets rather than
immediately close if errors are detected in packets that lack
authentication.