Thank you David, this was a QUIC reply ;-) (ok, old joke)

Still unclear to me about the section 4 comment though but it is non-blocking

Thanks again for the changes and your reply

-éric


From: iesg <iesg-boun...@ietf.org> on behalf of David Schinazi 
<dschinazi.i...@gmail.com>
Date: Tuesday, 25 October 2022 at 19:31
To: Eric Vyncke <evyn...@cisco.com>
Cc: The IESG <i...@ietf.org>, "draft-ietf-quic-version-negotiat...@ietf.org" 
<draft-ietf-quic-version-negotiat...@ietf.org>, "quic-cha...@ietf.org" 
<quic-cha...@ietf.org>, "quic@ietf.org" <quic@ietf.org>, "matt.jo...@gmail.com" 
<matt.jo...@gmail.com>, "pspa...@isc.org" <pspa...@isc.org>
Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-quic-version-negotiation-12: (with COMMENT)

Hi Éric, and thank you for your review. Responses inline.
David

On Mon, Oct 24, 2022 at 11:44 PM Éric Vyncke via Datatracker 
<nore...@ietf.org<mailto:nore...@ietf.org>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-quic-version-negotiation-12: No Objection

## 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.

Added a reference to 2.2:
https://github.com/quicwg/version-negotiation/commit/d45e03bc821775266f3b70985506957eb7cafdc6

### Section 11

As the "TCP" reference is only used in a note in section 1.2, it should
probably be an informative reference.

Sure, made it informative.
https://github.com/quicwg/version-negotiation/commit/344ba60a6366a6d119578c76a8a924b66730fd22

### 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.

An implementation of QUIC that does not support this version negotiation 
extension will not send these errors.
There is no concept of version negotiation error in the QUIC v1 RFCs.

### Section 5

Just to write my appreciation of this section that takes deployment in
consideration. Good idea!

Thank you!

### Section 7.2

Same explanations about the use of "SHOULD" will probably be welcome by
implementers.

Added an explanation
https://github.com/quicwg/version-negotiation/commit/7ff7a8d044559b157b0fac15ddf54a7db44f0234

Reply via email to