connection ID. If the spin bit is enabled for the connection, the endpoint maintains <del> a spin value and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent out. The spin value is initialized to 0 in the endpoint at connection start.  Each endpoint also remembers the highest packet number seen from its peer on the connection. When a server receives a short header packet that increments the highest packet number seen by the server from the client, it sets the spin value to be equal to the spin bit in the received packet. When a client receives a short header packet that increments the highest packet number seen by the client from the server, it sets the spin value to the inverse of the spin bit in the received packet. An endpoint resets its spin value to zero when sending the first packet of a given connection with a new connection ID.  This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change. </del>  With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can

This binds the spin-bit state to a network path, which aligns with intent better than the existing language. It's more words, but it is far less ambiguous.
NAME sanity check please? I'll merge this soon either way.
This is likely a case of "we know what we meant," but.... Section 17.3.1 says that the spin bit can be enabled/disabled on a per-connection or per-CID basis, and that: However, a literal reading of this suggests that a client which sets the spin bit on a per-connection basis will revert the spin bit on the main path to zero whenever it uses a new CID to probe on an alternate path. It also has implications for an implementation that uses many active CIDs at once. One resolution is that the current state of the spin bit is maintained on a per-CID basis, and that the CID begins at zero for each CID. However, for the client using many CIDs at once, that then begs the question of which of the peer's CIDs are being reflected back to it. I think that what we actually mean here is two-fold: The current state of the spin bit is maintained on a per-path basis, and is initialized to zero for each path. The current state of the spin bit is reset to zero whenever the CID being used on a path changes, no matter how frequently that is.
I think what you summarize in the bullets is indeed what was intended. NAME

connection ID. If the spin bit is enabled for the connection, the endpoint maintains  <ins> a spin value for each network path and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the highest packet number seen from its peer on each path. When a server receives a short header packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet. When a client receives a short header packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet. An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. </ins> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can


path via the attacker.  This places the attacker on path, giving it the ability to observe or drop all subsequent packets. <del> Unlike the attack described in on-path-spoofing, the attacker can ensure that the new path is successfully validated. </del> This style of attack relies on the attacker using a path that is approximately as fast as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if

This text could be read to imply that an off-path attacker is more capable than an on-path attacker, which is rarely true. What it was meant to point out was that it is easier to move traffic onto a path that you are on. What it fails to acknowledge is that it is also easier to move traffic off a path that you are on. In other words, the treatment of this in 21.12 is more thorough and we don't need to talk about limitations. Mike suggested that there is some duplication between this attack and the more comprehensive analysis in 21.12. That is true, but these serve different purposes. This is to describe attacks and the normative requirements on endpoints necessary to avoid them. The other section is a thorough and hollistic analysis. I couldn't see any truly straightforward changes. That doesn't mean that we won't find a way to clean this up, or that it would be undesirable to have fewer words, but I've not the time for that right now.
I find the text in 9.3.3 confusing, because it says: Unlike the attack described in {{on-path-spoofing}}, the attacker can ensure that the new path is successfully validated. This is odd because on-path attackers are generally regarded as stronger than on-path attackers. Why can't an on-path attacker complete this attack.
I think you're right that the text is confusing, if not quite incorrect. An on-path attacker can rewrite a source address, causing an apparent migration, but can't cause path validation to succeed with that source address unless it is actually on-path from both endpoints to the spoofed addresses as well. An off-path attacker which can race packets successfully can cause migration with successful path validation to a path which includes it, becoming a limited on-path attacker. This also feels slightly duplicative of 21.12.3; it might be worth condensing some text between these sections.

path via the attacker.  This places the attacker on path, giving it the ability to observe or drop all subsequent packets.  This style of attack relies on the attacker using a path that is approximately as fast as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if


assumed to be implicitly reset. After sending a CONNECTION_CLOSE frame, an endpoint immediately <del> enters the closing state. </del>  <del> During the closing period, an endpoint that sends a CONNECTION_CLOSE frame SHOULD respond to any incoming packet that can be decrypted with another packet containing a CONNECTION_CLOSE frame.  Such an endpoint SHOULD limit the number of packets it generates containing a CONNECTION_CLOSE frame.  For instance, an endpoint could wait for a </del>  progressively increasing number of received packets or amount of time <del> before responding to a received packet. An endpoint is allowed to drop the packet protection keys when entering the closing period (draining) and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet. </del>  Allowing retransmission of a closing packet is an exception to the requirement that a new packet number be used for each packet in

I took a careful look at the text here and found a few things: There wasn't much redundancy, but there was a little. Mostly the problem was scattering of content between two locations in the document. The closing and draining states only apply to immediate close. So I moved things up. I trimmed the top-level immediate close text, and moved text specific to closing or draining to sections corresponding to each. There were a few bits that could be cut, and a few that needed to be better aligned with existing text, but nothing major. Most of this is unmodified text. There are a few bits that I had to tweak. I will add comments for those.
NAME you can add this to your review load.
The section on Immediate Close contains some text that is redundant with the section on the Closing and Draining periods. Factor some of this out.
I think this flows a lot better. Thanks for the time you put into this!Thanks, Martin!

assumed to be implicitly reset. After sending a CONNECTION_CLOSE frame, an endpoint immediately  <ins> enters the closing state; see closing.  After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state; see draining. </ins>  <ins> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocol negotiates a graceful shutdown.  The application protocol can exchange messages that are needed for both application endpoints to agree that the connection can be closed, after which the application requests that QUIC close the connection.  When QUIC consequently closes the connection, a CONNECTION_CLOSE frame with an application-supplied error code will be used to signal closure to the peer. The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded.  These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in QUIC- RECOVERY. Disposing of connection state prior to exiting the closing or draining state could cause could result in an endpoint generating a stateless reset unnecessarily when it receives a late-arriving packet.  Endpoints that have some alternative means to ensure that late-arriving packets do not induce a response, such as those that are able to close the UDP socket, MAY end these states earlier to allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT end the closing or draining states early. Once its closing or draining state ends, an endpoint SHOULD discard all connection state.  The endpoint MAY send a stateless reset in response to any further incoming packets belonging to this connection. 10.2.1. An endpoint enters the closing state after initiating an immediate close. In the closing state, an endpoint retains only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection.  An endpoint in the closing state sends a packet containing a CONNECTION_CLOSE frame in response to any incoming packet that it attributes to the connection. An endpoint SHOULD limit the rate at which it generates packets in the closing state.  For instance, an endpoint could wait for a </ins> progressively increasing number of received packets or amount of time  <ins> before responding to received packets. An endpoint's selected connection ID and the QUIC version are sufficient information to identify packets for a closing connection; the endpoint MAY discard all other connection state.  An endpoint that is closing is not required to process any received frame.  An endpoint MAY retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame. An endpoint MAY drop packet protection keys when entering the closing state and send a packet containing a CONNECTION_CLOSE frame in response to any UDP datagram that is received.  However, an endpoint that discards packet protection keys cannot identify and discard invalid packets.  To avoid being used for an amplication attack, such endpoints MUST limit the cumulative size of packets it sends to three times the cumulative size of the packets that are received and attributed to the connection.  To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet in response to any received packet. </ins> Allowing retransmission of a closing packet is an exception to the requirement that a new packet number be used for each packet in


