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

Commentary: The endpoint sends frames , which carry -- not send -- identifier values . 
 The way it 's intended to parse , " An endpoint ... MUST NOT increase the value they send , " is probably incorrect in number or gender . But yes , changing the verb to reflect that the subject is the frames instead of the endpoint is also an option . 
 OK . I have no preference how this sentence is fixed -- as long as it 's fixed . 
 This looks good . While we are at this paragraph , why say " client ? " GOAWAY can be sent by either side now . 
 It can , but a server is n't going to retry push streams on a new connection ; it 's going to decide de novo whether to push there . Arguably , nothing breaks if the client increases the Push ID on the server after the fact . 
 BTW , thanks for catching this . I appreciate how many of these ambiguities you 're winkling out . 
 OK , lgtm , then . 
 Maybe , given the ambiguity , the right answer is to get rid of " they " in the first place ?
Paragraph (version A):
A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection.  An endpoint MAY
send multiple GOAWAY frames indicating different identifiers, but
MUST NOT increase the identifier value they send, since clients might
already have retried unprocessed requests on another connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR.
Paragraph (version B):
A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection.  An endpoint MAY
send multiple GOAWAY frames indicating different identifiers, but the
identifier in each frame MUST NOT be greater than the identifier in
any previous frame, since clients might already have retried
unprocessed requests on another connection.  Receiving a GOAWAY
containing a larger identifier than previously received MUST be
treated as a connection error of type H3_ID_ERROR.
Draft: draft-ietf-quic-tls

Commentary: This is an update to , so check where it is being merged to carefully . 
 I 'm going to merge this into the other PR . 
 pointed out to me that when you receive junk ( i.e. , unauthenticated ) packets , the odds are that these will be distributed evenly between the " current " packet protection keys and the " next " packet protection keys , as the key phase bit will be nearly random if they are true forgeries . The result is that an endpoint that approaches the integrity limit on key usage will update to the next packet protection keys and find that those keys will have similar amounts of authentication failures . That might lead to needing two updates in quick succession . That is n't fatal , but if the timing is tight , then more time might be needed for an update . We might say that endpoints should n't be calculating the forgery rate and trying to delay updates as late as possible , nor should they be allowing that many forgeries without doing anything but react with key updates . However , as a matter of good hygiene , it 's worth saying something about this . Taking this as an editorial follow - on to . 
 Integrated into .
Paragraph (version B):
Due to the way that header protection protects the Key Phase,
packets that are discarded are likely to have an even distribution
of both Key Phase values.  This means that packets that fail
authentication will often use the packet protection keys from the
next key phase.  It is therefore necessary to also track the
number of packets that fail authentication with the next set of
packet protection keys.  To avoid exhaustion of both sets of keys,
it might be necessary to initiate two key updates in succession.
Draft: draft-ietf-quic-recovery

Commentary: I prefer to have MUSTs towards the top of sections when possible so they 're not missed . This is a follow - on from 
 I 'm not a fan of this change -- I think there 's value in having that text below where we talk about how bursts can occur . That said , I do n't feel strongly about it , so I 'm not going to fight for it .
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 smoothed RTT when used with a window-based
controller, or 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.  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 another method to limit such bursts to the initial
congestion window; see initial-cwnd.
Paragraph (version A):
Practical considerations, such as packetization, scheduling delays,
and computational efficiency, can cause a sender to deviate from this
rate over time periods that are much shorter than a round-trip time.
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; see initial-cwnd.
Paragraph (version B):
Practical considerations, such as packetization, scheduling delays,
and computational efficiency, can cause a sender to deviate from this
rate over time periods that are much shorter than a round-trip time.
Draft: draft-ietf-quic-transport

