jiebi/CodeConvo huggingface dataset:
Change:
This cribs Lucas' proposed tweak and makes a few other tiny adjustments.
The transport currently says It feels more correct to say I'll prepare a PR if my understanding and suggestion is correct.
It's a subtle point, but it seems OK. I do find the use of a possessive in that phrasing abhorrent though.
I made a stupid typo, whoops. Open to alternative phrasing. "Pulling the rug" comes to mind...
You're changing the meaning here, and I think the existing phrasing is correct. If you don't understand the application protocol, you don't know which streams are safe to reset and which will be connection-fatal. Telling the application protocol that you reset the stream doesn't make it any less fatal if you reset the wrong stream.
So looking at the paragraph in entirety I agree with NAME : directly or through the receipt of a STOPSENDING frame from a peer. RESETSTREAM carries an application error code. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. Is the intention to describe why " RESET_STREAM MUST be instigated by the protocol"? The words following the normative text are a bit wooly/weasely. I think this paragraph slightly falls victim to the problem that you raised on URL but from the other side of the coin. Nowhere else do we use the phrase "protocol using QUIC" - it sounds a bit bcp56(bis).
Yes -- QUIC doesn't unilaterally reset streams, because it doesn't have the context to do so safely. The application layer on one of the peers has to do that, even if it does so via a STOP_SENDING transmitted by QUIC.
Small commentslgtm

Discussion:
RESET_STREAM frame (frame-reset-stream) with an appropriate error code to terminate just the affected stream. <del> RESET_STREAM MUST be instigated by the protocol using QUIC. RESET_STREAM carries an application error code.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an </del> <ins> Resetting a stream without the involvement of the application protocol could cause the application protocol to enter an unrecoverable state.  RESET_STREAM MUST only be instigated by the application protocol that uses QUIC. RESET_STREAM carries an application error code, for which the semantics are defined by the application protocol.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an </ins> automatic RESET_STREAM. <del> Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. </del> Application protocols SHOULD define rules for handling streams that are prematurely cancelled by either endpoint.
Change:
It's still slightly odd where we have this setup between TLS and transport, but it seems like replicating the information might be enough.
Would it make sense to add PN space columns to the table of frames with section references, with an X where a frame is applicable? Transport section 12.4 URL
Looks good to me, and thank you for adding this column. Seeing frames like PATH_CHALLENGE/RESPONSE in 0RTT packets is strange, but clearly allowed by the spec. I don't see a reason to changing this, but it's why I think this column is useful.

Discussion:
the frame.  These frames are explained in more detail in frame- formats. <ins> The "Packets" column in frame-types does not form part of the IANA registry (see iana-frames).  This column summarizes the types of packets that each frame type can appear in, indicated as up to four characters indicating: Initial (packet-initial) Handshake (packet-handshake) 0-RTT (packet-0rtt) 1-RTT (short-header) A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, Handshake, and 1-RTT packets, whereas a CONNECTION_CLOSE of type 0x1d can only appear in a 1-RTT packet. Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets. </ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR.
Change:
The old text used the non-specific "abort" here, but we can point to the right error code.
What does "abort" mean? Perhaps change this to "drop QUIC connection state"? Originally posted by NAME in URL
LGTM modulo the preference below.

Discussion:
QUIC requires that the cryptographic handshake provide authenticated protocol negotiation.  TLS uses Application Layer Protocol <del> Negotiation (ALPN) RFC7301 to select an application protocol.  Unless </del> <ins> Negotiation (ALPN) ALPN to select an application protocol.  Unless </ins> another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- <del> errors).  While RFC7301 only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN </del> <ins> errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN </ins> negotiation fails. <del> An application-layer protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol 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 MUST abort a connection if the server picks an application protocol incompatible with the protocol version being used. </del> <ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a connection error of type 0x178 (no_application_protocol).  Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x178. </ins> 8.2.
Change:
This is really just an observation, because there is no real way we can insist on people doing this sort of thing, but being aware of the performance implication of spoofed migrations might motivate solutions.
I think the sections that describe connection migration attacks should mention that, when the endpoint detects a spurious migration, it should revert back to using the same CC state and ECN state as before. Otherwise, an attacker could degrade the performance of a connection.
Perhaps the tag should be recovery, not transport.
I can see it going either way. NAME what do you think?
I think the text is going to be in transport, so that's probably the right tag
As long as this doesn't lead to confusion (for example: we recently tightened up the MUST around resetting state) for folks when reading this, I think it's really valuable to actually state this in the draft rather than hint at it throughout -- looks good!

Discussion:
An endpoint MAY send data to an unvalidated peer address, but it MUST protect against potential attacks as described in address-spoofing and on-path-spoofing.  An endpoint MAY skip validation of a peer <del> address if that address has been seen recently. </del> <ins> address if that address has been seen recently.  In particular, if an endpoint returns to a previously-validated path after detecting some form of spurious migration, skipping address validation and restoring loss detection and congestion state can reduce the performance impact of the attack. </ins> An endpoint only changes the address that it sends packets to in response to the highest-numbered non-probing packet.  This ensures
Change:
If we get one, rely on the back-off that we require endpoints to implement when they enter the closing state. No need for any additional special processing rules (as mentioned in ).
Section 11.1 says: "An endpoint that receives an invalid CONNECTIONCLOSE frame MUST NOT signal the existence of the error to its peer." Editorially, it is not clear to me whether I am to suppress the error code in the CONNECTIONCLOSE frame or the error I generate when I receive an invalid frame. Moreover, I am not sure what constitutes an invalid CONNECTION_CLOSE frame. The words don't occur elsewhere. Section 19.19 doesn't define any fatal errors for this type. I can imagine a Reason Length that overruns the packet, or perhaps an undefined error code? A bogus frame type? We should probably define those in 19.19. Perhaps this sentence is an artifact from before we were throwing away Initial keys agressively?
If you suppress the error, does it matter which error you do not send?
I'm not sure what the intent of the sentence is. Do I send PROTOCOL_VIOLATION but not the error code in the frame? Do I send nothing?
As I read it, you should not send anything if you see CONNECTION_CLOSE. As to the motivation, I'm not quite sure, but if the peer closes but does it badly, chances are that anything you send just results in stateless resets. Maybe there can also be some malicious intend, especially in early handshake, but I don't think that is the reason.
I think this is addressing the injected packet case -- if you ignore an injected CONNECTION_CLOSE, you shouldn't send the real peer anything about it, or you've just allowed an attacker to inject authenticated traffic in the connection.
This is more about the looping case: sending CONNECTIONCLOSE in response to CONNECTIONCLOSE. But it is badly worded.
From the current text in 10.3 After sending a CONNECTIONCLOSE frame, endpoints immediately enter the closing state. During the closing period, an endpoint that sends a CONNECTIONCLOSE frame SHOULD respond to any packet that it receives with another packet containing a CONNECTION_CLOSE frame. To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet. This will be a loop since the same invalid packet will be sent again by the sender ....
I'm going to request that this be re-assessed. When looking into Roni's comment, I realize that we aren't really clear enough about this invalid case and some (small amount of) discussion might be necessary to confirm that this change is OK.

Discussion:
data for a terminated connection is to use the stateless reset process (stateless-reset). <del> An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the existence of the error to its peer. </del> 11.2. If an application-level error affects a single stream, but otherwise
Change:
And note that 8311 is an update.
(Broken out of .) >A receiver maintains a cumulative sum of It would have helped me, had this explained what was intended by “control violations” - I think it means to detect when the sender sends more than permitted by the flow control limit. I think the control part comes in a later sentence? (Is this measured against the largest advertised offset, or the current offset? … given what is written about reducing the advertised value?)
one suggestion, but I'm approving

Discussion:
6.1. <del> If a path has been verified to support ECN, QUIC treats a Congestion Experienced codepoint in the IP header as a signal of congestion. This document specifies an endpoint's response when its peer receives packets with the Congestion Experienced codepoint.  As discussed in RFC8311, endpoints are permitted to experiment with other response functions. </del> <ins> If a path has been verified to support ECN RFC3168 RFC8311, QUIC treats a Congestion Experienced(CE) codepoint in the IP header as a signal of congestion.  This document specifies an endpoint's response when its peer receives packets with the Congestion Experienced codepoint. </ins> 6.2.
Change:
xml2rfc v3 format prohibits the use of these, which will cause problems. This makes the anchors longer, so feel free to go with something else.
Had to merge it, but feel free to fix anchors.

Discussion:
2. Like HPACK, QPACK uses two tables for associating header fields to <del> indices.  The static table (see _table-static) is predefined and contains common header fields (some of them with an empty value). The dynamic table (see _table-dynamic) is built up over the course of the connection and can be used by the encoder to index header fields in the encoded header lists. </del> <ins> indices.  The static table (see header-table-static) is predefined and contains common header fields (some of them with an empty value). The dynamic table (see header-table-dynamic) is built up over the course of the connection and can be used by the encoder to index header fields in the encoded header lists. </ins> QPACK defines unidirectional streams for sending instructions from encoder to decoder and vice versa.

QPACK defines two settings which are included in the HTTP/3 SETTINGS frame. <del> The default value is zero.  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 header-table-dynamic for usage. This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </ins> The default value is zero.  See blocked-streams.
Change:
This won't necessarily prevent fragmentation from happening, but it's the best we can do. I didn't REQUIRE dropping of fragments, because some systems do that for you, but a SHOULD seems appropriate.
Gorry notes correctly that fragmentation can play poorly with using IW10. If a sender uses a large maxdatagramsize, and if the network fragments, then IW10 can result in substantially larger amplification than 10x. A simple fix here is to say that if the endpoint uses maxdatagramsize larger than 1280 bytes (this is what the transport spec limits it to in the absence of DPLPMTUD), then the endpoint MUST set DF on outgoing packets. This is a problem with RFC 6928 as well, but we should be clear about it for QUIC.
Shouldn't endpoint always set DF for all QUIC packets? TCP does so.
I tend to agree with Praveen here. I think this is something that's under-specified in transport? I believe it should be in section 14: URL
Yeah, this is probably an issue in transport. DF seems like the obvious answer.
That was my first answer, but I thought that might be too intrusive. If we all agree that is a fine response, I'm happy with that. I can write up a PR.
From memory, I think there was once a discussion on DF bit not being accessible in some language interfaces. As such, the formulation should perhaps be that the DF bit SHOULD be set whenever possible. Having a MUST whenever possible could be problematic because possible could involve a lot of complexity.
-- URL
NAME yes, that is exactly the text I am referring to. I'm questioning if that requirement is practically enforceable.

