Éric Vyncke's No Objection on draft-ietf-quic-version-negotiation-12: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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