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

Commentary:   said : 
 I believe the mapping from encryption level to PNS is detailed in section 12.3 of transport : 
 I ca n't find the text being commented on . 
 text is in the first paragraph of 
 It might be useful to point to the specific section in -transport that mentioned in his comment . Anyone care to propose a PR ?
Paragraph (version A):
All transmissions in QUIC are sent with a packet-level header, which
indicates the encryption level and includes a packet sequence number
(referred to below as a packet number).  The encryption level
indicates the packet number space, as described in QUIC-TRANSPORT.
Packet numbers never repeat within a packet number space for the
lifetime of a connection.  Packet numbers are sent in monotonically
increasing order within a space, preventing ambiguity.
Paragraph (version B):
All transmissions in QUIC are sent with a packet-level header, which
indicates the encryption level and includes a packet sequence number
(referred to below as a packet number).  The encryption level
indicates the packet number space, as described in Section 12.3 of
QUIC-TRANSPORT.  Packet numbers never repeat within a packet number
space for the lifetime of a connection.  Packet numbers are sent in
monotonically increasing order within a space, preventing ambiguity.
Draft: draft-ietf-quic-recovery

Commentary: said 
 LG , one suggestion
Paragraph (version A):
To speed up handshake completion under these conditions, an endpoint
MAY, for a limited number of occasions per each connection, send a
packet containing unacknowledged CRYPTO data earlier than the PTO
expiry, subject to the address validation limits in Section 8.1 of
QUIC-TRANSPORT.  Doing so at most once for each connection is
adequate to quickly recover from a single packet loss.  Endpoints
that do not cease retransmitting packets in response to
unauthenticated data risk creating an infinite exchange of packets.
Paragraph (version B):
To speed up handshake completion under these conditions, an endpoint
MAY, for a limited number of times per connection, send a packet
containing unacknowledged CRYPTO data earlier than the PTO expiry,
subject to the address validation limits in Section 8.1 of QUIC-
TRANSPORT.  Doing so at most once for each connection is adequate to
quickly recover from a single packet loss.  An endpoint that always
retransmits packets in response to receiving packets that it cannot
process risks creating an infinite exchange of packets.
Draft: draft-ietf-quic-tls

Commentary: It all belongs in the same place .
Paragraph (version A):
In this document, the TLS handshake is considered confirmed at the
server when the handshake completes.  At the client, the handshake is
considered confirmed when a HANDSHAKE_DONE frame is received.
Paragraph (version B):
In this document, the TLS handshake is considered confirmed at the
server when the handshake completes.  The server MUST send a
HANDSHAKE_DONE frame as soon as the handshake is complete.  At the
client, the handshake is considered confirmed when a HANDSHAKE_DONE
frame is received.
Paragraph (version A):
An endpoint MUST discard its handshake keys when the TLS handshake is
confirmed (handshake-confirmed).  The server MUST send a
HANDSHAKE_DONE frame as soon as it completes the handshake.
Paragraph (version B):
An endpoint MUST discard its handshake keys when the TLS handshake is
confirmed (handshake-confirmed).
Draft: draft-ietf-quic-recovery

Commentary:  is right , we would lose the Initial discard condition . Drop the Handshake key drop condition . 
 -- you 're right , but I think that only applies to Initial here , since hs confirmed is the same as hs keys getting dropped . Take a look at the new text . 
 said : 
 Yes , this should be only about handshake confirmation . Thanks for catching this !
Paragraph (version A):
A sender SHOULD restart its PTO timer every time an ack-eliciting
packet is sent or acknowledged, when the handshake is confirmed
(Section 4.1.2 of QUIC-TLS), or when Initial or Handshake keys are
discarded (Section 4.9 of QUIC-TLS).  This ensures the PTO is always
set based on the latest estimate of the round-trip time and for the
correct packet across packet number spaces.
Paragraph (version B):
A sender SHOULD restart its PTO timer every time an ack-eliciting
packet is sent or acknowledged, or when Initial or Handshake keys are
discarded (Section 4.9 of QUIC-TLS).  This ensures the PTO is always
set based on the latest estimate of the round-trip time and for the
correct packet across packet number spaces.
Draft: draft-ietf-quic-transport

Commentary: This is already something we recommend separately , but this is a SHOULD and the extra is useful . 
   said : 
 It might not be entirely realistic , in that the person deploying a server might not be aware of unsecure endpoints around them , but it 's better to have the caution present than say nothing . 
 I think that it is moderately realistic for most deployments . There are n't so many UDP - based protocols out there in common usage . Besides , conducting an audit , if you did not already know , would be healthy . From another angle , a reason to include this is that if you have a firewall , deploy a QUIC server behind that firewall , and do n't know what else is behind that firewall , then us writing this text makes it clear where fault lies if something bad happens . 
 This is not an editorial issue . I think that it is an excellent question , and definitely the sort of question I would expect the IESG to press on . FWIW , I think that this response would be totally unreasonable if this were TCP instead of UDP , which implies that there is a degree of subjectivity involved in the decision . The working group position suggests no action , but I want to confirm that is satisfied with that response . As this was only a comment , not DISCUSS , I 'm going to assume that this is OK unless I 'm told otherwise . 
 Would it help to more tightly scope the definition of " networks " ? One absurd reading is that QUIC should not be deployed on Internet facing networks because there is not a 0 % chance of some unsecured UDP listening host somewhere . 
 I think we might be able to say " networks without ingress filtering [ BCP38 ] " . Servers are only vulnerable to these attacks if they ( or their network ) permit source address spoofing . 
 WfMq 
 I think the addition of BCP 38 makes it much more pointed and realistic . Overall , this is an important cautionary note . We decided that instead of trying to fix this in the protocol , it made sense to force those deploying QUIC to consider the implications of the environment in which they are doing it . 
 could you comment on the proposed resolution ? 
 Thanks for the refined text . The reference to ingress filtering makes it clearer . Consider this COMMENT resolved .
Paragraph (version A):
Because the migration attack described in request-forgery-with-
spoofed-migration is quite powerful and does not have adequate
countermeasures, QUIC server implementations should assume that
attackers can cause them to generate arbitrary UDP payloads to
arbitrary destinations.  QUIC servers SHOULD NOT be deployed in
networks that also have inadequately secured UDP endpoints.
Paragraph (version B):
Because the migration attack described in request-forgery-with-
spoofed-migration is quite powerful and does not have adequate
countermeasures, QUIC server implementations should assume that
attackers can cause them to generate arbitrary UDP payloads to
arbitrary destinations.  QUIC servers SHOULD NOT be deployed in
networks that do not deploy ingress filtering BCP38 and also have
inadequately secured UDP endpoints.
Draft: draft-ietf-quic-recovery

Commentary: said : 
 Yep , it 's open season on delay too . Sorry about the suggestions .
Paragraph (version A):
Congestion control fundamentally involves the consumption of signals
- both loss and ECN codepoints - from unauthenticated entities.  On-
path attackers can spoof or alter these signals.  An attacker can
cause endpoints to reduce their sending rate by dropping packets, or
alter send rate 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.
Draft: draft-ietf-quic-recovery

Commentary: Despite how the diff appears at first glance , I 've only changed the first two sentences . 
 said : 
 This changes the emphasis slightly , but in a good way .
Paragraph (version A):
When the PTO timer expires, an ack-eliciting packet MUST be sent.  An
endpoint SHOULD include new data in this packet.  Previously sent
data MAY be sent if no new data can be sent.  Implementations MAY use
alternative strategies for determining the content of probe packets,
including sending new or retransmitted data based on the
application's priorities.
Paragraph (version B):
An endpoint SHOULD include new data in packets that are sent on PTO
expiration.  Previously sent data MAY be sent if no new data can be
sent.  Implementations MAY use alternative strategies for determining
the content of probe packets, including sending new or retransmitted
data based on the application's priorities.
Draft: draft-ietf-quic-transport

Commentary: The value the client puts in the Destination Connection ID field is not random , but unpredictable . But we could be clearer and just say what this refers to . The second error here was that the server ca n't use the value it puts in Retry . Rather than talk about retaining the values , I 'm striking that clause . 
   said : 
 This refers to the one instance where the connection ID does need to be randomly generated ; see
Paragraph (version A):
Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (frame-new-connection-id).  The sequence
number on each newly issued connection ID MUST increase by 1.  The
connection ID randomly selected by the client in the Initial packet
and any connection ID provided by a Retry packet are not assigned
sequence numbers unless a server opts to retain them as its initial
connection ID.
Paragraph (version B):
Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (frame-new-connection-id).  The sequence
number on each newly issued connection ID MUST increase by 1.  The
connection ID that a client selects for the first Destination
Connection ID field it sends and any connection ID provided by a
Retry packet are not assigned sequence numbers.
Draft: draft-ietf-quic-transport

Commentary: This was a little tricky as the current text already had what we wanted . But it was n't quite clear on rationale , so I some of that . 
   said : 
 I believe that the view was that a PRNG was inferior to a PRF because it required state , but yes , it should be fine . Should we have avoided repeating advice from 6437 ? ( I forget who contributed this text , but I think that it was an RFC 6437 author . ) 
 Text originates with Christian in . A few people have touched it since for editorial purposes , but that does n't change the point of what you 're asking about .
