This is a clear, well-written document, with one exception noted below. Note that my understanding of QUIC is quite shallow and it's possible I missed something in here that is obviously wrong or dangerous if you have a deeper understanding of QUIC. I think the following are all nits except perhaps the extremely thin state of the Security Considerations section. Section 2.3 paragraph 4, this is arguably part of the definition of what "Compatibility" means: that such a document exists with a description of the server-to-client signaling mechanism. Thus, the definition of "Compatible" at the start of section 2.2 is arguably incomplete: '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 from version B.' Same para: "Any set of mutually compatible versions SHOULD use the same mechanism." Um, are mutually compatible versions necessarily organized into sets which are disjoint? That wasn't obvious to me from the narrative and, if so, maybe worth saying. Section 4 paragraph 5 is really hard to understand for this non-QUIC-expert. An example of the situation where the client might (invalidly) make a choice incompatible with its knowledge of what the server supports would be useful. Section 5, last para, "Note that this opens connections to version downgrades" - do you mean "opportunities for" or "risk of"? "connections to" is awkward. Section 7.1, send para: "If a future document wishes to define compatibility between two versions that support retry, that document MUST specify…" Is an RFC allowed to impose MUST constraints on future RFCs? Not a rhetorical question, just never seen anything like this before. (Also 7.3) Section 7.2. Sounds reasonable, but some motivation might be nice. Section 9, Security Considerations, seems very short for such a foundational piece of protocol. I would have hoped to see some discussion of threat models. (There seems to be good attention to security issues in the body of the document.)