jiebi/CodeConvo huggingface dataset:
Change:
Not repetitions, which might be read to mean one or more occurrences. This change will conflict, but the conflict is easy to resolve.
NAME said:
It is zero or more occurrences is correct and will adjust the text accordingly.

Discussion:
Indicates that x is optional (and has length of L) <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del> <ins> Indicates that zero or more instances of x are present (and that each instance is length L) </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.
Change:
The second iteration piece is cruft and confusing.
NAME said:
I think that's an oops. I'll cut that. It's just the PRF part we need.

Discussion:
case where state is lost, so this approach is suboptimal. A single static key can be used across all connections to the same <del> 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. </del> <ins> 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. </ins> An endpoint that loses state can use the same method to generate a valid Stateless Reset Token.  The connection ID comes from the packet
Change:
Error because you were going to violate the transport parameters we negotiated. You know you were! YOU KNOW IT!
NAME said:
I guess we were missing future tense, which would have made this sentence really fun.

Discussion:
carry. An endpoint received transport parameters that were badly <del> formatted, included an invalid value, was absent even though it is mandatory, was present though it is forbidden, or is otherwise in error. </del> <ins> formatted, included an invalid value, omitted a mandatory transport parameter, included a forbidden transport parameter, or were otherwise in error. </ins> The number of connection IDs provided by the peer exceeds the advertised active_connection_id_limit.
Change:
NAME 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 don't agree with Fernando that this absolutely needs specification.

Discussion:
discard packets that are received on a different network path. The Source and Destination Connection ID fields are the primary means <del> 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. </del> <ins> 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. </ins> The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose.
Change:
This might conflict, but I think it supersedes the other "off-path" tweaks.
NAME said:

Discussion:
IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail. <del> 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 </del> <ins> 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 </ins> 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.
Change:
No need for a SHOULD here. (No issue yet.)
Murray might have more choice words.

Discussion:
An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is <del> 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. </del> <ins> 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. </ins> 10.2.3.
Change:
Rob Wilton 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 don't get this. The following text seems abundantly clear: Or is it this? Where we don't say that optional == disable it? If that is all, I'm going to hold my tongue.
NAME -- this is good now. Thanks!

Discussion:
measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. <del> 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. </del> <ins> 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. </ins> Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection.  Implementations MUST allow administrators
Change:
NAME 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.

Discussion:
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 <del> 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. </del> <ins> 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. </ins> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that
Change:
With one exception.
Rob Wilton said:
The one case where non-optimal encodings are forbidden is URL Otherwise, there is no restriction. Yes, 3 can be encoded in 8 bytes. But it is worth noting. (I thought that we had.)

Discussion:
Examples and a sample decoding algorithm are shown in sample-varint. <ins> 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. </ins> Versions (versions), packet numbers sent in the header (packet- encoding), and the length of connection IDs in long header packets (long-header) are described using integers, but do not use this
Change:
So I rewrote the sentence instead.
packet-type-specific?
Rob Wilton 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.

Discussion:
The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types. <del> The lower four bits (those with a mask of 0x0f) of byte 0 are type-specific. </del> <ins> The semantics of the lower four bits (those with a mask of 0x0f) of byte 0 are determined by the packet type. </ins> The QUIC Version is a 32-bit field that follows the first byte. This field indicates the version of QUIC that is in use and
Change:
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.

Discussion:
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> <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
Change:
É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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
... 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}})...."?

Discussion:
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> <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
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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