[Last-Call] Artart last call review of draft-ietf-quic-version-negotiation-10

[Tim Bray via Datatracker <[e-mail]>]

Reviewer: Tim Bray
Review result: Ready with Issues

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.)