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

Discussion:
4. <del> QUIC version 2 endpoints SHOULD also support QUIC version 1.  Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </del> <ins> QUIC version 2 is not intended to deprecate version 1.  Endpoints that support version 2 might continue support for version 1 to maximize compatibility with clients.  In particular, HTTP clients often use Alt-Svc RFC7838 to discover QUIC support.  As this mechanism does not currently distinguish between QUIC versions, HTTP servers that support multiple versions reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback.  For example, an origin advertising support for "h3" in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC version used by HTTP/3 and therefore some clients will only support that version. Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </ins> Note that version 2 meets that document's definition of a compatible <del> version with version 1.  Therefore, v2-capable servers MUST use compatible version negotiation unless they do not support version 1. </del> <ins> version with version 1.  Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </ins> 4.1.

5. <ins> TLS session tickets are specific to the QUIC version of the connection that provided them.  Clients MUST NOT use a session ticket from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. Servers SHOULD validate the originating version of any session ticket and not resume from any ticket issued from a different version.  This results in falling back to a full TLS handshake, without 0-RTT. After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than original one. 6. </ins> QUIC version 2 provides protection against some forms of ossification.  Devices that assume that all long headers will contain encode version 1, or that the version 1 Initial key derivation

server supports it, or are willing to suffer a round-trip penalty if they are incorrect. <del> 6. </del> <ins> 7. </ins> This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications.  Therefore, all

All QUIC extensions defined to work with version 1 also work with version 2. <del> 7. </del> <ins> 8. </ins> QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.

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: