Hello all, Thank you for the responses to the Working Group Last Call. The chairs are happy that the document is ready to move to the next stage of the process. Stay tuned for further updates.
Best regards Lucas & Matt QUIC WG Chairs On Fri, Apr 22, 2022 at 4:32 PM David Schinazi <[email protected]> wrote: > Hi Mirja, thank you for your review. Responses inline. > David > > On Fri, Apr 22, 2022 at 3:14 PM Mirja Kuehlewind < > [email protected]> wrote: > >> Hi all, >> >> >> >> I reviewed the version negotiation draft and I think it’s ready to >> proceed. >> >> >> >> I proposed one PR with a small clarification that I thought could be >> helpful and I have one comment and a question, which I thought might be >> faster to address by mail, so here it comes: >> > > Thanks, we've merged your PR. > > >> My comment/proposal: >> >> I would find a terminology section actually helpful in order to have all >> three terms defined at the same place: "original version", "client's chosen >> version", and “negotiated version”. I had to read this multiple time to be >> fully clear about the differences. Also another term one could maybe >> explicitly define is “first flight”. This term is used in RFC9000 but in >> the context of one specific version is probably more clear. >> > > That makes sense. I wrote this up as a PR, please review: > https://github.com/quicwg/version-negotiation/pull/107 > > Any my question: >> >> The Chosen version field in section 3 is defined the following way: >> >> >> >> “The version that the sender has chosen to use for this connection. In >> most cases, this field will be equal to the value of the Version field in >> the long header that carries this data.” >> >> >> >> Why is this saying in most cases? What are the cases when this would not >> be equal? Or is this cover potential different behavior of future version? >> Would be could to clarify this! >> > > The latter, I've clarified in this PR: > https://github.com/quicwg/version-negotiation/pull/108 > > Mirja >> >> >> >> >> >> >> >> *From: *QUIC <[email protected]> on behalf of David Schinazi < >> [email protected]> >> *Date: *Wednesday, 13. April 2022 at 11:18 >> *To: *Matt Joras <[email protected]> >> *Cc: *IETF QUIC WG <[email protected]> >> *Subject: *Re: Working Group Last Call: QUIC Version Negotiation >> >> >> >> Thank you Matt! >> >> >> >> The editors will strive to address editorial comments as they come in. >> >> To help us with that process, I recommend that everyone review the latest >> editor's copy available here: >> >> >> https://quicwg.org/version-negotiation/draft-ietf-quic-version-negotiation.html >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b5772e3ae3fc7520&q=1&e=dd2ebf17-6afb-4150-ba3e-b9ea85018917&u=https%3A%2F%2Fquicwg.org%2Fversion-negotiation%2Fdraft-ietf-quic-version-negotiation.html> >> >> That way you'll review the latest document with improvements made during >> WGLC. >> >> >> >> Thanks, >> >> David >> >> >> >> On Tue, Apr 12, 2022 at 7:25 PM Matt Joras <[email protected]> wrote: >> >> Hello all, >> >> This email announces the WGLC of the latest QUIC version negotiation >> draft[1]. This document has seen significant work and thanks to persistent >> effort of the authors and other contributors the design and editorial >> content has stabilized. The chairs and authors believe it is ready for a >> last call. There are multiple interoperating implementations for compatible >> version negotiation, and downgrade prevention has been deployed at scale. >> This last call will run through April 26th. Please email any issues to the >> list or file them on Github[2]. >> >> Thanks, >> Matt & Lucas >> QUIC WG Chairs >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/ >> >> [2] https://github.com/quicwg/version-negotiation >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-e2f7a157cd4462af&q=1&e=dd2ebf17-6afb-4150-ba3e-b9ea85018917&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fversion-negotiation> >> >>