Commentary: ( It 's " Parameter , " not " Param . " )
Paragraph (version A):
The Transport Param Length field contains the length of the Transport
Parameter Value field.
Paragraph (version B):
The Transport Parameter Length field contains the length of the
Transport Parameter Value field.
Draft: draft-ietf-quic-recovery

Commentary: The fact that PTO does n't declare losses when it expires is quite important . It at the very end of the section , so I moved it to the first part . Also removed a section heading(pto - loss ) which was never referenced . 
 A reasonable simplification .
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.
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 server may not have validated the client's
address.  A PTO enables a connection to recover from loss of tail
packets or acknowledgements.
Paragraph (version A):
Delivery or loss of packets in flight is established when an ACK
frame is received that newly acknowledges one or more packets.
Draft: draft-ietf-quic-transport

Commentary: The rules for the active connection ID limit were such that the brief bump that NEWCONNECTIONID + Retire Prior To could add was not permitted . Strictly speaking , if you requested retirement , the connection IDs that you requested be retired are still active until you receive a RETIRECONNECTIONID frame . That means that you were technically violating this MUST in the spec . Adding an exception for this case was the best way I could see to fix this . The other was to change the definition of " active connection ID " . I tried that and , while it was a smaller change , it made the definition less crisp . This approach seems best . ( This is not new normative requirements as this is already . ) 
 LGTMThanks for making ( yet ) another attempt to clarify this . Looks good .
Paragraph (version A):
An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs.  Endpoints store received
connection IDs for future use and advertise the number of connection
IDs they are willing to store with the active_connection_id_limit
transport parameter.  An endpoint MUST NOT provide more connection
IDs than the peer's limit.  An endpoint that receives more connection
IDs than its advertised active_connection_id_limit MUST close the
connection with an error of type CONNECTION_ID_LIMIT_ERROR.
Paragraph (version B):
An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs.  Endpoints advertise the number
of active connection IDs they are willing to maintain using the
active_connection_id_limit transport parameter.  An endpoint MUST NOT
provide more connection IDs than the peer's limit.  An endpoint MAY
send connection IDs that temporarily exceed a peer's limit if the
NEW_CONNECTION_ID frame also requires the retirement of any excess,
by including a sufficiently large value in the Retire Prior To field.
Paragraph (version B):
A NEW_CONNECTION_ID frame might cause an endpoint to add some active
connection IDs and retire others based on the value of the Retire
Prior To field.  After processing a NEW_CONNECTION_ID frame and
adding and retiring active connection IDs, if the number of active
connection IDs exceeds the value advertised in its
active_connection_id_limit transport parameter, an endpoint MUST
close the connection with an error of type CONNECTION_ID_LIMIT_ERROR.
Draft: draft-ietf-quic-recovery

Commentary: Clarifies the impact of the anti - amplification factor on congestion control . Part of 
 When the client has a large first flight ( post - quantum , or 0 - RTT ) , it can send 10 packets at once . But that does not mean that the server can immediately send as much as 3x it receives in response , because that is above the INITCWND - the initial assumption about the network capacity . Things to be considered here are : Server can not rely on CC until the client 's address is validated , because an attacker might spoof Initial ACKs . At the very least , server needs to send one Initial in response to every client Initial packet not containing ACKs , otherwise the handshake might fail when there is heavy loss . Based on this observation , to me it seems that the easiest way of going forward would be to state that the amplification limit changes from 3x to 1x once the amount of data being sent by the server reaches INITCWND . Disclaimer : this issue popped up while trying to find out a response to claim that quicly sends 3x that is above INITCWND , when the client sends a large amount of 0 - RTT data . He 's correct , and and I think that this is a spec - issue . 
 Just to clarify , only an on - path attacker can do this , right ? 
 I agree it should be limited to INITCWND . Here 's how I read(and intended to write ) the text : 1 ) Congestion control always applies , because I do n't know of anywhere we say otherwise . 2 ) In addition , prior to address validation , the amplification limit of 3x also applies on the server side . Init CWND section : 
 Server can not rely on CC until the client 's address is validated , because an attacker might spoof Initial ACKs . An off - path attacker can do that . An attacker can easily guess the packet number that the server uses , and spoof an ACK without actually receiving a packet from the server . Note also that there is no guarantee that there would be enough entropy in server - generated CID , even though a server can generate CIDs in such a manner . That 's why we postpone the validation of the path until the server receives a Handshake packet . I think I agree with you that the limit can be defined as . 
 Thanks PTAL at PR and see if that clarifies this issue or if something else is necessary . 
 At the editor 's meeting , we concluded that the pseudocode did not represent the current text about re - arming the PTO alarm . I merged the first PR because I think it 's a nice clarification and I 'll send out a PR for the pseudocode . 
 Thank you for the quick PR . I 've stated my slight preference , but the text looks already : +1 : to me .
Paragraph (version B):
Prior to validating the client's address, the server can be further
limited by the anti-amplification limit as specified in Section 8.1
of QUIC-TRANSPORT.  Though the anti-amplification limit can prevent
the congestion window from being fully utilized and therefore slow
down the increase in congestion window, it does not directly affect
the congestion window.
Draft: draft-ietf-quic-invariants

Commentary: Happened to notice that the updated figure ( did n't check the old one ) was inconsistent with the text about the allowed length of the CID fields . Should be editorial , since the text wins any conflicts . 
  , yes , 255 bytes = 2,040 bits . 
 :D That 's exactly the process that my mind followed . 
 Both section 4.2 and 4.3 say Unfortunately , the does n't have  . I 'm not sure how to reword this to support both formats . 
 how about :) 
 I think this was fixed by , I do nt know if that was just a coincidence or it was untagged 
 That was intentional . I just neglected to tag this .
Paragraph (version A):
Long headers take the form described in fig-long.  Bits that have
version-specific semantics are marked with an X.
Paragraph (version B):
Long headers take the form described in fig-long.
Paragraph (version A):
Short headers take the form described in fig-short.  Bits that have
version-specific semantics are marked with an X.
Paragraph (version B):
Short headers take the form described in fig-short.
Draft: draft-ietf-quic-http

Commentary: Draft 27 says : Maybe I 'm missing it but I ca n't see where we say how the GoAway receiver handles an seeing the GoAway ID getting increased . We typically state what the receiver should do in such a case . For instance , with  we say " receipt of a  that contains a smaller value than previously received MUST be treated as a connection error of type H3IDERROR . " . I suggest that we need text that states receiving a larger GOAWAY ID than previously received MUST be treated as a connection error of type H3IDERROR . N.B. since draft-27 we landed changes to make the GOAWAY symmetrical . I believe this issue is still applicable to the most recent editors draft 
 H3IDERROR SGTM
Paragraph (version A):
A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection.  An endpoint MAY
send multiple GOAWAY frames indicating different identifiers, but
MUST NOT increase the identifier value they send, since clients might
already have retried unprocessed requests on another connection.
Paragraph (version B):
A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection.  An endpoint MAY
send multiple GOAWAY frames indicating different identifiers, but
MUST NOT increase the identifier value they send, since clients might
already have retried unprocessed requests on another connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR.
Draft: draft-ietf-quic-recovery

Commentary: This fixes some of the quoting issues that I discovered reading the spec .
Paragraph (version A):
The first three packets are determined to be lost when the
acknowledgement of packet 4 is received at t=8.  The congestion
period is calculated as the time between the oldest and newest lost
packets: (3 - 0) = 3.  The duration for persistent congestion is
equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the
threshold was reached and because none of the packets between the
oldest and the newest packets are acknowledged, the network is
considered to have experienced persistent congestion.
Paragraph (version B):
The first three packets are determined to be lost when the
acknowledgement of packet 4 is received at t = 8.  The congestion
period is calculated as the time between the oldest and newest lost
packets: (3 - 0) = 3.  The duration for persistent congestion is
equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the
threshold was reached and because none of the packets between the
oldest and the newest packets are acknowledged, the network is
considered to have experienced persistent congestion.
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 initial congestion window, which is recommended to be
the minimum of 10 * max_datagram_size and max(2* max_datagram_size,
14720)), where max_datagram_size is the current maximum size of a
datagram for the connection, not including UDP or IP overhead.
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 * max_datagram_size" and "max(2 *
max_datagram_size, 14720))", where max_datagram_size is the current
maximum size of a datagram for the connection, not including UDP or
IP overhead.
Draft: draft-ietf-quic-qpack

Commentary: The new principle is to only use backticks when referring to variables in pseudocode . There were two such instances that remain . 
 In I came up with a principle that might apply to use of . Field names , frame names , transport parameter names , and error codes do n't use any form of decoration . But if reference is being made to a variable in pseudocode , we would use backticks to distinguish it from . Qpack is a little tricky here because there is a mix of things . Note : backticks are quoted in for HTML and in double quotes ( ) in text output . Sparing use is probably best . 
 WFM . Thanks . I was never clear on whether " Base " or " Required Insert Count " referred to pseudocode variables or not .
