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

Commentary: Not sure if this is design . It probably is . 
 Because that is where contention occurs . 
 Amanda from IANA says : I believe that the original idea was that we privilege the first unassigned value in each range of values that has a different length encoding for varints . But as we are also using these rules for non - varint encodings , that sort of rulemaking is likely confusing . I 'm proposing that this be made simply " first unassigned codepoint " . PR to follow . ( This will affect more than just -transport , but the text change only occurs there , so I think we 're OK . ) 
 This is good .
Paragraph (version A):
Use of the first available codepoint in a range is reserved for
allocation using the Standards Action policy; see Section 4.9 of
RFC8126.  The early codepoint assignment process EARLY-ASSIGN can be
used for these values.
Paragraph (version B):
Use of the first unassigned codepoint is reserved for allocation
using the Standards Action policy; see Section 4.9 of RFC8126.  The
early codepoint assignment process EARLY-ASSIGN can be used for these
values.
Draft: draft-ietf-quic-transport

Commentary: So I rewrote the sentence instead . 
 packet - type - specific ? 
   said : 
 In this case , you can simply do " type specific " , since type - specific is not an adjective before a noun ( like " type - specific bits " ) . But this is good too .
Paragraph (version A):
The lower four bits (those with a mask of 0x0f) of byte 0 are
type-specific.
Paragraph (version B):
The semantics of the lower four bits (those with a mask of 0x0f)
of byte 0 are determined by the packet type.
Draft: draft-ietf-quic-transport

Commentary: With one exception . 
   said : 
 The one case where non - optimal encodings are forbidden is Otherwise , there is no restriction . Yes , 3 can be encoded in 8 bytes . But it is worth noting . ( I thought that we had . )
Paragraph (version B):
Values do not need to be encoded on the minimum number of bytes
necessary, with the sole exception of the Frame Type field; see
frames.
Draft: draft-ietf-quic-transport

Commentary:   said :
Paragraph (version A):
Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount
of data that can be sent on any stream.
Paragraph (version B):
Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount
of data that can be sent on a stream.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 I agree .
Paragraph (version A):
The receiving part of a stream enters the "Recv" state when the
sending part of a bidirectional stream initiated by the endpoint
(type 0 for a client, type 1 for a server) enters the "Ready" state.
Paragraph (version B):
For a bidirectional stream, the receiving part enters the "Recv"
state when the sending part initiated by the endpoint (type 0 for a
client, type 1 for a server) enters the "Ready" state.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 one suggestion but lgtm
Paragraph (version A):
Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines.  For the most part,
the use of these state machines is the same whether the stream is
unidirectional or bidirectional.  The conditions for opening a stream
are slightly more complex for a bidirectional stream because the
opening of either the send or receive side causes the stream to open
in both directions.
Paragraph (version B):
Unidirectional streams use either the sending or receiving state
machine depending on the stream type and endpoint role.
Bidirectional streams use both state machines at both endpoints.  For
the most part, the use of these state machines is the same whether
the stream is unidirectional or bidirectional.  The conditions for
opening a stream are slightly more complex for a bidirectional stream
because the opening of either the send or receive side causes the
stream to open in both directions.
Draft: draft-ietf-quic-transport

Commentary: said :
Paragraph (version A):
The stateless reset token MUST be difficult to guess.  In order to
create a Stateless Reset Token, an endpoint could randomly generate
(RFC4086) a secret for every connection that it creates.  However,
this presents a coordination problem when there are multiple
instances in a cluster or a storage problem for an endpoint that
might lose state.  Stateless reset specifically exists to handle the
case where state is lost, so this approach is suboptimal.
Paragraph (version B):
The stateless reset token MUST be difficult to guess.  In order to
create a Stateless Reset Token, an endpoint could randomly generate
(RANDOM) a secret for every connection that it creates.  However,
this presents a coordination problem when there are multiple
instances in a cluster or a storage problem for an endpoint that
might lose state.  Stateless reset specifically exists to handle the
case where state is lost, so this approach is suboptimal.
Draft: draft-ietf-quic-http

Commentary: … avoiding confusion with individual frame payloads ( editorial ) . This is related to the Semantics issue 
 has created on http - core Semantics draft , which describes how the term " payload " is overloaded when considered with the H2 and H3 docs .  's has a proposal to change that term in Semantics , which impacts the HTTP/3 draft . But he was kind enought to submit PR , which demonstrates the impact of that change . This issue is mainly for visibility and tracking purposes . 
 With or without suggestion . I need to do the same for h2 , so it is good to see suggestion
