Change:
attacks, but downgrades have no security implications, as the version properties are identical. <del> 8. </del> <ins> 9. </ins> This document requests that IANA add the following entry to the QUIC version registry:

Discussion:
Incorporated all suggestions. My only concern about server MUST is that it involves mucking with TLS implementations again to encode version in the ticket. Would this be a real obstacle]?
NAME for any implementation that uses BoringSSL (and I suspect the OpenSSL API is the same way), adding the version to the ticket will not require modifying the TLS implementation at all because the TLS implementation already accepts an opaque blob of data from QUIC (and that's currently used for transport parameters and h3 settings, adding the QUIC version would be transparent to TLS).
I am a bit concerned that we are departing from the common pattern used in QUIC specification: "Clients MUST NOT do this particular vile thing; server MAY terminate the connection if they catch the client doing it." The purpose of the MUST NOT is to prevent the client from creating problems at the server. The purpose of the MAY is to encourage servers to do some enforcement, so bad client implementations have a good chance of being detected and do not become some entrenched practice. Telling the servers that they MUST enforce forces servers to dedicate resource to explicit detection, which may not be the right tradeoff for classes of servers, such as for example embedded servers with resource constraints.
NAME that is true, however TLS has a common pattern which is to require servers to validate their tickets thoroughly. I guess we have to pick which common pattern we care about most. I still think having the MUST on both clients and servers will lead to better interoperability
NAME maybe. The way I deal with that in the picoquic demo server is simple: the default transport parameters are set when the process start, and by default the STEK key is also set at process start. I suppose that embedded servers could just follow that tradeoff, i.e., forget tickets issued before the last reboot in exchange for code simplicity. But the simple server only verifies that the version is "one of the supported versions", does not check the ticket for that. So this is extra code. Not a ton of extra code, so I am not going to fight that too long. But still extra code.
I changed the MUST to a SHOULD. "Servers gonna do", so what we write here doesn't matter much, but I see no reason to create RFC violations where they're not really needed, and on the off chance that some servers have a serious obstacle to doing this.

During the discussion of URL, we came to the conclusion that it was simplest and safest to ban TLS resumption across QUIC versions. The version negotiation draft will mention this, but without normative text because TLS is not a QUIC invariant. The QUICv2 draft should add normative text to explicitly ban resuming TLS across versions.
Does this consensus apply to compatible VN? If the client initiates with v1 and a v1 resumption ticket, can the server upgrade it to v2 and still respect the 0RTT, etc? IIUC, this means that if the client connects with v1 and learns that the server does v2, but there's no upgrade, if the client decides to connect next time with v2 it can't use 0RTT because there will have been a v1 resumption ticket? Whereas an upgraded connection would have a v2 resumption ticket?
What does this mean? How does the client "learn" that the server speaks v2 if the server didn't perform compatible VN from v1 to v2?
If the server does not upgrade, but it learns about available versions via the TP.
The server's Other Versions field exists to prevent downgrades in incompatible VN. There's no text suggesting that clients remember that information for use outside of the current connection.
That may not have been your intent, but why wouldn't a client do this?
This issue is hopelessly intertwined with other issues, like how we handle ALPN. I am not equipped to evaluate the claim that cross-version use of tags will cause a security problem, although as I understand it this sentiment is a concern rather than an established threat. However: the use case I am concerned about involves a client learning about an incompatible version via the supported_versions TP, and choosing to connect to that version. If the resumption tags aren't reusable, then it has to lose an RTT by not doing 0RTT. Relying on incompatible VN would be two RTTs before data arrives. Granted, v1 and v2 are not incompatible. But if it's not actually unsafe, I'd rather set a precedent that works for future, incompatible versions.
Outcome of offline discussion with NAME and NAME 1) Clients MUST NOT use a resumption ticket from a QUIC connection and apply it to another version.

2) Servers SHOULD validate that resumption tickets are not being used across QUIC versions and refuse to honor the ticket (or terminate the connection?) if they are. 3) Make it clear that the resumption ticket from a connection that did compatible VN maps to the negotiated version, not the original one.
Wow, that was a fast shift back to "SHOULD". I missed that. I did a little digging and it seems like there is a different determination for 0-RTT and resumption in our code. Accepting 0-RTT is something that needs to be controlled, but resumption has no similar controls. In that, we're in a similar position to NAME We can't really stop resumption without first performing a little surgery on the TLS stack. With that in mind, I'm conditionally OK with this resolution. That's a purely pragmatic decision on my part on the basis that "compatible" in this case means not really changing anything about TLS.
I'm not 100% firm on the server "MUST", but I really think we should consider it.