Paragraph (version A):
The "Base" is used to resolve references in the dynamic table as
described in relative-indexing.
Paragraph (version B):
The Base is used to resolve references in the dynamic table as
described in relative-indexing.
Draft: draft-ietf-quic-transport

Commentary: A follow - up for .
Paragraph (version A):
If servers can use other dedicated server IP addresses or ports
than the one that the client initially connects to, they could use
the preferred_address transport parameter to request that clients
move connections to these dedicated addresses.  Note that clients
could choose not to use the preferred address.
Paragraph (version B):
If servers can use a dedicated server IP address or port, other
than the one that the client initially connects to, they could use
the preferred_address transport parameter to request that clients
move connections to that dedicated address.  Note that clients
could choose not to use the preferred address.
Draft: draft-ietf-quic-recovery

Commentary: Thanks , nice fix .
Paragraph (version A):
A connection MAY use the delay between sending a PATH_CHALLENGE and
receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in
pto-handshake) for a new path, but the delay SHOULD NOT be considered
an RTT sample.
Paragraph (version B):
A connection MAY use the delay between sending a PATH_CHALLENGE and
receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in
constants-of-interest) for a new path, but the delay SHOULD NOT be
considered an RTT sample.
Draft: draft-ietf-quic-recovery

Commentary: This is what the pseudocode says , but I could n't find anywhere in the text that clarified that if there were no ack - eliciting packets to arm PTO from , use Now ( ) .
Paragraph (version A):
Prior to handshake completion, when few to none RTT samples have been
generated, it is possible that the probe timer expiration is due to
an incorrect RTT estimate at the client.  To allow the client to
improve its RTT estimate, the new packet that it sends MUST be ack-
eliciting.  If Handshake keys are available to the client, it MUST
send a Handshake packet, and otherwise it MUST send an Initial packet
in a UDP datagram of at least 1200 bytes.
Paragraph (version B):
Prior to handshake completion, when few to none RTT samples have been
generated, it is possible that the probe timer expiration is due to
an incorrect RTT estimate at the client.  To allow the client to
improve its RTT estimate, the new packet that it sends MUST be ack-
eliciting.
Paragraph (version A):
Since the server could be blocked until more packets 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.
Paragraph (version B):
Since the server could be blocked until more packets 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.  If Handshake keys are available
to the client, it MUST send a Handshake packet, and otherwise it MUST
send an Initial packet in a UDP datagram of at least 1200 bytes.
Paragraph (version B):
A client could have received and acknowledged a Handshake packet,
causing it to discard state for the Initial packet number space, but
not sent any ack-eliciting Handshake packets.  In this case, the PTO
is set from the current time.
Draft: draft-ietf-quic-transport

Commentary: We already had something here , but I think that it missed the central reason , which is the combination of : wanting to replace all connection IDs having used the limit from activeconnectionid_limit wanting to ensure that there is = 1 available connection IDs left This phrasing is n't quite that explicit , but I think that it is clear enough . 
 It is not obvious from this , but the intent here is to allow NEWCONNECTIONID to exceed the limit from activeconnectionid_limit . 
 Nice wording , looks good !
Paragraph (version A):
Upon receipt of an increased Retire Prior To field, the peer MUST
stop using the corresponding connection IDs and retire them with
RETIRE_CONNECTION_ID frames before adding the newly provided
connection ID to the set of active connection IDs.  This ordering
allows an endpoint that has already supplied its peer with as many
connection IDs as allowed by the active_connection_id_limit transport
parameter to replace those connection IDs with new ones as necessary.
Failure to cease using the connection IDs when requested can result
in connection failures, as the issuing endpoint might be unable to
continue using the connection IDs with the active connection.
Paragraph (version B):
Upon receipt of an increased Retire Prior To field, the peer MUST
stop using the corresponding connection IDs and retire them with
RETIRE_CONNECTION_ID frames before adding the newly provided
connection ID to the set of active connection IDs.  This ordering
allows an endpoint to replace all active connection IDs without the
possibility of a peer having no available connection IDs and without
exceeding the limit the peer sets in the active_connection_id_limit
transport parameter; see transport-parameter-definitions.  Failure to
cease using the connection IDs when requested can result in
connection failures, as the issuing endpoint might be unable to
continue using the connection IDs with the active connection.