Re: [Last-Call] Opsdir last call review of draft-ietf-quic-version-negotiation-10

[Qin Wu <[e-mail]>]

Hi, David:

Thanks for taking my comments into account, one more comment to version negotiation mechanism, do you think a single error code “TRANSPORT_PARAMETER_ERROR
” is sufficient, do you need to distinguish different reasons for version negotiation failure, if I am wrong, please correct me.
please see follow up comment inline.

发件人: David Schinazi [mailto:[e-mail]]
发送时间: 2022年10月1日 6:37
收件人: Qin Wu <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Re: Opsdir last call review of draft-ietf-quic-version-negotiation-10

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 <[e-mail]<mailto:[e-mail]>> 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.
https://github.com/quicwg/version-negotiation/pull/127
[Qin] Thanks, the proposed change looks good.
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.
[Qin]: If that is the case, I suggest to add some text to explain this analysis is not in the scope of this document.
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.
[Qin]:Thank for clarification, I am wondering why not request both codepoints at the same time,
I feel the current text in section 10 for codepoint request is temporary text and subject to change, would it be great to make these text normative,
Which doesn’t need to make another request using one more 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:
https://github.com/quicwg/version-negotiation/pull/128

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?
[Qin]:I suggest to consider the relation between fully supported and negotiated versioned, offered version, accepted version.
If my understanding is correct, parsing the first flight of a given version means you can negotiate a new version between the client
And the server ,if the negotiated version is not accepted version or not agreed by both the client and server,we can not use the negotiated
Version to establish the connection, not less than communicate the data packet using this version.
Hope this helps you find 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.
[Qin] Okay, my logic is you should make different xx version definition in the first place to help reader who has no quic background better understand
The mechanism proposed in this draft.
I will leave this up to you, no strong opinion on this.

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.
[Qin]Good.
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:
https://github.com/quicwg/version-negotiation/commit/e1ca5b749e2ea2347db7d8353bc2f9cc770ae354

[Qin]: Thanks. I am clear for this comment.