Paragraph (version A):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
Destination Connection ID field.  The flow label generation MUST be
designed to minimize the chances of linkability with a previously
used flow label, as a stable flow label would enable correlating
activity on multiple paths; see migration-linkability.
Paragraph (version A):
A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses,
source and destination UDP ports, Destination Connection ID field,
and a local secret.
Paragraph (version B):
The flow label generation MUST be designed to minimize the chances of
linkability with a previously used flow label, as a stable flow label
would enable correlating activity on multiple paths; see migration-
linkability.
Paragraph (version B):
RFC6437 suggests deriving values using a pseudorandom function to
generate flow labels.  Including the Destination Connection ID field
in addition to source and destination addresses when generating flow
labels ensures that changes are synchronized with changes in other
observable identifiers.  A cryptographic hash function that combines
these inputs with a local secret is one way this might be
implemented.
Draft: draft-ietf-quic-transport

Commentary: ... is good for linkability . 
   said : 
 I do n't think that is appropriate in the general case . However , in , we say this : We could point to privacy addresses as an option here . That is not a bad idea as IPv6 clients ca n't rely on NAT to the same extent that IPv4 clients do . 
 Using " optionally " inside " might wish to " seems overly wishy - washy . How about " employing a new connection ID , source UDP port , and/or IP address ( see { { ? RFC4941 } } ) .... " ?
Paragraph (version A):
A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period
of inactivity.  Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection
migration.  This ensures that the mechanisms that support migration
are exercised even for clients that do not experience NAT rebindings
or genuine migrations.  Changing port number can cause a peer to
reset its congestion control state (see migration-cc), so the port
SHOULD only be changed infrequently.
Paragraph (version B):
A client might wish to reduce linkability by switching to a new
connection ID, source UDP port, or IP address (see RFC4941) when
sending traffic after a period of inactivity.  Changing the address
from which it sends packets at the same time might cause the server
to detect a connection migration.  This ensures that the mechanisms
that support migration are exercised even for clients that do not
experience NAT rebindings or genuine migrations.  Changing address
can cause a peer to reset its congestion control state (see
migration-cc), so addresses SHOULD only be changed infrequently.
Draft: draft-ietf-quic-recovery

Commentary: This should be fixed . I 've sent out . 
 The natural question that follows will be " which period of time " , but I think that is already . Thanks , LG
Paragraph (version A):
At a high level, an endpoint measures the time from when a packet was
sent to when it is acknowledged as a round-trip time (RTT) sample.
The endpoint uses RTT samples and peer-reported host delays (see
Section 13.2 of QUIC-TRANSPORT) to generate a statistical description
of the network path's RTT.  An endpoint computes the following three
values for each path: the minimum value observed over the lifetime of
the path (min_rtt), an exponentially-weighted moving average
(smoothed_rtt), and the mean deviation (referred to as "variation" in
the rest of this document) in the observed RTT samples (rttvar).
Paragraph (version B):
At a high level, an endpoint measures the time from when a packet was
sent to when it is acknowledged as a round-trip time (RTT) sample.
The endpoint uses RTT samples and peer-reported host delays (see
Section 13.2 of QUIC-TRANSPORT) to generate a statistical description
of the network path's RTT.  An endpoint computes the following three
values for each path: the minimum value over a period of time
(min_rtt), an exponentially-weighted moving average (smoothed_rtt),
and the mean deviation (referred to as "variation" in the rest of
this document) in the observed RTT samples (rttvar).
Paragraph (version A):
min_rtt is the sender's estimate of the minimum RTT observed for a
given network path.  In this document, min_rtt is used by loss
detection to reject implausibly small rtt samples.
Paragraph (version B):
min_rtt is the sender's estimate of the minimum RTT observed for a
given network path over a period of time.  In this document, min_rtt
is used by loss detection to reject implausibly small rtt samples.
Draft: draft-ietf-quic-tls

Commentary: Resumption is not quite the basis of 0 - RTT , since it is also allowed to pre - provision an external PSK and other parameters and do 0 - RTT that way . This also allows a rewording to avoid implying that 0 - RTT would need to be enabled by configuration , since it is supposed to just be " on by default " . 
 said : 
 Having just reviewed all instances of 0 - RTT , I 'm not seeing anything that I disagree with in terms of tone and posture . Most of the language does treat 0 - RTT as a normal part of the protocol , though it is very careful to highlight the risks . I think that is entirely appropriate . Short of being provided with specific problems or recommendations , I propose no action here . 
 How do you feel about s / Session resumption is the basis of 0 - RTT , but can be used without also enabling 0 - RTT./Session resumption can be used to enable 0 - RTT , and can also be used when 0 - RTT is disabled./ ( recalling that we had another change to clarify that 0 - RTT can be used independently of resumption , if sufficient information is configured alongside the external PSK ) ? To clarify , the concern here is that if 0 - RTT is something that you " enable " , then there would be some precursor state where 0 - RTT is disabled by default . Disabled by default may not mesh very well with " normal part of the protocol " . Thank you for reviewing the other instances ; I only happened to notice this one place in Section 4.5 but was not specifically looking for others . 
 It 's a fine point , but I would n't object to making that change in line with other 0 - RTT changes . I think that the chances of ever seeing non - resumption 0 - RTT are so remote as to be irrelevant , but we can still be accurate .
Paragraph (version A):
QUIC can use the session resumption feature of TLS 1.3.  It does this
by carrying NewSessionTicket messages in CRYPTO frames after the
handshake is complete.  Session resumption is the basis of 0-RTT, but
can be used without also enabling 0-RTT.
Paragraph (version B):
QUIC can use the session resumption feature of TLS 1.3.  It does this
by carrying NewSessionTicket messages in CRYPTO frames after the
handshake is complete.  Session resumption can be used to provide
0-RTT, and can also be used when 0-RTT is disabled.
Draft: draft-ietf-quic-transport

Commentary: There was a sentence in this section that seems to be specifying how to handle a version negotiation packet , not how to send one , and as such is out of place . 
 I can see how this duplicates text from the next section and so is safe to remove . Thanks for separating and providing independent justification . I missed the justification before .
Paragraph (version A):
This system allows a server to process packets with unsupported
versions without retaining state.  Though either the Initial packet
or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt.  As a result, the
client discards all state for the connection and does not send any
more packets on the connection.
Paragraph (version B):
This system allows a server to process packets with unsupported
versions without retaining state.  Though either the Initial packet
or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 receiver / client is an invalid comparison here , so this is a bit of a confusing question . The point is to ensure that a receiver can limit what space it commits for buffering . 
 With the suggestions , this is a fine , if small , improvement .
Paragraph (version A):
It is necessary to limit the amount of data that a receiver could
buffer, to prevent a fast sender from overwhelming a slow receiver,
or to prevent a malicious sender from consuming a large amount of
memory at a receiver.  To enable a receiver to limit memory
commitment to a connection and to apply back pressure on the sender,
streams are flow controlled both individually and as an aggregate.  A
QUIC receiver controls the maximum amount of data the sender can send
on a stream at any time, as described in data-flow-control and fc-
credit.
Paragraph (version B):
Receivers need to limit the amount of data that they are required to
buffer, in order to prevent a fast sender from overwhelming them or a
malicious sender from consuming a large amount of memory.  To enable
a receiver to limit memory commitments for a connection, streams are
flow controlled both individually and across a connection as a whole.
A QUIC receiver controls the maximum amount of data the sender can
send on a stream as well as across all streams at any time, as
described in data-flow-control and fc-credit.
Draft: draft-ietf-quic-invariants

Commentary: This makes it clearer that the notation is copied from v1 , not defined there and normatively referenced . ( Note , figures are n't normative anyway . ) 
   said : 
 In my response to , I explain this . This ensures that the transport reference can remain informative . 
 Perhaps the intro needs to be reworded to indicate that it 's using some of the same conventions as the transport document , which are reproduced below ? 
   said : 
  's point ( captured in ) was that one or other might need to be normative . This is a different point , suggesting that this document concretely depends on the transport draft for terminology that has normative effect . Have n't checked , I do n't think that is the case and the reference can remain informative . The reason for that being that all of the terminology used in this draft is also defined in this draft . 
 Any other bids ?
Paragraph (version A):
Packet diagrams in this document use a format defined in QUIC-
TRANSPORT to illustrate the order and size of fields.
Paragraph (version B):
The format of packets is described using the notation defined in this
section.  This notation is the same as that used in QUIC-TRANSPORT.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 This is deliberate . Everything is authenticated ( absent some unused fields in Retry packets and Version Negotiation , which has a big TBD on it ) . As much as possible is encrypted . I 'm going to propose no action here . 
 Well , it 's not deliberate that he has trouble parsing it , so I do n't think that 's the right way to justify a no - action . This is an editorial comment . Something like " QUIC authenticates all packets ; as much of each packet as practical is also encrypted . " would make the same statement with less possibility of misunderstanding . As a native speaker , I do n't find the current text confusing , but I also realize that our audience includes those from different backgrounds ; I 'm not opposed to making an editorial change here .
Paragraph (version A):
Endpoints communicate in QUIC by exchanging QUIC packets.  Most
packets contain frames, which carry control information and
application data between endpoints.  QUIC authenticates all packets
and encrypts as much as is practical.  QUIC packets are carried in
UDP datagrams (UDP) to better facilitate deployment in existing
systems and networks.
Paragraph (version B):
Endpoints communicate in QUIC by exchanging QUIC packets.  Most
packets contain frames, which carry control information and
application data between endpoints.  QUIC authenticates the entirety
of each packet and encrypts as much of each packet as is practical.
QUIC packets are carried in UDP datagrams (UDP) to better facilitate
deployment in existing systems and networks.