expected to be relevant for a closed connection.  Retransmitting the final packet requires less state. <del> New packets from unverified addresses could be used to create an amplification attack; see address-validation.  To avoid this, endpoints MUST either limit transmission of CONNECTION_CLOSE frames to validated addresses or drop packets without response if the response would be more than three times larger than the received packet. After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state.  An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended. </del>  <del> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocols negotiates a graceful shutdown.  The application protocol exchanges whatever messages that are needed to cause both endpoints to agree to close the connection, after which the application requests that the connection be closed.  When the application closes the connection, a CONNECTION_CLOSE frame with an appropriate error code will be used to signal closure. 10.2.1. </del>  When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a

expected to be relevant for a closed connection.  Retransmitting the final packet requires less state.  <ins> While in the closing state, an endpoint could receive packets from a new source address, possibly indicating a connection migration; see migration.  An endpoint in the closing state MUST either discard packets received from an unvalidated address or limit the cumulative size of packets it sends to an unvalidated address to three times the size of packets it receives from that address. </ins>  <ins> An endpoint is not expected to handle key updates when it is closing (Section 6 of QUIC-TLS).  A key update might prevent the endpoint from moving from the closing state to the draining state, as the endpoint will not be able to process subsequently received packets, but it otherwise has no impact. 10.2.2. The draining state is entered once an endpoint receives a CONNECTION_CLOSE frame, which indicates that its peer is closing or draining.  While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets.  Retaining packet protection keys is unnecessary once a connection is in the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets.  Doing so could result in a constant exchange of CONNECTION_CLOSE frames until one of the endpoints exits the closing state. An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is 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. 10.2.3. </ins> When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a


of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers. <del> 10.4. The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded.  These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in QUIC- RECOVERY. An endpoint enters a closing period after initiating an immediate close; immediate-close.  While closing, an endpoint MUST NOT send packets unless they contain a CONNECTION_CLOSE frame; see immediate- close for details.  An endpoint retains only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection.  The endpoint's selected connection ID and the QUIC version are sufficient information to identify packets for a closing connection; an endpoint can discard all other connection state.  An endpoint MAY retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame. The draining state is entered once an endpoint receives a signal that its peer is closing or draining.  While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets.  Retaining packet protection keys is unnecessary once a connection is in the draining state. An endpoint MAY transition from the closing period to the draining period if it receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate that the peer is also closing or draining. The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. Disposing of connection state prior to the end of the closing or 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 to allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. Once the closing or draining period has ended, an endpoint SHOULD discard all connection state.  This results in new packets on the connection being handled generically.  For instance, an endpoint MAY send a stateless reset in response to any further incoming packets. The draining and closing periods do not apply when a stateless reset (stateless-reset) is sent. An endpoint is not expected to handle key updates when it is closing or draining.  A key update might prevent the endpoint from moving from the closing state to draining, but it otherwise has no impact. While in the closing period, an endpoint could receive packets from a new source address, indicating a connection migration; migration.  An endpoint in the closing state MUST strictly limit the number of packets it sends to this new address until the address is validated; see migrate-validate.  A server in the closing state MAY instead choose to discard packets received from a new source address. </del> 11. An endpoint that detects an error SHOULD signal the existence of that

of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers.  11. An endpoint that detects an error SHOULD signal the existence of that


semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version <del> are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. </del>  Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-

instead of saying servers SHOULD NOT attempt to parse unknown versions, stick with the factual statement that they will likely be unable to do so. Flips the SHOULD to the second half of the sentence, the expected response. I believe this is editorial, since we're not modifying expected behavior, but it's touching normative language, so please speak up if you're not convinced.
Actually, it seems like there should be a normative MUST NOT attempt.
I would have said "cannot". The contents are unknown, after all. Attempting to prohibit someone from doing something impossible seems like it might be unnecessary (or at least futile). Edit: of course, this change avoids having to deal with that question, which is better.
Why do you say it's impossible? You could simply hope that version n+1 was the same as version n in terms of structure and try to parse it as that, ignoring the version number.
Which is why the PR says "unlikely," not "impossible." But the impossible thing is for the server to know whether it's doing things correctly.
Right, but my point is that we should prohibit trying, not just give people advice that it's dumb.
(Broken out of .) This seems like tuning? Or is the intention to protect the endpoint from an attack, please explain the SHOULD.
encodings for any version-specific field. In particular, different packet protection keys might be used for different versions. Servers that do not support a particular version are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. I'm having trouble seeing what's needed here. The endpoint has received a packet professing to be in a version it does not understand. It can't know the semantics or encoding of any field there -- and the paragraph already explains that. Yes, I'm sure there are potential attacks in interpreting a packet of unknown provenance and unknown semantics against a different set of semantics and expectations, but I'm not convinced we need to explain them. The text recommends sending a Version Negotiation packet, which seems like the only sensible response.
This refers to .
NAME
I'm looking for two things: (i) I think this ought to clarify the intention for the SHOULD, I suspect it is clear to those working on this part, but not clear to me why this is a recommendation - i.e., specifically can you give me a use-case of why the Server would otherwise USE information from a packet from an unknown version, unless the intention is to say the server shouldn't waste resources to do try to do this? (ii) I think this implies understanding of Section 14.1 later in the spec, and a ref would help. So... Is it equally true that.. "Servers MUST NOT use the contents of a packet with an unknown version, and SHOULD NOT decrypt this packet, but instead send a Version Negotiation packet, provided that the packet is sufficiently long (see Section 14.1)."? Or perhaps simply explain something like: "Servers SHOULD NOT commit resources to attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long (see Section 14.1)."?
Fundamentally, it's a caution against assumptions which could prove incorrect, such as "this looks like an unencrypted TLS ClientHello, so I can go find the field that contains...." The server will either process information in a way that could be used maliciously, or the server will generate a response that won't be understood by the client. Ideally, this would be a MUST, except that it's entirely unenforceable by the client what the server does internally. Perhaps the right solution here is to remove the normative language with regard to that piece and stick to the statement of fact we already have:
That approach seems fine.

semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version  <ins> are unlikely to be able to decrypt the payload of the packet or properly interpret the result.  Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long. </ins> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-


between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port. <del> Path validation tests that packets can be both sent to (PATH_CHALLENGE) and received from (PATH_RESPONSE) a peer on the path.  Importantly, it validates that the packets received from the migrating endpoint do not carry a spoofed source address. </del>  Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession

The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .

between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port.  <ins> Path validation tests that packets sent on a path to a peer are received by that peer.  Path validation is used to ensure that packets received from a migrating peer do not carry a spoofed source address. Path validation does not validate that a peer can send in the return direction.  The peer performs independent validation of the return path. </ins> Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession


8.3. To initiate path validation, an endpoint sends a PATH_CHALLENGE frame <del> containing a random payload on the path to be validated. </del>  An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet loss.  However, an endpoint SHOULD NOT send multiple

8.3. To initiate path validation, an endpoint sends a PATH_CHALLENGE frame  <ins> containing an unpredictable payload on the path to be validated. </ins> An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet loss.  However, an endpoint SHOULD NOT send multiple


On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a <del> PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </del>  An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-

On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a  <ins> PATH_RESPONSE frame.  A PATH_RESPONSE frame does not need to be sent on the network path where the PATH_CHALLENGE was received; a PATH_RESPONSE can be sent on any network path.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </ins> An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-


8.5. <del> A new address is considered valid when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame.  Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </del>  8.6.

8.5.  <ins> Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame. This validates the path on which the PATH_CHALLENGE was sent. Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </ins> 8.6.


initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is:  Note that the endpoint might receive packets containing other frames on the new path, but a PATH_RESPONSE frame with appropriate data is required for path validation to succeed.

I believe these two cases are both 3*PTO to allow the PTO to expire at least once before declaring path validation failure and idle timeout.
Thanks for your suggestions, I'm quite happy with this now.
NAME says in : This is reasonable. I don't know which document needs the text though.
This looks like it should go into -recovery, since -transport mostly only refers to as a TP, except in Section 13.2.1 ("sending-acknowledgements"), but that text is very general.
I would suggest that this should go where a value of X PTOs is suggested for each specific timer.
Relabeling, since ended up being against -transport and not -recovery.

initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is: <ins> This timeout allows for multiple PTOs to expire prior to failing path validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE frame does not cause path validation failure. </ins> Note that the endpoint might receive packets containing other frames on the new path, but a PATH_RESPONSE frame with appropriate data is required for path validation to succeed.


To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the <del> current Probe Timeout (PTO). </del>  10.1.1.

To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the  <ins> current Probe Timeout (PTO).  This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle timeout does not expire as a result of a single packet loss. </ins> 10.1.1.


sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). <del> Versions (versions) and error codes (error-codes) are described using integers, but do not use this encoding. </del>  17.

Error codes do use varints, but packet numbers (in the header) don't.

sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25).  <ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding. </ins> 17.


If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this <del> encryption level, saved data can be provided to TLS.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del>  Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake

This check really is triggered by TLS providing new keys, not QUIC delivering data on a higher encryption level. Otherwise, in the case where no session ticket is sent, this condition would go undetected for unconsumed data at the Handshake encryption level.

If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this  <ins> encryption level, saved data can be provided to TLS.  When TLS provides keys for a higher encryption level, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake


expiration, as TCP does with Tail Loss Probes (RACK) and a Retransmission Timeout (RFC5681).  The RECOMMENDED value for kPersistentCongestionThreshold is 3, which <del> is approximately equivalent to two TLPs before an RTO in TCP. </del>  This design does not use consecutive PTO events to establish persistent congestion, since application patterns impact PTO

Section 7.6.1: The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is approximately equivalent to two TLPs before an RTO in TCP. Any values that needs to be explicitly forbidden? For example does it need a sentence saying that it MUST be larger than X? I would think that 1 would be to low and allow slow start after just one RTT+variations? I understand that likely would give the application bad behavior but likely also have negative impact on other applications if the QUIC stack ends up doing slow start crashing into the wall and then slow starting again?
I lean towards not being overly proscriptive here. We could elaborate on the pros and cons of smaller and larger values if you think that is necessary? Exponential backoff is clearly critical, but it's less clear to me that the CWND really needs to be collapsed in these situations.
I am really just trying to asses if there are significant risks with any specific ranges of values. For example causing very bursty behavior that could be considered harmful or becoming extremely aggressive after a persistent congestion event, in those cases some text may be necessary.
Based on , labeling this as "editorial"
Thinks this resolve my issue, but would prefer Ian's proposal.

expiration, as TCP does with Tail Loss Probes (RACK) and a Retransmission Timeout (RFC5681). <ins> Larger values of kPersistentCongestionThreshold cause the sender to become less responsive to persistent congestion in the network, which can result in aggressive sending into a congested network.  Too small a value can result in a sender declaring persistent congestion unnecessarily, resulting in reduced throughput for the sender. </ins> The RECOMMENDED value for kPersistentCongestionThreshold is 3, which  <ins> results in behavior that is approximately equivalent to a TCP sender declaring an RTO after two TLPs. </ins> This design does not use consecutive PTO events to establish persistent congestion, since application patterns impact PTO


The total length of time over which consecutive PTOs expire is limited by the idle timeout. <del> The probe timer MUST NOT be set if the time threshold (time- threshold) loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data. </del>  6.2.2.

That term doesn't appear above, so don't use it in the PTO section.
Thanks NAME I took your suggestions with one tweak.
Section 6.2.1: "The probe timer MUST NOT be set if the time threshold (Section 6.1.2) loss detection timer is set. The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data." What does "MUST NOT be set" means. The time threshold loss detection 6.1.2 only occurs if there is acknowledgement received by the sender sufficient late after the transmission. Thus, PTO timer needs to always be set. because even if Time Threshold timer fires it might not declare a loss.
It means if the time threshold timer is armed, you are not supposed to arm the PTO timer. If the Time Threshold timer fires and doesn't declare a loss, then I would consider that a bug.
So the above text about loss timer is only when one are under the condition created by this Section 6.1.2 sentence? "If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time." Does the formulation in 6.1.2 need to be improved, possibly naming the timer?
I can see the confusion. This can either be a single timer or multiple, and sometimes we refer to it one way and sometimes as separately named timers, ie "The time threshold loss detection timer" We can either be more consistent about naming the timers or stop naming the timers entirely. Would you prefer the former?
Frankly I don't know which direction that is best. Could I ask you to take an editorial stab on your most preferred. I would guess when you sit down to do either you realize if it will work or not when you harmonize it.
NAME Does PR resolve this for you?
NAME we'd need a response, please
Yes, that simple tweak do make it clearer. So resolved.
The second suggestion is a little risky, but avoids a slightly awkward construction.Editorial suggestion. I'm fine with merging this, but NAME should probably see if it addresses his issue.

The total length of time over which consecutive PTOs expire is limited by the idle timeout.  <ins> The PTO timer MUST NOT be set if a timer is set for time threshold loss detection; see time-threshold.  A timer that is set for time threshold loss detection will expire earlier than the PTO timer in most cases and is less likely to spuriously retransmit data. </ins> 6.2.2.


certain that it has not processed another packet with the same packet number from the same packet number space.  Duplicate suppression MUST happen after removing packet protection for the reasons described in <del> Section 9.3 of QUIC-TLS. </del>  Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state.

There are three places which refer to "Section 9.3 of QUIC-TLS". I think they should refer to "Section 9.5 of QUIC-TLS".
Thanks!

certain that it has not processed another packet with the same packet number from the same packet number space.  Duplicate suppression MUST happen after removing packet protection for the reasons described in  <ins> Section 9.5 of QUIC-TLS. </ins> Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state.


both packet and header protection as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del>  In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain

both packet and header protection as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see  <ins> Section 9.5 of QUIC-TLS. </ins> In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain


and header protection, as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del>  The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection

and header protection, as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see  <ins> Section 9.5 of QUIC-TLS. </ins> The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection


has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it.  However, an HTTP message can traverse one or more <del> intermediaries (see Section 3.7 of SEMANTICS) before reaching the origin server.  Because this limit is applied separately by each </del>  implementation which processes the message, messages below this limit are not guaranteed to be accepted.

Fixes several nits from the gen-art review, which basically all come down to defining terms appropriately and/or referencing their definitions. modifies definition of "stream" and "stream error"; pulls in more terms from SEMANTICS references SEMANTICS for definition of fields rewords to avoid the term "hop" and describes intermediation more explicitly rewords to avoid saying "not possible" and copies language from SEMANTICS advising against retries updates reference to definition of CONNECT in SEMANTICS. NAME your review would be appreciated.
In the HTTP genart review, NAME writes:
Yes, CONNECT only supports TCP, and there's no short-term plan to change that. There is separate relevant work such as but I don't think we need to change anything in the draft here - it pretty clearly mentions TCP so I don't see any ambiguity.
This question should be addressed by the definition of CONNECT the spec is referring to. It's worth double-checking the references in that section, though; it points to HTTP11, when I think there should be a definition in SEMANTICS.
In the HTTP genart review, NAME writes:
Presumably a reference into SEMANTICS; I'll look for the right section to point to.
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes: "HTTP/3 stream". Perhaps it's worth defining "HTTP/3 stream" explicitly, in analogy to "HTTP/3 connection". Perhaps it's worth defining "message", too (this is only an HTTP concept, correct?). The document should make sure it clearly distinguishes terms and concept of QUIC vs. of HTTP/3 in all cases. In particular, what is the relationship between HTTP/3 frames and QUIC frames? It's important to make their difference and relationship explicit, as the document uses several other terms interchangeably between HTTP/3 and QUIC, like "connection" and perhaps "stream".
A few minor suggestions, but this is a good change.This looks good to me, thanks!

has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it.  However, an HTTP message can traverse one or more  <ins> intermediaries before reaching the origin server; see Section 3.7 of SEMANTICS.  Because this limit is applied separately by each </ins> implementation which processes the message, messages below this limit are not guaranteed to be accepted.


If a stream is canceled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the <del> response SHOULD NOT be used.  Only idempotent actions (such as GET, PUT, or DELETE) can be safely retried; a client SHOULD NOT </del>  automatically retry a request with a non-idempotent method unless it <del> has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.  See Section 8.2.2 of SEMANTICS for more details. </del>  4.1.3.

If a stream is canceled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the  <ins> response SHOULD NOT be used.  Only idempotent actions such as GET, PUT, or DELETE can be safely retried; a client SHOULD NOT </ins> automatically retry a request with a non-idempotent method unless it  <ins> has some means to know that the request semantics are idempotent independent of the method or some means to detect that the original request was never applied.  See Section 8.2.2 of SEMANTICS for more details. </ins> 4.1.3.


negotiating-connection-ids describes the use of this field in more detail.  In this version of QUIC, the following packet types with the long header are defined:

Minor nit while looking at ; the definition of generic "Long-Header Packets" won't actually match any real packet types, because it ends after the CIDs. This modifies the definition to add a final "Type-Specific Payload" section to the figure.
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.

negotiating-connection-ids describes the use of this field in more detail. <ins> The remainder of the packet, if any, is type-specific. </ins> In this version of QUIC, the following packet types with the long header are defined:


distrustful entities control requests or responses that are placed onto a single HTTP/3 connection.  If the shared QPACK compressor permits one entity to add entries to the dynamic table, and the other <del> to access those entries, then the state of the table can be learned. </del>  Having requests or responses from mutually distrustful entities occurs when an intermediary either:

I think this helps?
Magnus Nystrom : scenario of "mutual distrustful parties" is unclear to me. One stated scenario is where multiple client connections aggregate at an intermediary that then maintains a single connection to an origin server. Another stated scenario is where multiple origin servers connect to an intermediary which then serves a client. In these scenarios, is the concern that the intermediary may control either a client or an origin server and thus would be able to leverage the compression context at, say, a second client and then observe (as the intermediary) the result of a guess for a field tuple? It may be helpful to explain this in a little more detail. as to what strategy (option) implementations should choose to protect against this attack. It seems like the Never-Indexed-Literal is a good candidate which should be easy to implement.
This text was mostly lifted from RFC 7541. intermediary may control either a client or an origin server and thus would be able to leverage the compression context at, say, a second client and then observe (as the intermediary) the result of a guess for a field tuple? Yes, this is the concern. It's interesting that 'intermediary' here also refers to a browser that coalesces requests from different tabs onto the same connection. I agree. as to what strategy (option) implementations should choose to protect against this attack. I think the document recommends the tagging option unambiguously: "An ideal solution segregates access to the dynamic table based on the entity that is constructing the message" While never-index literals is the less complicated fallback option.
NAME so are you proposing any changes to the text?

