Draft: draft-ietf-quic-applicability

Commentary: From review . 
 Not sure if this is the right approach . The whole point of this document is that we do n't want the reader ask to read the spec in details but pre - digest the important bits for the reader . 
 I 'm not going to lie down in the road over this , but maybe there 's a middle ground ? Instead of punting totally to the VN Draft , maybe we can specifically say that VN has a deployment template in that section ? 
 Feel free to create a PR :-) 
 per discussion with on 5 July , keep the new text but add a short but useful summary of version negotiation above it . I 'll rework this PR . 
 This entire section appears to be a duplicate of section 5 of the version negotiation draft . I suggest the authors verify that the latter has all the relevant information , and then replace this section with a reference to the VN draft .
Paragraph (version A):
QUIC version 1 does not specify a version negotiation mechanism in
the base spec but I-D.draft-ietf-quic-version-negotiation proposes an
extension.  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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
The second stage of deployment commences once all server instances
are able to accept new connections with the new version.  At this
point, all servers can start sending the new version in Version
Negotiation packets.
Paragraph (version A):
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.
Paragraph (version A):
The third stage completes the process by enabling authentication of
the negotiated version with the assumption that the new version is
fully available.
Paragraph (version A):
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.
Paragraph (version B):
QUIC version 1 does not specify a version negotiation mechanism in
the base specification, but I-D.draft-ietf-quic-version-negotiation
proposes an extension that provides compatible version negotiation.
Paragraph (version B):
This approach uses a three-stage deployment mechanism, enabling
progressive rollout and experimentation with multiple versions across
a large server deployment.  In this approach, all servers in the
deployment must accept connections using a new version (stage 1)
before any server advertises it (stage 2), and authentication of the
new version (stage 3) only proceeds after advertising of that version
is completely deployed.
Paragraph (version B):
See Section 5 of I-D.draft-ietf-quic-version-negotiation for details.