Thanks Rob, I've taken your suggestion in https://github.com/quicwg/quic-v2/pull/80.
Martin On Mon, Oct 24, 2022 at 3:08 AM Robert Wilton via Datatracker < [email protected]> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-quic-v2-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-v2/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thank you. Another well written, easy to read, draft from the QUIC WG. > > Minor level comments: > > (1) p 2, sec 1. Introduction > > QUIC version 2 is meant to mitigate ossification concerns and > exercise the version negotiation mechanisms. The changes provide an > example of the minimum set of changes necessary to specify a new QUIC > version. > > As a minor comment, I would suggest adding some text to the first sentence > to > cite that choosing a value other than 2 for the version number, and > changing > the type field assignment of the long header packet format, are examples of > mitigating ossification concerns. Specifically, I presume it isn't the > case > that all new QUIC versions need to renumber the type fields or choose a > fixed > random number for the version number? I.e., strictly speaking I assume > that > these are not the minimal set of changes for any new QUIC version? > > Regards, > Rob > > // Thanks to Bo for the OPS DIR review. > > > >