Paragraph (version A):
The term "payload data" is defined in Section 6.4 of SEMANTICS.
Paragraph (version B):
The term "content" is defined in Section 6.4 of SEMANTICS.
Paragraph (version A):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a
final response to the same request.  Interim responses do not contain
payload data or trailers.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a
final response to the same request.  Interim responses do not contain
content or trailers.
Paragraph (version A):
A request or response that includes payload data can include a
Content-Length header field.  A request or response is also malformed
if the value of a Content-Length header field does not equal the sum
of the DATA frame lengths that form the payload data.  A response
that is defined to have no payload, as described in Section 6.4 of
SEMANTICS, can have a non-zero Content-Length field, even though no
content is included in DATA frames.
Paragraph (version B):
A request or response that is defined as having content when it
contains a Content-Length header field (Section 6.4.1 of SEMANTICS),
is malformed if the value of a Content-Length header field does not
equal the sum of the DATA frame lengths received.  A response that is
defined as never having content, even when a Content-Length is
present, can have a non-zero Content-Length field even though no
content is included in DATA frames.
Paragraph (version A):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with HTTP request or response payload data.
Paragraph (version B):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with HTTP request or response content.
Draft: draft-ietf-quic-transport

Commentary: This was just old and needed a little bit of a refresh . Removing the recommendation , which was counter to established views and unnecessary . I will let others determine whether this is editorial / design . 
 said : 
 I think that the point of this section is to highlight the possibility that routing based on client - selected values exposes servers to load that is balanced under client - and therefore attacker - control . I do n't think that it needs to include such a strong recommendation . If people deploying load balancers are not concerned about this , then that is good . That makes the recommendation less good . As this is very old text , it needs a bit of a cleanup anyway . I 'm going to suggest something along the lines of my statement above in a pull request and we can polish the wording there . I do n't think that we should remove the Retry SCID language . That remains an option for servers , even if they do n't want to exercise the option ( whether load balancers look at Retry tokens is very much down to how the various functions are distributed ) . What could happen is that the Retry SCID is chosen so that the next initial can be routed as though it were chosen by a client , but in such a way as it results in the connection being sent to a lightly - loaded server instance . That is , if the load balancer routes inchoate Initials based on connection ID , knowledge of that routing algorithm is used to direct traffic . That said , I understand that what is more likely here is that Initials with inauthentic Destination Connection ID fields will be routed using other information : round - robin , random , five - tuple , or whatever . 
 I think you 're proposing that the text I quoted be deleted . That is satisfactory , and what I would recommend as well . 
 Returning to an open state as the chairs directed in their plan . 
 Closing this now that the IESG have approved the document(s ) . 
 To be safe , let 's mark this design .
Paragraph (version A):
Deployments should limit the ability of an attacker to target a new
connection to a particular server instance.  This means that client-
controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions.  Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to
route later packets to the same server.
Paragraph (version B):
Deployments should limit the ability of an attacker to target a new
connection to a particular server instance.  Ideally, routing
decisions are made independently of client-selected values, including
addresses.  Once an instance is selected, a connection ID can be
selected so that later packets are routed to the same instance.
Draft: draft-ietf-quic-transport

Commentary: Competing for least - impactful PR ever ....
Paragraph (version A):
This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6, 14, 30, or 62 bit values respectively.  integer-summary
summarizes the encoding properties.
Paragraph (version B):
This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6-, 14-, 30-, or 62-bit values respectively.  integer-summary
summarizes the encoding properties.
Draft: draft-ietf-quic-tls

Commentary: The three points are wordy enough it might be worth making this a bulleted list , however . Thoughts ? 
 said : 
 With fixes , this is good .
Paragraph (version A):
An endpoint cannot discard keys for a given encryption level unless
it has both received and acknowledged all CRYPTO frames for that
encryption level and when all CRYPTO frames for that encryption level
have been acknowledged by its peer.  However, this does not guarantee
that no further packets will need to be received or sent at that
encryption level because a peer might not have received all the
acknowledgments necessary to reach the same state.
Paragraph (version B):
An endpoint cannot discard keys for a given encryption level unless
it has received all the cryptographic handshake messages from its
peer at that encryption level and its peer has done the same.
Different methods for determining this are provided for Initial keys
(discard-initial) and Handshake keys (discard-handshake).  These
methods do not prevent packets from being received or sent at that
encryption level because a peer might not have received all the
acknowledgments necessary.
Draft: draft-ietf-quic-transport

