jiebi/CodeConvo huggingface dataset:
Change:
ekr says there used to be stateless and stateful retry, but now there is just stateless. This is the only place the phrase is used, so instead just say "retry".

Discussion:
A Retry packet uses a long packet header with a type value of 0x3. It carries an address validation token created by the server.  It is <del> used by a server that wishes to perform a stateless retry (see validate-handshake). </del> <ins> used by a server that wishes to perform a retry (see validate- handshake). </ins> A Retry packet (shown in retry-format) does not contain any protected fields.  In addition to the long header, it contains these additional
Change:
NAME made a good suggestion in , which I have taken and tweaked further. It is not sufficient to discard ECN if one QUIC packet is discared, you need to discard ALL QUIC packets in the IP packet.
Sounds about right to me.
S 21.7 This could use more elaboration. As written, it seems like if you win the race (which you might like half the time) then you will succeed in the attack. Is that true?
Yes, the winner of a race can reduce the congestion window or maybe prevent it from being reduced.
As I see this: QUIC receivers ignore the ECN codepoint field received in IP packets that carry duplicate QUIC packets (see {{ecn}}).
So NAME is this resolved or do you expect more than what Martin wrote?
I think that I can make that call now. If there is a problem, we can open an issue.

Discussion:
ECN codepoints 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> attack.  Therefore, QUIC receivers ignore ECN codepoints set in duplicate packets (see ecn). </del> <ins> attack.  Therefore, QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn. </ins> 21.8.
Change:
When multiple connections share the same network path or multiple connection IDs are used for the same path, using the spin bit is complicated by the difficulty in correlating forward and reverse flows. There is currently text that uses RFC 6919 language in the draft recommending coordination of the spin to avoid this problem. However, as , this coordination seems difficult and therefore unlikely. It also creates a strong signal that indicates that all the connections on the path are terminated at the same endpoint on both ends. Maybe we don't want to be generating that signal. Also, because this coordination can't be guaranteed, the on-path observer is forced to build code for correlating/segregating measurements by connection ID in the case where there is no coordination. Maybe it's best just to remove this recommendation entirely.
+1 to removing the recommendation, or changing the statement to just a caution (e.g., if you are to coalesce connections that spin, then you'd better be aware of ...). FWIW I am not sure if I agree with this observation. IIUC, the connections sharing a 5-tuple will be terminated by the same endpoint on both ends; it is impossible for a middlebox to coalesce multiple QUIC connections. It is impossible because CIDs can change mid-connection, and a middlebox cannot determine to where the packets containing the new CID must be sent.
There definitely needs to be a degree of coordination between the middlebox and the endpoints, but that doesn't mean that you can't use something like the quic-lb stuff on either end (or both ends).
Yes, I think it is better to remove that recommendation, but perhaps replace it with a note to observers.
Text says: How would that work when 1/8th of the connections are not spinning? Wouldn't that either be sending a misleading signal, or violate the 1/8th rule?

Discussion:
the administrator, implementations MUST disable the spin bit for a given connection with a certain likelihood.  The random selection process SHOULD be designed such that on average the spin bit is <del> disabled for at least one eighth of connections.  The selection </del> <ins> disabled for at least one eighth of network paths.  The selection </ins> process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. <del> In case multiple connections share the same five-tuple, that is, have the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </del> <ins> In case multiple connections share the same network path, as determined by having the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </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:
In addition, remove verbiage stating that the settings values are integers, as the are integers by the definition of the SETTINGS frame.
Both specify the maximum value the decoder supports. The encoder is free to pick and use a smaller value. There is no reason to add artificial limits to the way an decoder is implemented.
This could be viewed as an alternative resolution to .
Also, historical note: These have maxima because settings used to be length-prefixed blobs. By defining them to be integers of a maximum size, the length could be constrained. Now that we use varints, there is a maximum structural size already.

Discussion:
QPACK defines two settings which are included in the HTTP/3 SETTINGS frame. <del> An integer with a maximum value of 2^30 - 1.  The default value is zero bytes.  See _table-dynamic for usage.  This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </del> <ins> The default value is zero.  See _table-dynamic for usage.  This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </ins> <del> An integer with a maximum value of 2^16 - 1.  The default value is zero.  See overview-hol-avoidance. </del> <ins> The default value is zero.  See overview-hol-avoidance. </ins> 6.
Change:
IIUC, RFC 2119 keywords used in RFC 7540 need to be converted to uppercase words in HTTP/3, because HTTP/3 invokes RFC 8174.
That was never an interoperability requirement, just a suggestion. So I think that this should be reverted. If it isn't, using the active voice might be better.

That was never an interoperability requirement, just a suggestion. So I think that this should be reverted. Originally posted by NAME in URL Look at a better way to phrase this guidance, while still retaining the guidance. (Note this text has also been touched by other PRs in the meantime.)

Discussion:
parameters "initial_max_stream_data_bidi_local".  An HTTP/3 server SHOULD send non-zero values for the QUIC transport parameters "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". <del> It is recommended that "initial_max_bidi_streams" be no smaller than </del> <ins> It is RECOMMENDED that "initial_max_bidi_streams" be no smaller than </ins> 100, so as to not unnecessarily limit parallelism. HTTP/3 does not use server-initiated bidirectional streams; clients
Change:
The client only replaces a token sent in Initial packets when receiving a Retry. NEW_TOKEN is an orthogonal mechanism to provide tickets for subsequent connections, and doesn't have any effect on the current connection.

Discussion:
future connections.  The client includes this token in Initial packets to provide address validation in a future connection.  The client MUST include the token in all Initial packets it sends, unless <del> a Retry or NEW_TOKEN frame replaces the token with a newer one.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </del> <ins> a Retry replaces the token with a newer one.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the
Change:
The server doesn't pick a version. The server only picks the application protocol from what the client offered, and it might do that based on the QUIC version that the client picked.
NAME That depends on how you read RFC 7301, doesn't it? Section 3.1 says: I interpret "suitable" as "one of the options that the client proposed", but unfortunately that RFC is not very specific.
That is confusing, but it doesn't mean that the server doesn't pick an ALPN. We do require that it select an ALPN value, and even if it picks one that the client doesn't offer (whether legitimate or not), that doesn't invalidate this text.
No, I was suggesting restoring the sentence that was there before, but with alternate wording to address NAME concern. Now the server MUST abort if it can't pick a proper combination, and the client MUST abort if the server fails to abide by that requirement.
I think removing the sentence entirely is the wrong approach.OK, I see now. Yes, this WFM.

Discussion:
compatible with the QUIC version that the client has selected.  If the server cannot select a compatible combination of application protocol and QUIC version, it MUST abort the connection.  A client <del> MUST abort a connection if the server picks an incompatible combination of QUIC version and ALPN identifier. </del> <ins> MUST abort a connection if the server picks an application protocol incompatible with the protocol version being used. </ins> 8.2.
Change:
Moves the "Retry and Version Negotiation" out of the "Crypto Retransmission Timeout" section in preparation for a redo of

Discussion:
When the crypto retransmission timer is active, the probe timer (pto) is not active. <del> 6.2.1. A Retry or Version Negotiation packet causes a client to send another Initial packet, effectively restarting the connection process and resetting congestion control and loss recovery state, including resetting any pending timers.  Either packet indicates that the Initial was received but not processed.  Neither packet can be treated as an acknowledgment for the Initial. The client MAY however compute an RTT estimate to the server as the time period from when the first Initial was sent to when a Retry or a Version Negotiation packet is received.  The client MAY use this value to seed the RTT estimator for a subsequent connection attempt to the server. </del> 6.3. A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data

6.4. <ins> A Retry or Version Negotiation packet causes a client to send another Initial packet, effectively restarting the connection process and resetting congestion control and loss recovery state, including resetting any pending timers.  Either packet indicates that the Initial was received but not processed.  Neither packet can be treated as an acknowledgment for the Initial. The client MAY however compute an RTT estimate to the server as the time period from when the first Initial was sent to when a Retry or a Version Negotiation packet is received.  The client MAY use this value to seed the RTT estimator for a subsequent connection attempt to the server. 6.5. </ins> When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed

might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). <del> 6.5. </del> <ins> 6.6. </ins> The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet.
Change:
This aligns section 4.5 with section 19.11's text: "An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted."
I'm going to recommend calling this editorial on the basis that it reconciles this text with another MUST-level requirement. But I will leave the issue open for the chairs to make a design/editorial assessment and any resulting consensus call.
In most places in QUIC, if an error is clearly avoidable(ie: only a buggy implementation would do so), then we advise closing the connection with an error, not just closing the stream with an error. In section 4.5 of transport(URL) it says: "Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAMLIMITERROR" Came up in discussion of
As I commented in the updated PR description, section 19.11 already says this: "An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted."
Reopening to keep this visible.
is effectively the proposal, correct?
Yes. It was editorial. So I merged it. But then this issue really isn't editorial.
Yes, I opened this issue, then found that text in section 19.11 in the doc said exceeding MAXSTREAMID was a connection error, so the PR ended up aligning the two sections.
In HTTP/3 Appendix A.4 it states : : HTTPREQUESTREJECTED (in {{http-error-codes}}) is used to indicate that a request was not processed. Otherwise, not applicable because QUIC handles stream management. A STREAMIDERROR at the QUIC layer is used for streams that are improperly opened. But STREAMIDERROR was removed in transport draft 17.
Since URL there are different error codes that the transport might use depending on error conditions (maybe STREAMSTATEERROR or maybe STREAMLIMITERROR). I'm inclined to simply omit the sentence.