distrustful entities control requests or responses that are placed onto a single HTTP/3 connection.  If the shared QPACK compressor permits one entity to add entries to the dynamic table, and the other  <ins> to access those entries to encode chosen field lines, then the attacker can learn the state of the table by observing the length of the encoded output. </ins> Having requests or responses from mutually distrustful entities occurs when an intermediary either:


1. <del> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and loss recovery mechanisms, described in RFCs, various Internet-drafts, or academic papers, and also those prevalent in TCP implementations. </del>  2.

In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.

1.  <ins> QUIC is a secure general-purpose transport protocol, described in QUIC-TRANSPORT).  This document describes loss detection and congestion control mechanisms for QUIC. </ins> 2.


4.2. TCP conflates transmission order at the sender with delivery order at <del> the receiver, which results in retransmissions of the same data carrying the same sequence number, and consequently leads to "retransmission ambiguity".  QUIC separates the two.  QUIC uses a packet number to indicate transmission order.  Application data is sent in one or more streams and delivery order is determined by stream offsets encoded within STREAM frames. </del>  QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet

4.2. TCP conflates transmission order at the sender with delivery order at  <ins> the receiver, resulting in the retransmission ambiguity problem (RETRANSMISSION).  QUIC separates transmission order from delivery order: packet numbers indicate transmission order, and delivery order is determined by the stream offsets in STREAM frames. </ins> QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet


The initial contents of this registry are shown in iana-tp-table. <del> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be assigned by IANA. </del>  22.3.

IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >

The initial contents of this registry are shown in iana-tp-table.  <ins> Each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 22.3.


The entries in iana-frame-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA. </del>  11.2.2.

The entries in iana-frame-table are registered by this document.  <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.2.


The entries in iana-setting-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del>  11.2.3.

The entries in iana-setting-table are registered by this document.  <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.3.


Specification Required policy to avoid collisions with HTTP/2 error codes. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del>  11.2.4.

Specification Required policy to avoid collisions with HTTP/2 error codes.  <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.4.


The entries in the following table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del>

The entries in the following table are registered by this document.  <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins>


QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a contiguous block of handshake data identified by an offset and length.  Those frames are packaged into QUIC packets and <del> encrypted under the current TLS encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </del>  responsibility to deliver it reliably.  Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the same keys even if TLS has already updated to newer keys. <del> One important difference between TLS records (used with TCP) and QUIC CRYPTO frames is that in QUIC multiple frames may appear in the same QUIC packet as long as they are associated with the same packet number space.  For instance, an endpoint can bundle a Handshake message and an ACK for some Handshake data into the same packet. </del>  Some frames are prohibited in different packet number spaces; see Section 12.5 of QUIC-TRANSPORT.

The first strikes "TLS" from encryption level The second removes misleading text about coalescing I'm suggesting that we replace it with explanatory language about encryption levels and packet number spaces. This context is now missing as a result of moving the referenced text to -transport.
Roman Danyliw said:
I'm going to suggest that the text I propose in addresses this first part of this. The higher/lower stuff seems like it could be better, but it's a lot of work to do carefully. I'm going to suggest that we could live with this, but I might leave this issue open and try to find a fix once other more pressing issues are dealt with.
NAME said:
This is really two comments, but I think we can dispense with both at the same time as the first is really trivial: The use of "TLS encryption level" is an unnecessary redundancy and inconsistent with other usage, so we can easily remove "TLS" there. The start of that paragraph is cruft. I'm going to suggest we only keep the last sentence, which was unquoted in this issue. But then I see that we are missing important context, so I'm going to suggest a little bit of text to replace it.
one suggestion, but lgtm

QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a contiguous block of handshake data identified by an offset and length.  Those frames are packaged into QUIC packets and  <ins> encrypted under the current encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </ins> responsibility to deliver it reliably.  Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the same keys even if TLS has already updated to newer keys.  <ins> Each encryption level corresponds to a packet number space.  The packet number space that is used determines the semantics of frames. </ins> Some frames are prohibited in different packet number spaces; see Section 12.5 of QUIC-TRANSPORT.


exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what <del> incoming messages trigger different actions.  New handshake messages are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </del>  4.2.

Ben observed that this might be at odds with the definition of the interface. This is true, but the illustrative value of the current structure is valuable. More text on that might help.
NAME said:
I think that the multiple invocations is enough to call out. However, the retrieval of bytes to send after processing some data is not necessary. For reference, the is: This does not necessarily imply that you pull after every byte provided. As the bytes here are provided in a coalesced packet, it is reasonable to defer the "Get Handshake" call until all of the bytes arrive. I know that our stack does, though this is not uniformly true. to Handshake Complete? YES! Thanks. That's going to be awkward, as it involves QUIC-layer messages, but I think we can do that. (In a separate PR though.)

exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what  <ins> incoming messages trigger different actions.  This shows multiple "Get Handshake" invocations to retrieve handshake messages at different encryption levels.  New handshake messages are requested after incoming packets have been processed. exchange-summary shows one possible structure for a simple handshake exchange.  The exact process varies based on the structure of endpoint implementations and the order in which packets arrive. Implementations could use a different number of operations or execute them in other orders. </ins> 4.2.


ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is sufficiently large.  QUIC PADDING frames are added to increase the size of the packet as necessary. </del>  4.4.

NAME I'll leave that in your hands.
NAME said:
Seems reasonable. I took the opportunity to reword a little.
Perhaps this PR should also fix the text in 8.1 to simply state and point to 14.1 in -transport. That text is redundant.

ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello  <ins> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </ins> 4.4.


that supports this extension if the extension is received when the transport is not QUIC.  8.3. The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not

As agreed via mail.
NAME said:
Response provided via email.
This is probably something we need a consensus call on, even though it's a change only in theory.
Returning to an open state as the chairs directed in their plan.
Closing this now that the IESG have approved the document(s).
This gets the job done, with or without the suggested rewording.

that supports this extension if the extension is received when the transport is not QUIC. <ins> Negotiating the quic_transport_parameters extension causes the EndOfEarlyData to be removed; see remove-eoed. </ins> 8.3. The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not


4. <del> Packet diagrams in this document use a format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </del>  Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is

This makes it clearer that the notation is copied from v1, not defined there and normatively referenced. (Note, figures aren't normative anyway.)
Éric Vyncke said:
In my response to , I explain this. This ensures that the transport reference can remain informative.
Perhaps the intro needs to be reworded to indicate that it's using some of the same conventions as the transport document, which are reproduced below?
Éric Vyncke said:
Barry's point (captured in ) was that one or other might need to be normative. This is a different point, suggesting that this document concretely depends on the transport draft for terminology that has normative effect. Haven't checked, I don't think that is the case and the reference can remain informative. The reason for that being that all of the terminology used in this draft is also defined in this draft.
Any other bids?

4.  <ins> The format of packets is described using the notation defined in this section.  This notation is the same as that used in QUIC-TRANSPORT. </ins> Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is


defined in Section 6 of TLS13. A TLS alert is converted into a QUIC connection error.  The <del> AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </del>  QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal

One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

defined in Section 6 of TLS13. A TLS alert is converted into a QUIC connection error.  The  <ins> AlertDescription value is added to 0x0100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal


QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as <del> handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </del>  4.9.

QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as  <ins> handshake_failure (0x0128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.9.


on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type <del> 0x10a, equivalent to a fatal TLS alert of unexpected_message; see </del>  tls-errors. ex-key-update shows a key update process, where the initial set of

on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type  <ins> 0x010a, equivalent to a fatal TLS alert of unexpected_message; see </ins> tls-errors. ex-key-update shows a key update process, where the initial set of


When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS <del> alert (QUIC error code 0x178; see tls-errors) if an application </del>  protocol is not negotiated.  While ALPN only specifies that servers <del> use this alert, QUIC clients MUST use error 0x178 to terminate a </del>  connection when ALPN negotiation fails. 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 <del> 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. </del>  8.2.

When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS  <ins> alert (QUIC error code 0x0178; see tls-errors) if an application </ins> protocol is not negotiated.  While ALPN only specifies that servers  <ins> use this alert, QUIC clients MUST use error 0x0178 to terminate a </ins> connection when ALPN negotiation fails. 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  <ins> connection error of type 0x0178 (no_application_protocol). Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x0178. </ins> 8.2.


MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an <del> error of type 0x16d (equivalent to a fatal TLS missing_extension </del>  alert, see tls-errors). Transport parameters become available prior to the completion of the

MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an  <ins> error of type 0x016d (equivalent to a fatal TLS missing_extension </ins> alert, see tls-errors). Transport parameters become available prior to the completion of the


Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges. <del> The three ECN Counts; see ack-ecn-counts. </del>  19.3.1.

This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!

Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges.  <ins> The three ECN counts; see ack-ecn-counts. </ins> 19.3.1.


The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE <del> in the packet's IP header.  ECN Counts are only present when the ACK </del>  frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format. <del> The three ECN Counts are: </del>  A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of

The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE  <ins> in the packet's IP header.  ECN counts are only present when the ACK </ins> frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format.  <ins> The ECN count fields are: </ins> A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of


"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <del> <https://www.iana.org/assignments/http-fields/>. </del>  Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more <del> detail in RFC9110.  As in HTTP/2, characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </del>  <del> Like HTTP/2, HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </del>  The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain

Removed one HTTP/2 reference which seems extraneous, and corrected the polarity of another. This by doing almost nothing; speak now if you think more is warranted.
RFC Editor says: But fair enough -- are we overdoing it?
Having looked at the references, they all seem reasonable with the possible exception of PUSH_PROMISE noting it behaves "as in HTTP/2." Most references to HTTP/2 occur either in the first two sections of the document or in the Appendix which specifically discusses the relationship between HTTP/2 and HTTP/3. removes that one extraneous reference. Other than than, I plan to make no further changes to address this feedback unless someone wants to provide a more concrete list of places where the comparison is unnecessary.
Marginal: Section 4.1.1 and 4.1.1.1 seems to have some egregious use of phrasing similar to "Like HTTP/2, ..." or "as in HTTP/2". You could possibly condense these to a sentence such as "Like HTTP/2, HTTP/3 has additional considerations related to use of characters in field names, the Connect header field, and pseudo-header fields". That could be inserted into to thefirst para of 4.1.1, or the second para (thus breaking the para so the next one starts with "Characters in field names").
Fixed in .

"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at  <ins> <https://www.iana.org/assignments/http-fields/>.  Like HTTP/2, HTTP/3 has additional considerations related to the use of characters in field names, the Connection header field, and pseudo-header fields. </ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more  <ins> detail in RFC9110.  Characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </ins>  <ins> HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain


7.2.5. The frame (type=0x05) is used to carry a promised request header <del> section from server to client on a , as in HTTP/2. </del>  The payload consists of:

7.2.5. The frame (type=0x05) is used to carry a promised request header  <ins> section from server to client on a . </ins> The payload consists of:


The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of <del> HTTP/2 (RFC7540).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (HTTP3), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </del>  streams. QPACK reuses core concepts from HPACK, but is redesigned to allow

These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of  <ins> HTTP/2 (RFC9113).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (RFC9114), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </ins> streams. QPACK reuses core concepts from HPACK, but is redesigned to allow


fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Sections 6.3 and 6.5 of SEMANTICS. </del>  Data associated with a field name, composed from all field line values with that field name in that section, concatenated together

fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See  <ins> Sections 6.3 and 6.5 of RFC9110. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together


8. This document makes multiple registrations in the registries defined <del> by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del>  8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in <del> HTTP3. </del>  For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.

8. This document makes multiple registrations in the registries defined  <ins> by RFC9114.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in  <ins> RFC9114. </ins> For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.


This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry <del> established in HTTP3. </del>  8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry <del> established in HTTP3. </del>

This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry  <ins> established in RFC9114. </ins> 8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry  <ins> established in RFC9114. </ins>


integer value (represented as a variable-length integer) that represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) the endpoint is willing to receive, in <del> bytes.  An endpoint that includes this parameter supports the DATAGRAM frame types and is willing to receive such frames on this connection.  Endpoints MUST NOT send DATAGRAM frames until they have received the max_datagram_frame_size transport parameter.  Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer. An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65535 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </del>  The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application

Clarify meaning of 0 in the datagram transport parameter, based on the discussion at IETF 110. This follows one of the suggestions to have 0 mean no datagrams, and > 0 mean support for datagrams. This should be a non-breaking change with existing implementations.
This change is very surprising. Why not take the approach that was discussed in the issue, wherein the limit describes the payload size, and presence of the transport parameter indicates extension support? It's not useful to have a bunch of ill-formed possibilities where the limit describes the frame size but is smaller than needed to encode the frame. See also URL
NAME this is based on the WG discussion, minuted here: URL
So it comes down to preserving the weird semantics nobody wants because renumbering the TP is aesthetically unappealing? That seems like a shame. Unless saying "I support it, but you can't send it" is actually useful somehow?
Right now, the TP specifies a maximum frame size, including frame type, length and payload. This makes certain values invalid (0, 1?). Also, since this values practically is a kind of flow control, indicating how much data I'm willing to receive at a time, it's the payload length that's important here, not the framing. For these reasons, I'm arguing to change this to specifying a maximum payload length. Then, the question of what a value of zero means. Should a value of 0 be the same thing as not present or should it mean that only 0 length datagrams are allowed? I think it is simpler to say that a value of zero is the same as not present (i.e. disabled). (Issue copied from , by NAME on 2019-11-18)
from NAME on 2019-11-18: Wasn't the legality of zero-length frames agreed upon in URL I didn't even realize that the parameter wasn't payload size. Strongly agree that it should be.
from NAME on 2019-11-19: I agree that is simpler to define zero to mean not allowed, but it is highly confusing to be forced to require a length of one if you specifically only use 0 length datagrams for heatbeats or similar. It would be better to a have separate indicator to reject datagrams altogether.
Isn't this indicated by omitting the transport parameter entirely?
NAME If omitting the parameter indicates that data frames are not permitted, then this achieves the purpose, yes. So there is no need to have 0 means disabling. Hence it is better to have 0 mean 0 length, but still valid. This is the most natural representation, and there is a an actual meaning ful use of these, namely heartbeats. Further, by making it explicit that length 0 is the only valid, you can have a fast or lightweight implementation.
I wonder if we need this limit at all. It introduces implementation complexity and it's unclear why any implementation would like to limit the size of DATAGRAM frames (or payloads) they can receive. We already have for implementations that have a limit on their stack size. Does anyone have a use-case where they'd like to limit the size of DATAGRAM frames (or payloads) specifically?
I'm all for removing the limit. As I have it coded up in MsQuic, I always send a max value. It's not even configurable by the app. I don't think "I have a buffering limit" a good reason to have a limit. It's limited by a single packet already. That should be enough IMO.
I don't think it's particularly useful to set this smaller than a packet, given that a reasonable buffer is bigger than that, and I'm not sure what a peer could usefully do with the information that the limit is larger than a packet. :+1:
The more I think about it, limiting the size of the QUIC DATAGRAMS (frames or payloads) is weird. In part because there is no wiresignal to describe a max number of DATAGRAMS per packet, and we seem to have discounted the need for an internal API to configure how frames are composed in a packet. I don't hear anyone with use cases; removing the limit removes a whole load of edge cases and/or implementation defined behaviour. I think the simplification would be a win.
NAME One reason you might want to limit Datagrams is if you have a slottet buffering system for datagrams, for example 1K, or 256 bytes per datagram, or a paged system of multiple datagrams. In this case you cannot always fit a whole package into the buffering. For streams you have an entirely different mechanism, and other frames are generally not large.
NAME that's an interesting thought - is this something you're planning on implementing and have a use for, or is it more of a thought experiment?
NAME Unfortunately I've had to push back on my QUIC dev, but I did work with an emulation of netmap, on top of select / poll, that uses slots to receive packets from the OS without context switching. Sometimes a packet needs to span multiple slots, but often it just drops into a 2K slot or so. I could imagine many use cases where datagrams are redistributed to other threads or processes in a similar manner without having an explicit use case. I believe there are now several kernel interfaces that uses a similar approach.
As far as I know, those kernel interfaces all use slots that are larger than the interface MTU, so I don't think they'd require reducing the payload size. Am I missing something?
Well, I can only speak for netmap, but it works by having the user specify one large memory block divided into a number of equal sized slots of a user specified size. Each slot has a control record with some flags. A record can indicate that the slot is partial and reference the next slot in the packet. So you can can choose a slot of 64K and waste a lot of memory, or choose a slot of 512 bytes and frequently have to deal with fragmenting. Or chose 2K for a use case where you know that you will not have larger payload and can afford the space overhead. EDIT: to clarify, it is the network driver that chooses to link data and update the control record when receiving, and the user process when writing. I'm not sure exactly how the other kernel interfaces behave but from memory it is rather much the same. For QUIC datagrams it is a bit different in that you likely want to avoid fragmentation at all cost due to the added complexity and the non-stream nature of the data. If you could afford fragmentation it would make less sense to have a limit on the size.
I support switching to TP specifying max payload size.
IIRC, the original reason this limit was introduced is to allow QUIC proxies to communicate the max datagram size it gets from the MTU between itself and the backend.
In my experience, a MASQUE proxy doesn't know that information at the time it opens a listening QUIC connection., and there is nothing to say that all backends would share the same value.
This is not for MASQUE, but for a direct QUIC-to-QUIC proxy.
OK, do you expect the max DATAGRAM frame size a backend expects to receive is smaller than the QUIC packet size it is willing to receive?
If we do have a max frame/perhaps size still defined, perhaps it makes sense to let this be updated by a new frame (MAXDATAGRAMSIZE).
A MAXDATAGRAMSIZE frame would be tricky because of reordering. In QUIC, all the MAX_FOOBAR frames can only increase limits, but here I suspect for this to be useful we'd want to be able to lower the limit which greatly increases complexity.
I expect this to be fairly uncommon, but whenever this does happen, it would make the entire connection unreliable for datagrams, meaning the applications would have to do their own MTU discovery on top of the one QUIC already does.
The default ought to be "whatever fits in the PMTU".
Yes, you have to do PMTUD. (What is pernicious here is that if you get too good at that, the value that you resolve to might not be good forever because your varints will use more bytes over time and so reduce available space.)
NAME which varints will use more bytes here?
I was thinking about flow IDs. If you are not reusing flow IDs, there is a good chance that those will get bigger over time. But I guess that assumes use of flow IDs. Mostly, I guess that DATAGRAM can be each sent in their own packet/datagram, so the size of other frames won't affect the space that is available.
Yeah the flow ID is part of the payload as far as this document is concerned. Our implementation will try to coalesce DATAGRAM frames with other frames, but that doesn't impact the max possible payload size because if the DATAGRAM frame doesn't fit with other frames we just send it in its own packet.

integer value (represented as a variable-length integer) that represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) the endpoint is willing to receive, in  <ins> bytes. The default for this parameter is 0, which indicates that the endpoint does not support DATAGRAM frames.  A value greater than 0 indicates that the endpoint supports the DATAGRAM frame types and is willing to receive such frames on this connection. An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value. An endpoint MUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value it has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not indicated support via the transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION.  Similarly, an endpoint that receives a DATAGRAM frame that is larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION. For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in the max_datagram_frame_size transport parameter to indicate that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </ins> The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application


max_datagram_frame_size <del> Indicates that the connection should enable support for unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive datagrams frames from the other endpoint, up to and including the length in bytes provided in the transport parameter. </del>  This document also registers a new value in the QUIC Frame Type registry:

max_datagram_frame_size  <ins> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </ins> This document also registers a new value in the QUIC Frame Type registry:


This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions.  Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].

Some applications might want to send messages, and not care about the order of delivery, but still get reliability. QUIC streams give them reliability, but within a stream it enforces order of delivery. This datagram proposal gives unordered delivery of messages, but without reliability. Why not provide datagrams with optional (opt-in) reliability? It shouldn't be a lot of extra work for QUIC implementors to provide reliable datagrams as well as unreliable, given that retransmission is already there for QUIC streams. (I guess an application could create a separate QUIC stream for each unordered reliable message. That might work, but seems ugly and may have some overhead.)
What you describe can already be accomplished using streams: each “reliable datagram” is its own stream. That provides reliable delivery without ordering between independent datagrams. I don’t think we need to add optional reliability to the datagram spec.
Streams are very lightweight, and well suited to this task. Beware applying intuition from TCP too heavily.
So, here's a suggestion then: since I'm sure I'm not the only person who is going to think of this, maybe add some verbiage to the spec explaining why supporting reliable datagrams is unnecessary?
Sounds good. We can keep this issue open as requesting an editorial change.

This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <ins> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </ins> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].


7.  This document registers a new value in the QUIC Transport Parameter <del> Registry: </del>  <del> 0x0020 (if this document is approved) </del>  max_datagram_frame_size <del> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </del>  <del> This document also registers a new value in the QUIC Frame Type registry: </del>  0x30 and 0x31 (if this document is approved) DATAGRAM <del> Unreliable application data </del>  8.

The IANA section was added before the QUIC registries had a notion of permanent vs provisional, and we then forgot to update it. This PR fixes that oversight.
Latest change looks good to me
Noticed during Shepherd review. All of the core types registered in RFC 9000 simply link to the relevant document (RFC 9000) and section in the document where the protocol element is defined. In contrast, in datagram's IANA considerations section, the transport parameter and frame type registrations include the required field with some text that is already included in the document. This will manifest as a weird juxtaposition in the IANA table. I suggest you simply reference the section 3 and section 4 respectively. If you really want some prose (I don't recommend that) then it can be added as a note to the table.
I noticed that when writing and I agree, we should just list "This specification" in there as most RFCs do.
Noticed during the shepherd writeup of IANA considerations: The document is attempting to register: maxdatagramframe_size Transport Parameter with value 0x0020 DATAGRAM frame type with values 0x30 and 0x31 According to IANA (URL) registrations can be of different types. Here the requested values are in the bracket. So I suggest that the document state clearly that this is a request for permanent registration of these types.
Agreed. Wrote up to fix this.
LGTM, thanks!

7. <ins> 7.1. </ins> This document registers a new value in the QUIC Transport Parameter  <ins> Registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-transport>. </ins>  <ins> 0x20 (if this document is approved) </ins> max_datagram_frame_size  <ins> permanent This document </ins>  <ins> 7.2. This document registers two new values in the QUIC Frame Type registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-frame-types>. </ins> 0x30 and 0x31 (if this document is approved) DATAGRAM  <ins> permanent This document </ins> 8.


extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters <del> with an "x-<vendor>" identifier, e.g. "x-acme-policy", "x-acme- burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del>  2.2.

See .
iirc there was a discussion on stuff. In general I'm ok with just NAME do you see any issue with that?
No issue, I was aware of the BCP and I think this case fits the first provision for segregating the name spaces in the Appendix B, so any one of the proposed solutions there, including yours, is fine with me.

extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters  <ins> with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </ins> 2.2.


references.  Like all search criteria, on a resource lookup it can match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any <del> group resource that endpoint is contained in. </del>  Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

This decides the open question of how to match the in a query in favor of client simplicity. Closes: URL NAME NAME would that change be OK with you and solve the issue?
I know what an absolute form is, where do I find out what a path absolute form is
path-absolute is an ABNF in RFC3986, described as "begins with a '/' but not '//'".
I agree with the addition. This means that one can match against an absolute registration target as well.
Jim in :
It's a trade-off between not being a surprise to the RD implementation (with b, it needs to compare values that it has not seen in that form) versus not being a surprise to the lookup client (with a, it queries for something it does not see in that form in the query result). I think that the latter is preferable. Here are some more questions on the document. The registration text in section 5.3 says that the interface is idempotent, however it is not clear to me just how idempotent this is supposed to be. It is obvious that the goal is to make sure that a different resource is not created, however I am not clear what is supposed to happen with some of the parameters such as the 'lt' parameter. One way to implement this is to just make it a POST to the previously existing resource which would inherit old attributes on the endpoint. The other way is to say we are going to create a new resource, it just has the same address. It is not clear which, if any, of these two methods is to be used. Never mind I found the answer to this one. Need to think if I want clearer language. When doing an endpoint lookup, I assume that the 'lt' parameter would be the same as the one registered at creation. Is there/should there be a parameter which is a TTL value? How are href comparisons done. a) compare against what was registered b) Resolve what was registered and the href in the current context and compare c) something I did not think of compare on group for remote endpoint. Should this do the remote lookup or can it just be ignored for attribute comparison Value of lt = should it be the set parameter or the time left - how would time left be represented outherwise - should it be represented. Inferred context based on source IP when an update is done. If no con is provided, is that supposed to be checked again to see if it is "right"? Only if we did the infer to begin with? I don't understand the presence of the content-format for the empty message posted for simple registration. This seems to be odd if the content is empty. 8 Is there supposed to be a way for simple registration to return an error message? As written this is not necessarily done. Specifically, the response to the post can be executed before the query to /.well-known/core is done and the registration is attempted.

references.  Like all search criteria, on a resource lookup it can match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any  <ins> group resource that endpoint is contained in.  Queries for resource link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource