jiebi/TextFlow huggingface dataset:
Original text:
risk that differing semantics are attributed to the same codepoint by different implementations. <del> 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. </del>  For codepoints that are encoded in variable-length integers (integer- encoding), such as frame types, codepoints that encode to four or

Reviewer comments:
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.

Revised text:
risk that differing semantics are attributed to the same codepoint by different implementations.  <ins> 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. </ins> For codepoints that are encoded in variable-length integers (integer- encoding), such as frame types, codepoints that encode to four or
Original text:
Endpoints communicate in QUIC by exchanging QUIC packets.  Most packets contain frames, which carry control information and <del> 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. </del>  Application protocols exchange information over a QUIC connection via streams, which are ordered sequences of bytes.  Two types of stream

Reviewer comments:
Éric Vyncke 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 don'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 don'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.

Revised text:
Endpoints communicate in QUIC by exchanging QUIC packets.  Most packets contain frames, which carry control information and  <ins> 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. </ins> Application protocols exchange information over a QUIC connection via streams, which are ordered sequences of bytes.  Two types of stream
Original text:
4. <del> 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. </del>  Similarly, to limit concurrency within a connection, a QUIC endpoint controls the maximum cumulative number of streams that its peer can

Reviewer comments:
Barry Leiba 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.

Revised text:
4.  <ins> 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. </ins> Similarly, to limit concurrency within a connection, a QUIC endpoint controls the maximum cumulative number of streams that its peer can
Original text:
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 <del> 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. </del>  A server MAY limit the number of Version Negotiation packets it sends.  For instance, a server that is able to recognize packets as

Reviewer comments:
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.

Revised text:
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  <ins> a response or it abandons the connection attempt. </ins> A server MAY limit the number of Version Negotiation packets it sends.  For instance, a server that is able to recognize packets as
Original text:
QUIC can use the session resumption feature of TLS 1.3.  It does this by carrying NewSessionTicket messages in CRYPTO frames after the <del> handshake is complete.  Session resumption is the basis of 0-RTT, but can be used without also enabling 0-RTT. </del>  Endpoints that use session resumption might need to remember some information about the current connection when creating a resumed

Reviewer comments:
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".
NAME 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 wouldn'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.

Revised text:
QUIC can use the session resumption feature of TLS 1.3.  It does this by carrying NewSessionTicket messages in CRYPTO frames after the  <ins> handshake is complete.  Session resumption can be used to provide 0-RTT, and can also be used when 0-RTT is disabled. </ins> Endpoints that use session resumption might need to remember some information about the current connection when creating a resumed
Original text:
routing of packets across multiple network paths will also allow activity on those paths to be linked by entities other than the peer. <del> 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. </del>  An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts

Reviewer comments:
... is good for linkability.
Éric Vyncke said:
I don'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 can'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}})...."?

Revised text:
routing of packets across multiple network paths will also allow activity on those paths to be linked by entities other than the peer.  <ins> 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. </ins> An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts
Original text:
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 <del> 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. </del>  When an endpoint issues a connection ID, it MUST accept packets that carry this connection ID for the duration of the connection or until

Reviewer comments:
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 can't use the value it puts in Retry. Rather than talk about retaining the values, I'm striking that clause.
Rob Wilton said:
This refers to the one instance where the connection ID does need to be randomly generated; see URL

Revised text:
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  <ins> 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. </ins> When an endpoint issues a connection ID, it MUST accept packets that carry this connection ID for the duration of the connection or until
Original text:
If the sender wants to elicit a faster acknowledgment on PTO, it can skip a packet number to eliminate the acknowledgment delay. <del> 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. </del>  It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new

Reviewer comments:
Despite how the diff appears at first glance, I've only changed the first two sentences.
NAME said:
This changes the emphasis slightly, but in a good way.

Revised text:
If the sender wants to elicit a faster acknowledgment on PTO, it can skip a packet number to eliminate the acknowledgment delay.  <ins> 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. </ins> It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new
Original text:
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 <del> networks that also have inadequately secured UDP endpoints. </del>  Although it is not generally possible to ensure that clients are not co-located with vulnerable endpoints, this version of QUIC does not

Reviewer comments:
This is already something we recommend separately, but this is a SHOULD and the extra is useful.
Roman Danyliw 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 aren'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 don'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 NAME 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.
NAME could you comment on the proposed resolution?
Thanks for the refined text. The reference to ingress filtering makes it clearer. Consider this COMMENT resolved.

Revised text:
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  <ins> networks that do not deploy ingress filtering BCP38 and also have inadequately secured UDP endpoints. </ins> Although it is not generally possible to ensure that clients are not co-located with vulnerable endpoints, this version of QUIC does not
Original text:
certificate and can therefore read these 1-RTT packets. A sender SHOULD restart its PTO timer every time an ack-eliciting <del> packet is sent or acknowledged, when the handshake is confirmed (Section 4.1.2 of QUIC-TLS), or when Initial or Handshake keys are </del>  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.

Reviewer comments:
Ian is right, we would lose the Initial discard condition. Drop the Handshake key drop condition.
NAME -- 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.
NAME said:
Yes, this should be only about handshake confirmation. Thanks for catching this!

Revised text:
certificate and can therefore read these 1-RTT packets. A sender SHOULD restart its PTO timer every time an ack-eliciting  <ins> packet is sent or acknowledged, or when Initial or Handshake keys are </ins> 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.
Original text:
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 <del> 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. </del>  This design obviates the need for disambiguating between transmissions and retransmissions; this eliminates significant

Reviewer comments:
Roman Danyliw said:
I believe the mapping from encryption level to PNS is detailed in section 12.3 of transport: URL
I can't find the text being commented on.
NAME text is in the first paragraph of URL
It might be useful to point to the specific section in -transport that NAME mentioned in his comment. Anyone care to propose a PR?

Revised text:
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  <ins> 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. </ins> This design obviates the need for disambiguating between transmissions and retransmissions; this eliminates significant
Original text:
A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes by adding PADDING frames to the Initial packet or <del> by coalescing the Initial packet; see packet-coalesce.  Similarly, a server MUST expand the payload of all UDP datagrams carrying ack- eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes.  Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions.  Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </del>  Datagrams containing Initial packets MAY exceed 1200 bytes if the sender believes that the network path and peer both support the size

Reviewer comments:
This seems to have caused problems, so address it.
This text in seems to cause confusion for implementors: since it leaves it unclear what the Initial packet can be coalesced with to pad it. Specifically, some implementations use zeros or other (random) data, which seems to surprise some implementors. (, which is referred to, also doesn't seem to clarify this.)
My understanding is that transport draft does not say anything about padding outside QUIC packet. Because a receiver is required to ignore invalid long packets, zero padding outside QUIC packet just works. So this is "OK because it is not explicitly disallowed" category.
I agree, but it has tripped up implementers (again). I wonder if a wording can be found that doesn't do that.
I'd be happy to see a bit more explicit text to clarify this, since as you said, it's come up a few times as non-obvious.
Maybe something like: "An Initial that is padded by coalescing could be coalesced with valid or even invalid QUIC packets; the latter MUST be ignored as described in Section XYZ."

Revised text:
A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes by adding PADDING frames to the Initial packet or  <ins> by coalescing the Initial packet; see packet-coalesce.  Initial packets can even be coalesced with invalid packets, which a receiver will discard.  Similarly, a server MUST expand the payload of all UDP datagrams carrying ack-eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes. Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions.  Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address- validation. </ins> Datagrams containing Initial packets MAY exceed 1200 bytes if the sender believes that the network path and peer both support the size