jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: rfc9002

Commentary: These are tiny enough that I 'll merge
Paragraph (version A):
Loss detection and congestion control fundamentally involve
consumption of signals, such as delay, loss, and ECN markings, from
unauthenticated entities.  An attacker can cause endpoints to reduce
their sending rate by manipulating these signals; by dropping
packets, by altering path delay strategically, or by changing ECN
codepoints.
Paragraph (version B):
Loss detection and congestion control fundamentally involve
consumption of signals, such as delay, loss, and ECN markings, from
unauthenticated entities.  An attacker can cause endpoints to reduce
their sending rate by manipulating these signals: by dropping
packets, by altering path delay strategically, or by changing ECN
codepoints.
Paragraph (version A):
A sender can detect suppression of reports by marking occasional
packets that it sends with an ECN-CE marking.  If a packet sent with
an ECN-CE marking is not reported as having been CE marked when the
packet is acknowledged, then the sender can disable ECN for that path
by not setting ECT codepoints in subsequent packets sent on that path
RFC3168.
Paragraph (version B):
A sender can detect suppression of reports by marking occasional
packets that it sends with an ECN-CE marking.  If a packet sent with
an ECN-CE marking is not reported as having been CE marked when the
packet is acknowledged, then the sender can disable ECN for that path
by not setting ECN-Capable Transport (ECT) codepoints in subsequent
packets sent on that path RFC3168.
Draft: rfc9002

Commentary: 3 ) [ rfced ] Does the following improve the readability of the paragraph ? Current : Endpoints SHOULD set the minrtt to the newest RTT sample after persistent congestion is established . This is to allow a connection to reset its estimate of minrtt and smoothedrtt after a disruptive network event ( Section 5.3 ) , and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared . Perhaps : Endpoints SHOULD set the minrtt to the newest RTT sample after persistent congestion is established because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared . This also allows a connection to reset its estimate of minrtt and smoothedrtt after a disruptive network event ( Section 5.3 ) . 
 I find this easier to read , but I think it may be subtly different , so I put it into a separate PR . 
 It does n't change the meaning , but it does feel like the first sentence is trying to span too many topics . I like the reordering , but I 'd split it out . This is good , thank you !
Paragraph (version A):
Endpoints SHOULD set the min_rtt to the newest RTT sample after
persistent congestion is established.  This is to allow a connection
to reset its estimate of min_rtt and smoothed_rtt (smoothed-rtt)
after a disruptive network event, and because it is possible that an
increase in path delay resulted in persistent congestion being
incorrectly declared.
Paragraph (version B):
Endpoints SHOULD set the min_rtt to the newest RTT sample after
persistent congestion is established.  This avoids repeatedly
declaring persistent congestion when the RTT increases.  This also
allows a connection to reset its estimate of min_rtt and smoothed_rtt
after a disruptive network event; see smoothed-rtt.
Draft: rfc9002

Commentary: one suggestion , but lgtm
Paragraph (version A):
TCP's RACK (RACK) specifies a slightly larger threshold,
equivalent to 5/4, for a similar purpose.  Experience with QUIC
shows that 9/8 works well.
Paragraph (version A):
Packets 2 through 8 are declared lost when the acknowledgment for
packet 9 is received at t = 12.2.
Paragraph (version A):
The congestion period is calculated as the time between the oldest
and newest lost packets: 8 - 1 = 7.  The persistent congestion
duration is: 2 * 3 = 6.  Because the threshold was reached and
because none of the packets between the oldest and the newest lost
packets were acknowledged, the network is considered to have
experienced persistent congestion.
Paragraph (version B):
Packets 2 through 8 are declared lost when the acknowledgment for
packet 9 is received at "t = 12.2".
Paragraph (version B):
The congestion period is calculated as the time between the oldest
and newest lost packets: "8 - 1 = 7".  The persistent congestion
duration is "2 * 3 = 6".  Because the threshold was reached and
because none of the packets between the oldest and the newest lost
packets were acknowledged, the network is considered to have
experienced persistent congestion.
Draft: rfc9001

Commentary: And make its presentation consistent throughout .
Paragraph (version A):
A TLS alert is converted into a QUIC connection error.  The
AlertDescription value is added to 0x0100 to produce a QUIC error
code from the range reserved for CRYPTO_ERROR.  The resulting value
is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.
Paragraph (version B):
A TLS alert is converted into a QUIC connection error.  The
AlertDescription value is added to 0x0100 to produce a QUIC error
code from the range reserved for CRYPTO_ERROR; see Section 20.1 of
QUIC-TRANSPORT.  The resulting value is sent in a QUIC
CONNECTION_CLOSE frame of type 0x1c.
Draft: rfc9000

Commentary: This includes all the updates to references in transport . This includes new code again . See It would be possible to cite BCP38 as an RFC and avoid this , but I think that the BCP reference is correct . Not as sure about the BCP145 reference , as we need to point to the RFC directly to get the section reference , but I think that is OK on balance .
Paragraph (version A):
Both DPLPMTUD and PMTUD send datagrams that are larger than the
current maximum datagram size, referred to as PMTU probes.  All QUIC
packets that are not sent in a PMTU probe SHOULD be sized to fit
within the maximum datagram size to avoid the datagram being
fragmented or dropped RFC8085.
Paragraph (version B):
Both DPLPMTUD and PMTUD send datagrams that are larger than the
current maximum datagram size, referred to as PMTU probes.  All QUIC
packets that are not sent in a PMTU probe SHOULD be sized to fit
within the maximum datagram size to avoid the datagram being
fragmented or dropped BCP145.
Paragraph (version A):
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from packet injection as specified in RFC8201 and Section 5.2 of
RFC8085.  This validation SHOULD use the quoted packet supplied in
the payload of an ICMP message to associate the message with a
corresponding transport connection (see Section 4.6.1 of DPLPMTUD).
ICMP message validation MUST include matching IP addresses and UDP
ports RFC8085 and, when possible, connection IDs to an active QUIC
session.  The endpoint SHOULD ignore all ICMP messages that fail
validation.
Paragraph (version B):
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from packet injection as specified in RFC8201 and Section 5.2 of
RFC8085.  This validation SHOULD use the quoted packet supplied in
the payload of an ICMP message to associate the message with a
corresponding transport connection (see Section 4.6.1 of DPLPMTUD).
ICMP message validation MUST include matching IP addresses and UDP
ports BCP145 and, when possible, connection IDs to an active QUIC
session.  The endpoint SHOULD ignore all ICMP messages that fail
validation.
Draft: rfc9000

Commentary: For those drafts that are in AUTH48 . 
 This PR makes me happy.9000 ! Very cool !
Paragraph (version B):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgments are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY choose not to send an ACK frame with
outgoing frames until an ack-eliciting packet has been received.
Paragraph (version B):
An endpoint that is only sending non-ack-eliciting packets might
choose to occasionally add an ack-eliciting frame to those packets to
ensure that it receives an acknowledgment; see ack-tracking.  In that
case, an endpoint MUST NOT send an ack-eliciting frame in all packets
that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgments.
Paragraph (version A):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgments are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to include an ACK frame with outgoing frames.
Paragraph (version A):
A receiver MUST NOT send an ack-eliciting frame in all packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgments.
Paragraph (version A):
A variable-length integer error code that 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 B):
A variable-length integer error code that 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 defined by the
application protocol; see app-error-codes.
Draft: rfc9000

Commentary: This includes changelogs , notes in front matter , and stuff about draft versions . 
 Goodbye , change logs !
Paragraph (version B):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgments are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY choose not to send an ACK frame with
outgoing frames until an ack-eliciting packet has been received.
Paragraph (version B):
An endpoint that is only sending non-ack-eliciting packets might
choose to occasionally add an ack-eliciting frame to those packets to
ensure that it receives an acknowledgment; see ack-tracking.  In that
case, an endpoint MUST NOT send an ack-eliciting frame in all packets
that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgments.
Paragraph (version A):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgments are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to include an ACK frame with outgoing frames.
Paragraph (version A):
A receiver MUST NOT send an ack-eliciting frame in all packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgments.
Paragraph (version A):
A variable-length integer error code that 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 B):
A variable-length integer error code that 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 defined by the
application protocol; see app-error-codes.
Draft: draft-ietf-quic-transport

Commentary: This avoids the implication of a single error code space . Even if one is permissible , that is not necessary . 
 originally posted in a comment highlighting that although HTTP/3 uses a single error code space for connection and stream errors , there is no requirement for other application protocol mappings to do the same . I found the text in to give me the wrong assumptions . This is the only mention of an error code space in the text that will make it into RFC . So I suggest in the offending paragraph we delete the 2 occurrences of " space " and just state that the frame contains a value , either defined in transport [ ref ] or application [ ref ] 
 " uses codes defined by the application protocol " ?
Paragraph (version A):
A variable-length integer error code that 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 B):
A variable-length integer error code that 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 defined by the
application protocol; see app-error-codes.
Draft: draft-ietf-quic-transport

Commentary:  points out that we accidentally cited the sending parts , but these are receive states . 
 Very editorial nit : The section has the following text : The states referenced here are in fact receive stream states , not send stream states . Should this be : The same goes for  :
Paragraph (version A):
A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states; see stream-send-states.  Receiving a STOP_SENDING frame
for a locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version B):
A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states; see stream-recv-states.  Receiving a STOP_SENDING frame
for a locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
see stream-send-states.  Receiving a MAX_STREAM_DATA frame for a
locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version B):
A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
see stream-recv-states.  Receiving a MAX_STREAM_DATA frame for a
locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Draft: draft-ietf-quic-transport

Commentary: Rather than saying who ignores MAX_STREAMS , we can just that it is ignored . 
 has the following requirement : frame , advertising a smaller limit has no effect . A receiver MUST ignore any MAXSTREAMS frame that does not increase the stream limit . I believe this should be : frame , advertising a smaller limit has no effect . A sender MUST ignore any MAXSTREAMS frame that does not increase the stream limit . This would be in line with the similar requirements for MAXSTREAMDATA and  in : is not an error to advertise a smaller limit , but the smaller limit has no effect . [ ... ] A sender MUST ignore any MAXSTREAMDATA or  frames that do not increase flow control limits . 
 I believe the sentence was intended to read : " A receiver(of the frame ) MUST ignore any MAX_STREAMS frame that does not increase the stream limit . " 
 Using " receiver " in this context is confusing , maybe it could just be replaced by " endpoint " : frame , advertising a smaller limit has no effect . An endpoint MUST ignore any MAXSTREAMS frame that does not increase the stream limit . Or just take the language from : ignored . 
 Yeah , this is the right fix .
Paragraph (version A):
Once a receiver advertises a stream limit using the MAX_STREAMS
frame, advertising a smaller limit has no effect.  A receiver MUST
ignore any MAX_STREAMS frame that does not increase the stream limit.
Paragraph (version B):
Once a receiver advertises a stream limit using the MAX_STREAMS
frame, advertising a smaller limit has no effect.  MAX_STREAMS frames
that do not increase the stream limit MUST be ignored.
Draft: draft-ietf-quic-qpack

Commentary: RFC - to - be 9114 ( draft - ietf - quic - http ) includes the following note to indicate that the registrations have a status of permanent and the Change  is the IETF . Should a similar statement be included in this document ? From RFC - to - be 9114 : The initial allocations in these registries created in this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group ( ietf - http- ) . In addition , note that the padding in the Settings , Stream Types , and Error Codes differs from what appears in the IANA registry . IANA included the following note when they notified us that their actions for RFC - to - be 9114 were complete : NOTE : In the new registries , the padding has been adjusted for consistency from one registry to another and with We understand that there may be a request to change it . We have asked  ( as editor of RFC - to - be 9114 ) to review , as the padding for the HTTP/3 registries is now inconsistent with the padding for the HTTP/2 registries . Please review and dicuss and let us know if any updates are needed . 
 Fixed in . 
 The QUIC registry policies , imported to HTTP/3 , specify that a change controller and their contact information should be listed with each permanent registration . QPACK does n't provide one , though almost certainly it should be the HTTP WG .
Paragraph (version B):
This document makes multiple registrations in the registries defined
by HTTP3.  The allocations created by this document are all assigned
permanent status and list a change controller of the IETF and a
contact of the HTTP working group (ietf-http-wg@w3.org).
Draft: draft-ietf-quic-transport

Commentary: If the client has opened a stream in 0 - RTT with , and the server increases to , does this apply to this stream as well , or only to streams opened after handshake completion ? Consensus in Slack seems to be that the limit should apply to all streams . The text should be explicit about that . 
 Is n't that already clear enough ? states : 
 This is what the definition of the TP says : Arguably , the stream used in 0 - RTT is not a " newly created " stream . 
 Yeah , let 's just be really clear about this . Though quotes the section that is most important , this has proven to be a mistake common enough to spend text on .
Paragraph (version B):
A server might provide larger initial stream flow control limits for
streams than the remembered values that a client applies when sending
0-RTT.  Once the handshake completes, the client updates the flow
control limits on all sending streams using the updated values of
initial_max_stream_data_bidi_remote and initial_max_stream_data_uni.
Draft: draft-ietf-quic-http

Commentary: Adds the all - important conditional . 
 For clients that have sent CANCEL_PUSH , they do n't know if server 's push stream will still arrive or not . They have to remember  IDs forever in order to differentiate between cancelled push and completed push . 
 I would appreciate some quick discussion if this issue is important to address before I approve or not . 
 We could make this a MAY . The other formulation we 've used is " MUST ... if the client detects " , making the response mandatory if the condition is detected , but not specifying the required level of effort to detect it . 
 I do n't know that this issue is critical to address , but I agree that with certain ( reasonable ) implementation strategies this particular MUST becomes unenforceable / unachievable . 
 +1 for " MUST if the client detects " if we 're going to make a change . 
 I think " MUST if detects " is suitable here - it points at the core problem . Simply s / MUST / MAY does n't help people appreciate that might not be able to detect the condition . I 'd also suggest that " MUST if detects " is an editorial change . 
 can you confirm if addresses your issue ? 
 Looks good ! 
 Thanks . In that case I believe we have addressed this issue with an editorial change . please confirm if we can merge the related PR and incorporate the change in during the RFC editor process . 
 Yes , the change looks good . I could actually include it as an RFC - edtior note in my approval message . 
 An elegant solution :)
Paragraph (version A):
Each Push ID MUST only be used once in a push stream header.  If a
push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of
type H3_ID_ERROR; see errors.
Paragraph (version B):
Each Push ID MUST only be used once in a push stream header.  If a
client detects that a push stream header includes a Push ID that was
used in another push stream header, the client MUST treat this as a
connection error of type H3_ID_ERROR; see errors.
Draft: draft-ietf-quic-tls

Commentary: Cleanup the language here a little . 
 This text could be better : Maybe instead : 
 Does anyone want to prepare a PR ? Otherwise , this will get dropped I guess . 
 I did n't want to clutter our list of stuff with post - IESG PRs . I 'll copy the above text once HTTP is done ( real soon now ) . We 're going to have to be careful that these little tweaks do n't pile up . 
 I think this should be good to go now ?
Paragraph (version A):
The TLS implementation does not need to ensure that the ClientHello
is large enough to meet the requirements for QUIC packets.  QUIC
PADDING frames are added to increase the size of the packet as
necessary; see Section 14.1 of QUIC-TRANSPORT.
Paragraph (version B):
The TLS implementation does not need to ensure that the ClientHello
is large enough to meet QUIC's requirements for datagrams that carry
Initial packets; see Section 14.1 of QUIC-TRANSPORT.  QUIC
implementations use PADDING frames or packet coalescing to ensure
that datagrams are large enough.