Commentary: notes : requiring the disabling of the spin bit on a fraction of connections is useful . This may be worth a sentence of explanation . My understanding is that this exists both to protect the ability of endpoints to opt out and to ensure that monitoring is robust when the opt - out is exercised . 
 Also to ensure that if the functionality is removed / changed in a future version of QUIC , we 're only changing the percentage of traffic that enables it versus creating something new .
Paragraph (version A):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, endpoints MUST disable their use of the spin bit
for a random selection of at least one in every 16 network paths, or
for one in every 16 connection IDs.  As each endpoint disables the
spin bit independently, this ensures that the spin bit signal is
disabled on approximately one in eight network paths.
Paragraph (version B):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, endpoints MUST disable their use of the spin bit
for a random selection of at least one in every 16 network paths, or
for one in every 16 connection IDs, in order to ensure that QUIC
connections that disable the spin bit are commonly observed on the
network.  As each endpoint disables the spin bit independently, this
ensures that the spin bit signal is disabled on approximately one in
eight network paths.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 This was talked about on the IESG telechat 2020 - 01 - 07 . The action item is to add clarity for what an endpoint that does not support the spin bit should do . Note that this is distinct from an endpoint that supports spin bit but chooses to disable it . The discussion leaned towards an editorial change to the text in Section 17.4 , for instance in paragraph 3 . IIUC no other changes are needed to resolve this discuss , but we should confirm this via email . 
 I do n't get this . The following text seems abundantly clear : Or is it this ? Where we do n't say that optional = = disable it ? If that is all , I 'm going to hold my tongue . 
 -- this is good now . Thanks !
Paragraph (version A):
The spin bit is an OPTIONAL feature of this version of QUIC.  A QUIC
stack that chooses to support the spin bit MUST implement it as
specified in this section.
Paragraph (version B):
The spin bit is an OPTIONAL feature of this version of QUIC.  An
endpoint that does not support this feature MUST disable it, as
defined below.
Draft: draft-ietf-quic-transport

Commentary: No need for a SHOULD here . ( No issue yet . ) 
 Murray might have more choice words .
Paragraph (version A):
An endpoint MAY enter the draining state from the closing state if it
receives a CONNECTION_CLOSE frame, which indicates that the peer is
also closing or draining.  In this case, the draining state SHOULD
end when the closing state would have ended.  In other words, the
endpoint uses the same end time, but ceases transmission of any
packets on this connection.
Paragraph (version B):
An endpoint MAY enter the draining state from the closing state if it
receives a CONNECTION_CLOSE frame, which indicates that the peer is
also closing or draining.  In this case, the draining state ends when
the closing state would have ended.  In other words, the endpoint
uses the same end time, but ceases transmission of any packets on
this connection.
Draft: draft-ietf-quic-tls

Commentary: As agreed via mail . 
 said : 
 Response provided via email . 
 This is probably something we need a consensus call on , even though it 's a change only in theory . 
 Returning to an open state as the chairs directed in their plan . 
 Closing this now that the IESG have approved the document(s ) . 
 This gets the job done , with or without the suggested rewording .
Paragraph (version B):
Negotiating the quic_transport_parameters extension causes the
EndOfEarlyData to be removed; see remove-eoed.
Draft: draft-ietf-quic-transport

Commentary: This might conflict , but I think it supersedes the other " off - path " tweaks . 
 said :
Paragraph (version A):
An on-the-side attacker can duplicate and send packets with modified
ECN fields to affect the sender's rate.  If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this
attack.  Therefore, QUIC endpoints ignore the ECN field on an IP
packet unless at least one QUIC packet in that IP packet is
successfully processed; see ecn.
Paragraph (version B):
A limited on-path attacker can duplicate and send packets with
modified ECN fields to affect the sender's rate.  If duplicate
packets are discarded by a receiver, an attacker will need to race
the duplicate packet against the original to be successful in this
attack.  Therefore, QUIC endpoints ignore the ECN field on an IP
packet unless at least one QUIC packet in that IP packet is
successfully processed; see ecn.
Draft: draft-ietf-quic-transport

