Original text:
9. <del> This document has no actions for IANA. </del>  10.  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for applications using QUIC, as well. connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 11. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Reviewer comments:
NAME should probably double-check my work here. This assumes that we take the compatible version upgrade stuff, but if we don't, there's only one sentence to remove. I've tried to keep it abstract enough that the details won't matter.
LGTM. Thank you for writing it down!
Moving this from quicwg/base-drafts to here.
NAME NAME can one of you maybe provide some text?
is probably exactly what needs to be said for this issue.
lgtm

Revised text:
9.  <ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters. A server that rolls out a new version of QUIC can do so in three stages.  Each stage is completed across all server instances before moving to the next stage. In the first stage of deployment, all server instances start accepting new connections with the new version.  The new version can be enabled progressively across a deployment, which allows for selective testing.  This is especially useful when the new version is compatible with an old version, because the new version is more likely to be used. While enabling the new version, servers do not advertise the new version in any Version Negotiation packets they send.  This prevents clients that receive a Version Negotiation packet from attempting to connect to server instances that might not have the new version enabled. During the initial deployment, some clients will have received Version Negotiation packets that indicate that the server does not support the new version.  Other clients might have successfully connected with the new version and so will believe that the server supports the new version.  Therefore, servers need to allow for this ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances are able accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do not.  This state will persist only for as long as any Version Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay. The third stage completes the process by enabling validation of the negotiation version as though the new version were disabled. The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse. Servers disable validation of the old version, stop sending the old version in Version Negotiation packets, then the old version is no longer accepted. </ins> 10. <ins> This document has no actions for IANA. 11. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for applications using QUIC, as well. connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  <ins> 12. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture