Thank Rob!

I agree with you, so I made the following editorial commit to address your
comment:
https://github.com/quicwg/version-negotiation/commit/50a9fb8b81252b74116b41e499d5618c14af5451
It adds <<The ordering of the versions in this field does not carry any
semantics.>>

David

On Mon, Oct 24, 2022 at 2:55 AM Robert Wilton via Datatracker <
[email protected]> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-quic-version-negotiation-12: 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-version-negotiation/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for another clear and well written document.
>
> One minor comment:
>
> (1) p 9, sec 3.  Version Information
>
>    Client-Sent Available Versions:  When sent by a client, the Available
>       Versions field lists all the versions that this first flight is
>       compatible with, ordered by descending preference.  Note that the
>       version in the Chosen Version field MUST be included in this list
>       to allow the client to communicate the chosen version's
>       preference.  Note that this preference is only advisory, servers
>       MAY choose to use their own preference instead.
>    Server-Sent Available Versions:  When sent by a server, the Available
>       Versions field lists all the Fully-Deployed Versions of this
>       server deployment, see Section 5.  Note that the version in the
>       Chosen Version field is not necessarily included in this list,
>       because the server operator could be in the process of removing
>       support for this version.  For the same reason, the Available
>       Versions field MAY be empty.
>
> It might be helpful to explicitly indicate whether the sever-sent available
> versions are ordered (as per the client), or unordered.  I presume that it
> is
> latter because it isn't stated, but it may improve readability of the
> document
> if this was explicit.
>
> Regards,
> Rob
>
> // Thank to Qin for OPSDIR review.
>
>
>
>

Reply via email to