Last Call Review of draft-ietf-quic-version-negotiation-10
review-ietf-quic-version-negotiation-10-opsdir-lc-wu-2022-09-30-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes a version negotiation mechanism that allows a client
and server to select a mutually supported version. The mechanism can be further
broke down into incompatible Version Negotiation and compatible Version
Negotiation.

I believe this document is on the right track and but worth further polished
with the following editorial comments. Major Issues: No Minor Issues: 1.
Section 4 introduce verson downgrade term [Qin]What the version downgrade is? I
feel confused, does it mean when I currently use new version, I should not fall
back to the old version? Can you explain how version downgrade is different
from version incompatible? It will be great to give a definition of version
downgrade in the first place or provide an example to explain it? 2. Section 9
said: " The requirement that versions not be assumed compatible mitigates the
possibility of cross-protocol attacks, but more analysis is still needed here."
[Qin] It looks this paragraph is incomplete, what else analysis should we
provide to make this paragraph complete? 3. Section 10 [Qin]: I am not clear
why not request permanent allocation of a codepoint in the 0-63 range directly
in this document. In my understanding, provisional codepoint can be requested
without any dependent document? e.g., Each vendor can request IANA for Vendor
specific range. Secondly, if replacing provisional codepoint with permanent
allocation, requires make bis for this document, I don't think it is
reasonable. Nits: 1. Section 2 said: " For instance, if the client initiates a
connection with version A and the server starts incompatible version
negotiation and the client then initiates a new connection with .... " [Qin]Can
the client starts incompatible version negotiation? if not, I think we should
call this out, e.g., using RFC2119 language. 2. Section 2, last paragraph [Qin]
This paragraph is a little bit vague to me, how do we define not fully support?
e.g., the server can interpret version A, B,C, but the server only fully
implements version A,B, regarding version C, the server can read this version,
but can not use this version, in other words, it is partially implemented, is
my understanding correct? 3.Section 2.1 the new term "offered version" [Qin]
Can you add one definition of offered versions in section 1.2, terminology
section? To be honest, I still not clear how offered version is different from
negotiated version? Also I suggest to add definitions of accepted version,
deployed version as well in section 1.2? Too many terminologies, hard to track
them in the first place. 4. Section 6 said: " it is possible for some
application layer protocols to not be able to run over some of the offered
compatible versions. " [Qin]I believe compatible versions is not pertaining to
any application layer protocol, if yes,
 s/compatible versions/compatible QUIC versions
5.Section 7.1 said:
"For example, that could be accomplished by having the server send a Retry
packet in the original
 version first thereby validating the client's IP address before"
[Qin] Is Version first Version 1? If the answer is yes, please be consistent
and keep using
 either of them instead of inter-exchange to use them.
 s/version first/version 1