Change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> In this document, the Maximum Segment Lifetime (MSL) represents the time a QUIC packet can exist in the network.  Implementations can make this configurable, and a RECOMMENDED value is one minute. </ins> 2. <ins> While this document mainly discusses a single QUIC server, it is common for deployments of QUIC servers to include a fleet of multiple server instances.  We therefore define the following terms: This is the set of versions supported by a given server instance. More specifically, these are the versions that a given server instance will use if a client sends a first flight using them. This is the set of versions that a given server instance will send in a Version Negotiation packet if it receives a first flight from an unknown version.  This set will most often be equal to the Acceptaple Versions set, except during short transitions while versions are added or removed (see below). This is the set of QUIC versions that is supported and negotiated by every single QUIC server instance in this deployment.  If a deployment only contains a single server instance, then this set is equal to the Offered Versions set, except during short transitions while versions are added or removed (see below). If a deployment contains multiple server instances, software updates may not happen at exactly the same time on all server instances. Because of this, a client might receive a Version Negotiation packet from a server instance that has already been updated and the client's resulting connection attempt might reach a different server instance which hasn't been updated yet. However, even when there is only a single server instance, it is still possible to receive a stale Version Negotiation packet if the server performs its software update while the Version Negotiation packet is in flight. This could cause the version downgrade prevention mechanism described in downgrade to falsely detect a downgrade attack.  To avoid that, server operators SHOULD perform a three-step process when they wish to add or remove support for a version: When adding support for a new version: The first step is to progressively add support for the new version to all server instances.  This step updates the Acceptable Versions but not the Offered Versions nor the Fully-Deployed Versions.  Once all server instances have been updated, operators wait for at least one MSL to allow any in-flight Version Negotiation packets to arrive. Then, the second step is to progressively add the new version to Offered Versions on all server instances.  Once complete, operators wait for at least another MSL. Finally, the third step is to progressively add the new version to Fully-Deployed Versions on all server instances. When removing support for a version: The first step is to progressively remove the version from Fully- Deployed Versions on all server instances.  Once it has been removed on all server instances, operators wait for at least one MSL to allow any in-flight Version Negotiation packets to arrive. Then, the second step is to progressively remove the version from Offered Versions on all server instances.  Once complete, operators wait for at least another MSL. Finally, the third step is to progressively remove support for the version from all server instances.  That step updates the Acceptable Versions. Note that this opens connections to version downgrades (but only for partially-deployed versions) during the update window, since those could be due to clients communicating with both updated and non- updated server instances. 3. </ins> If A and B are two distinct versions of QUIC, A is said to be "compatible" with B if it is possible to take a first flight of packets from version A and convert it into a first flight of packets

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.