Discussion:
immediate-close). Endpoints MUST NOT exceed the limit set by their peer.  An endpoint <del> that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR </del> <ins> that receives a frame with a stream ID exceeding the limit it has sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR </ins> (error-handling). Once a receiver advertises a stream limit using the MAX_STREAMS
Change:
The phrase, , is semantically equal to This is not correct since all streams don't create a (new) stream. Moreover, by definition, a stream is created by sending data[1] or STREAM frames implicitly create a stream[2]. This indicates a stream itself doesn't create another stream. [1] URL [2] URL
Looks good. Just a minor comment.

Discussion:
data on this stream.  Either frame might arrive before a STREAM or STREAM_DATA_BLOCKED frame if packets are lost or reordered. <del> Before creating a stream, all streams of the same type with lower- </del> <ins> Before a stream is created, all streams of the same type with lower- </ins> numbered stream IDs MUST be created.  This ensures that the creation order for streams is consistent on both endpoints.
Change:
Retry always changes the connection ID.
NAME The paragraph 2 before this one says exactly that.
Ah... I missed that. Thanks for pointing it out NAME

Discussion:
protection for all 0-RTT packets because the same key and nonce could be used to protect different content. <del> Receiving a Retry packet, especially a Retry that changes the connection ID used for subsequent packets, indicates a strong possibility that 0-RTT packets could be lost.  A client only receives acknowledgments for its 0-RTT packets once the handshake is complete. Consequently, a server might expect 0-RTT packets to start with a packet number of 0.  Therefore, in determining the length of the packet number encoding for 0-RTT packets, a client MUST assume that all packets up to the current packet number are in flight, starting from a packet number of 0.  Thus, 0-RTT packets could need to use a longer packet number encoding. </del> <ins> A client only receives acknowledgments for its 0-RTT packets once the handshake is complete.  Consequently, a server might expect 0-RTT packets to start with a packet number of 0.  Therefore, in determining the length of the packet number encoding for 0-RTT packets, a client MUST assume that all packets up to the current packet number are in flight, starting from a packet number of 0. Thus, 0-RTT packets could need to use a longer packet number encoding. </ins> A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot
Change:
Clients aren't forbidden from sending a Handshake packet before receiving the ServerHello, they just don't have the keys to do so.
LGTM

Discussion:
If the packet is a 0-RTT packet, the server MAY buffer a limited number of these packets in anticipation of a late-arriving Initial <del> Packet.  Clients are forbidden from sending Handshake packets prior to receiving a server response, so servers SHOULD ignore any such </del> <ins> packet.  Clients are not able to send Handshake packets prior to receiving a server response, so servers SHOULD ignore any such </ins> packets. Servers MUST drop incoming packets under all other circumstances.
Change:
As of -12, TLS records are not used in QUIC (TLS handshake messages are directly transmitted instead), and therefore it is impossible in QUIC to transmit early data using the machinery provided by TLS.

Discussion:
with any other value as a connection error of type PROTOCOL_VIOLATION. <del> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. </del> 4.6. A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This
Change:
It doesn't matter what an Initial is coalesced with. It could be a 0-RTT packet, it could be an (invalid) Handshake packet, or the bytes after the Initial packet could be completely random. The only thing that matters is that the resulting UDP datagram has at least 1200 bytes.
CI failure isn't my fault. The faulty commit seems to be bbe2b80d490c39c1d5900a5f00b4bbe11a29c4df.

Discussion:
The payload of a UDP datagram carrying the first Initial packet MUST be expanded to at least 1200 bytes, by adding PADDING frames to the <del> Initial packet and/or by combining the Initial packet with a 0-RTT packet (see packet-coalesce).  Sending a UDP datagram of this size ensures that the network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </del> <ins> Initial packet and/or by coalescing the Initial packet (see packet- coalesce).  Sending a UDP datagram of this size ensures that the network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address- validation. </ins> The datagram containing the first Initial packet from a client MAY exceed 1200 bytes if the client believes that the Path Maximum
Change:
FWIW, the state that was implied was the creation of a new connection. That's not realistic in QUICv1 however, so this is good.
I'm not following why in general this would create state. If the handshake has occurred > MSL ago, and you just refuse to create state on short packets with unknown CIDs s, why isn't that enough?
This was written when there was some uncertainty about what packets might look like. I think that we can truncate this sentence. Basically, you can drop state earlier, but it will mean that you won't be able to attribute any laggardly packets properly.

Discussion:
cease retransmission of the closing packet. Disposing of connection state prior to the end of the closing or <del> draining period could cause delayed or reordered packets to be handled poorly.  Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not create QUIC state, such as those that are able to close the UDP socket, MAY use an abbreviated draining period which can allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. </del> <ins> draining period could cause delayed or reordered packets to generate an unnecessary stateless reset.  Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not induce a response, such as those that are able to close the UDP socket, MAY use an abbreviated draining period which can allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. </ins> Once the closing or draining period has ended, an endpoint SHOULD discard all connection state.  This results in new packets on the
Change:
NAME I added IANA considerations, analogous to those in the HTTP doc for the stream type.
We have space for private transport parameters and a process for assigning new standard transport parameters. However, since we do not apply GREASE to transport parameters, we leave ourselves open to that flexibility ossifying. I'm happy to produce a PR to address this in the spec.
During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter. I think applying GREASE to transport parameters is a great idea.
Discussed in London, NAME to prepare a PR
NAME any progress here?
I have prepared something. I can open a pr
NAME sorry I totally dropped the ball here! I had text ages ago and was circling back today finally. Thanks NAME for seeing to it.
Thanks Marten!Thanks for writing this up!Need to fix the examples, but otherwise looks good.

Discussion:
An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  The maximum ack delay is communicated in the <del> max_ack_delay transport parameter; see Section 18.1 of QUIC- </del> <ins> max_ack_delay transport parameter; see Section 18.2 of QUIC- </ins> TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the

New transport parameters can be used to negotiate new protocol behavior.  An endpoint MUST ignore transport parameters that it does not support.  Absence of a transport parameter therefore disables any <del> optional protocol feature that is negotiated using the parameter. </del> <ins> optional protocol feature that is negotiated using the parameter.  As described in transport-parameter-grease, some identifiers are reserved in order to exercise this requirement. </ins> New transport parameters can be registered according to the rules in iana-transport-parameters.

18.1. <ins> Transport parameters with an identifier of the form "31 * N + 27" for integer values of N are reserved to exercise the requirement that unknown transport parameters be ignored.  These transport parameters have no semantics, and may carry arbitrary values. 18.2. </ins> This section details the transport parameters defined in this document.

The initial contents of this registry are shown in iana-tp-table. <ins> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by IANA. </ins> 22.2. IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a