Hi Éric, and thank you for your review. Responses inline. David On Mon, Oct 24, 2022 at 11:44 PM Éric Vyncke via Datatracker < [email protected]> wrote:
> Éric Vyncke has entered the following ballot position for > draft-ietf-quic-version-negotiation-12: No Objection > > ## COMMENTS > > ### Section 2 > > In `the versions are compatible` what is meant by 'compatible' ? Identical > version ? Some clarity early in the document will help the reader without > waiting the section 2.2. > Added a reference to 2.2: https://github.com/quicwg/version-negotiation/commit/d45e03bc821775266f3b70985506957eb7cafdc6 ### Section 11 > > As the "TCP" reference is only used in a note in section 1.2, it should > probably be an informative reference. > Sure, made it informative. https://github.com/quicwg/version-negotiation/commit/344ba60a6366a6d119578c76a8a924b66730fd22 ### Section 4 > > ``` > For QUIC version 1, version negotiation errors are signaled using a > transport error of type VERSION_NEGOTIATION_ERROR; see Section 10.2. > ``` > Just wondering how an already deployed QUIC version 1 implementation that > was > not updated will know how to send this error type as it is only specified > by > the document in 2022... I am sure that I miss something else I would have > balloted a DISCUSS. > An implementation of QUIC that does not support this version negotiation extension will not send these errors. There is no concept of version negotiation error in the QUIC v1 RFCs. ### Section 5 > > Just to write my appreciation of this section that takes deployment in > consideration. Good idea! > Thank you! ### Section 7.2 > > Same explanations about the use of "SHOULD" will probably be welcome by > implementers. > Added an explanation https://github.com/quicwg/version-negotiation/commit/7ff7a8d044559b157b0fac15ddf54a7db44f0234