Discussion:
client believes that the Path Maximum Transmission Unit (PMTU) supports the size that it chooses. <ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. </ins> A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in response to an Initial packet it receives from a client if the UDP datagram is smaller than 1200 bytes.  It MUST NOT
Change:
This is already implied by the existing text, but it isn't said directly. That is, we say that the values can't be linkable, which is a stronger requirement. Saying that you can't send the same value on two connections is much clearer.
This text does not forbid the server from sending the same token on multiple connections. Consequently the client has a hard, or impossible, task of excluding duplicates. At least if you only read that section. Later the text says: >The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued. This suggests that the token MUST indeed be unique, but in a roundabout manner. It would be helpful to make the initial paragraph clearer by stating the that the duplicate token can only happen on the same connection and that the server MUST ensure different connections use different tokens.
A nit, but looks good, thanks for working patiently!

Discussion:
allow values to be linked by an on-path observer to the connection on which it was issued, unless the values are encrypted.  For example, it cannot include the previous connection ID or addressing <del> information.  Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server. </del> <ins> information.  A server MUST ensure that every NEW_TOKEN frame it sends is unique across all clients, with the exception of those sent to repair losses of previously sent NEW_TOKEN frames.  Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server. </ins> It is unlikely that the client port number is the same on two different connections; validating the port is therefore unlikely to

connection error of type FRAME_ENCODING_ERROR. An endpoint might receive multiple NEW_TOKEN frames that contain the <del> same token value.  Endpoints are responsible for discarding duplicate values, which might be used to link connection attempts; see validate-future. </del> <ins> same token value if packets containing the frame are incorrectly determined to be lost.  Endpoints are responsible for discarding duplicate values, which might be used to link connection attempts; see validate-future. </ins> Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt of a NEW_TOKEN frame as a connection error of type
Change:
This builds on to address the linkability issues that it added. It recommends 1/16 of network paths are disabled randomly as suggested by NAME It also allows the determination to be made per connection ID rather than per-path (which is more granular, but I expect it will have a nearly identical effect). The net effect is that 1/8 paths will not spin as originally intended.
The draft says: Given that each endpoint needs to decide for itself whether it is enabling spin bit, it is not exactly clear whether each endpoint SHOULD disable spin bit on at least 1/8 (=12.5%) of connections, or it can assume that the other endpoint is also making a random decision to disable and disable only on 1-sqrt(7/8) (=6.5%) of connections.
as the author of this passage, I intended the latter (assume the other side is disabling as well, so 1-sqrt(7/8)), but the "at least" is in there since just disabling 1/8 is probably what people will do, and the result (about 1/4) is "at least 1/8".
NAME could you review ?
One suggestionLooks good technically. It may be slightly confusing, though, that the last sentence only talks about paths, while a sentence before talks about "paths or connection IDs". In any case, the behavior ensures a sufficient amount of traffic without the spin bit to prevent ossification of the bit.

Discussion:
disabled for a connection.  Implementations MUST allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis.  Even when the spin bit is not disabled by <del> 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 disabled for at least one eighth of network paths.  The selection process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. </del> <ins> the administrator, endpoints MUST disable their use of the spin bit for a random selection of at least one in every 16 network paths, or for one in every 16 connection IDs.  As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths. </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:
states: This is an unnecessary constraint and there’s value in not having it. A server can, for example, include multiple IP addresses for a client in a token, enabling client validation from multiple attachment points.
Agreed. Just to give one example, it'd make sense for a server to issue a NEWTOKEN token containing two addresses, if the client is using one path to communicate while having another path being probed and validated. Note also that it is difficult to implement the MUST NOT that exists now. Consider the case where a client receives a NEWTOKEN frame during or after path migration. Is the client expected to bind the token to the old IP address? Or the new address? It is hard to tell the intention of the server.
I agree this seems unnecessary, given tokens cannot be used multiple times. The worst case scenario is including the token increases the number of Initial packets the client needs to send to two packets from one and the token turns out not to be useful for address validation.
As is clear from the PR, this should be marked design.

Discussion:
A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts.  Reusing a token allows connections to be linked by <del> entities on the network path; see migration-linkability.  A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the connection process over if there is any change in its local address prior to completing the handshake. </del> <ins> entities on the network path; see migration-linkability. </ins> Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection