|
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:dschinazi.ietf@xxxxxxxxx]
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:
It's a pretty common term of art in versioned protocols but I've defined it in Section 4. [Qin] Thanks, the proposed change looks good.
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.
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.
Good catch, this was an implicit assumption. I made it explicit with 2119 text:
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.
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.
Compatible versions are defined as referring to QUIC versions. My apologies but I think the existing text is clearer. [Qin]Good.
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. |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
