Éric Vyncke 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-quic-version-negotiation-12 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Matt Joras for the shepherd's detailed write-up including the WG consensus *even* if the justification of the intended status is rather weak. Please note that Petr Špaček is the DNS directorate reviewer (at the chairs' request) and you may want to consider his review as well (and I have read the email dialogue with David): https://mailarchive.ietf.org/arch/msg/dnsdir/swTm6QGRLQqnsVC87asXiedii9s/ I hope that this review helps to improve the document, Regards, -éric ## 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. ### Section 11 As the "TCP" reference is only used in a note in section 1.2, it should probably be an informative reference. ### 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. ### Section 5 Just to write my appreciation of this section that takes deployment in consideration. Good idea! ### Section 7.2 Same explanations about the use of "SHOULD" will probably be welcome by implementers. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