Commentary: said : 
 I believe that we are perfectly OK for the handshake . We can cite Section 8.1 ( again ) for this ( it 's the third paragraph primarily ) . This is deliberately not specified other places . Mostly because it is hard , but also because any definition would be unnecessarily constraining . I do n't agree with  that this absolutely needs specification .
Paragraph (version A):
The Source and Destination Connection ID fields are the primary means
of protection against off-path attack during the handshake.  These
are required to match those set by a peer.  Except for an Initial and
stateless reset packets, an endpoint only accepts packets that
include a Destination Connection ID field that matches a value the
endpoint previously chose.  This is the only protection offered for
Version Negotiation packets.
Paragraph (version B):
The Source and Destination Connection ID fields are the primary means
of protection against off-path attack during the handshake; see
validate-handshake.  These are required to match those set by a peer.
Except for an Initial and stateless reset packets, an endpoint only
accepts packets that include a Destination Connection ID field that
matches a value the endpoint previously chose.  This is the only
protection offered for Version Negotiation packets.
Draft: draft-ietf-quic-transport

Commentary: Error because you were going to violate the transport parameters we negotiated . You know you were ! YOU KNOW IT ! 
 said : 
 I guess we were missing future tense , which would have made this sentence really fun .
Paragraph (version A):
An endpoint received transport parameters that were badly
formatted, included an invalid value, was absent even though it is
mandatory, was present though it is forbidden, or is otherwise in
error.
Paragraph (version B):
An endpoint received transport parameters that were badly
formatted, included an invalid value, omitted a mandatory
transport parameter, included a forbidden transport parameter, or
were otherwise in error.
Draft: draft-ietf-quic-transport

Commentary: The second iteration piece is cruft and confusing . 
 said : 
 I think that 's an oops . I 'll cut that . It 's just the PRF part we need .
Paragraph (version A):
A single static key can be used across all connections to the same
endpoint by generating the proof using a second iteration of a
preimage-resistant function that takes a static key and the
connection ID chosen by the endpoint (see connection-id) as input.
An endpoint could use HMAC RFC2104 (for example, HMAC(static_key,
connection_id)) or HKDF RFC5869 (for example, using the static key as
input keying material, with the connection ID as salt).  The output
of this function is truncated to 16 bytes to produce the Stateless
Reset Token for that connection.
Paragraph (version B):
A single static key can be used across all connections to the same
endpoint by generating the proof using a pseudorandom function that
takes a static key and the connection ID chosen by the endpoint (see
connection-id) as input.  An endpoint could use HMAC RFC2104 (for
example, HMAC(static_key, connection_id)) or HKDF RFC5869 (for
example, using the static key as input keying material, with the
connection ID as salt).  The output of this function is truncated to
16 bytes to produce the Stateless Reset Token for that connection.
Draft: draft-ietf-quic-transport

Commentary: Follow up to . 
 Much more precise , thanks .
Paragraph (version A):
Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address.  It SHOULD drop packets
for this connection received on the old IP address, but can continue
to process delayed packets.
Paragraph (version B):
Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address.  The server SHOULD drop
newer packets for this connection that are received on the old IP
address.  The server MAY continue to process delayed packets that are
received on the old IP address.
Draft: draft-ietf-quic-transport

Commentary: CLoses . 
 said :
Paragraph (version A):
An address validation token MUST be difficult to guess.  Including a
large enough random value in the token would be sufficient, but this
depends on the server remembering the value it sends to clients.
Paragraph (version B):
An address validation token MUST be difficult to guess.  Including a
random value with at least 128 bits of entropy in the token would be
sufficient, but this depends on the server remembering the value it
sends to clients.
Draft: draft-ietf-quic-transport

Commentary: So just reference that as fact instead . 
 said : 
 Yes . A reference should do instead .
Paragraph (version A):
When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already
completed address validation.  If the token is invalid then the
server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry.  A server SHOULD
encode tokens provided with NEW_TOKEN frames and Retry packets
differently, and validate the latter more strictly.  If the
validation succeeds, the server SHOULD then allow the handshake to
proceed.
Paragraph (version B):
When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already
completed address validation.  If the token is invalid then the
server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry.  Tokens provided with
NEW_TOKEN frames and Retry packets can be distinguished by servers
(see token-differentiation), and the latter validated more strictly.
If the validation succeeds, the server SHOULD then allow the
handshake to proceed.