Hi Qin, thank you for your comments, responses inline.
Note to other WG members: PR 127 is completely editorial but 128 does add
some RFC 2119 language that was previously implicit, please double-check my work.
Thanks,
David
On Fri, Sep 30, 2022 at 5:48 AM Qin Wu via Datatracker <noreply@xxxxxxxx> wrote:
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?
It's a pretty common term of art in versioned protocols but I've defined it in Section 4.
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?
The paragraph is complete. It acknowledges the potential for cross-protocol attacks
and encourages more research in this area.
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.
The IANA section means that when the IESG approves the document, we will
modify the document to select a permanent 0-63 codepoint before or during
AUTH48. There will be no need for a bis document.
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.
Good catch, this was an implicit assumption. I made it explicit with 2119 text:
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?
Your understanding is correct. Do you have suggestions for better wording?
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.
Those terms are introduced with a reference to Section 5 that very clearly
defines them. Duplicating those definitions in Section 1.2 would make the
document less clear in my opinion.
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
Compatible versions are defined as referring to QUIC versions. My apologies
but I think the existing text is clearer.
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
You're misunderstanding this sentence, I've moved the word first to avoid the confusion:
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
