Subject: Call for Adoption: draft-schinazi-quic-version-negotiation

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 08:35:43 +1100

This is a Call for Adoption of the following document:
  https://tools.ietf.org/html/draft-schinazi-quic-version-negotiation-02

The Working Group has discussed recently in Singapore, where there was support for quick adoption.

Please state whether you support adoption of the document by the Working Group, and any additional information that you feel may be helpful.

This call will end on 15 January 2020.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Dec 2019 13:49:39 -0800

I support adopting this document.

We should be working on getting version negotiation done asap, since it is
an important extensibility mechanism for QUIC. Not having a mechanism means
that any work on a next version (even local experiments) is effectively
stymied, which increases the risk that this extensibility mechanism becomes
unusable. Not only should we adopt this document, we should act towards
shipping this soon after (or even at the same time as) QUICv1 ships.

- jana

On Wed, Dec 11, 2019 at 1:36 PM Mark Nottingham <[email-masked]> wrote:

> Please state whether you support adoption of the document by the Working
> Group, and any additional information that you feel may be helpful.
>

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 11 Dec 2019 15:06:04 -0800

I definitely support adopting this document.

On Wed, Dec 11, 2019 at 1:50 PM Jana Iyengar <[email-masked]> wrote:

>  Not having a mechanism means that any work on a next version (even local
> experiments) is effectively stymied,
>

Eh? That's a bit overbroad isn't it? If you want to locally experiment with
a non-standardized QUIC v2, surely you can experiment with
a non-standardized VN mechanism, right? Or you can even do no VN at all if
your local clients can learn out of band (alt-svc) that your local server
supports your new v2.

Of course, I still support adopting this document. :)

Cheers,

Ryan

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 11 Dec 2019 15:06:04 -0800

I support adoption.

Best,
Chris

On Wed, Dec 11, 2019, at 1:49 PM, Jana Iyengar wrote:
> We should be working on getting version negotiation done asap, since it 
> is an important extensibility mechanism for QUIC. Not having a 
> mechanism means that any work on a next version (even local 
> experiments) is effectively stymied, which increases the risk that this 
> extensibility mechanism becomes unusable. Not only should we adopt this 
> document, we should act towards shipping this soon after (or even at 
> the same time as) QUICv1 ships.
> 
> - jana
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Dec 2019 15:09:56 -0800

> Eh? That's a bit overbroad isn't it? If you want to locally experiment
> with a non-standardized QUIC v2, surely you can experiment with

Yeah, fair point about local experiments. I'll take that back.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 12 Dec 2019 11:59:44 +1100

> support for quick adoption.

Adopt.  I share the desire expressed by others to close on this relatively soon.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Dec 2019 10:18:35 +0900

> shipping this soon after (or even at the same time as) QUICv1 ships.

+1. I share the same view (modulo the "even local experiments" part, which
Ryan has correctly pointed out to be overbroad).

I'd also point out that downgrade prevention (which is defined in the
draft) is a must-have for any new version. As I commented in Singapore,
there would be some QUIC versions (e.g., token-based greasing) that cannot
rely on the downgrade prevention mechanism defined in this document. But
most of the new versions can.

Considering these aspects, it is my view that we should adopt this document.

-- 
Kazuho Oku

---

From: Ian Swett <[email-masked]>
Date: Wed, 11 Dec 2019 20:45:41 -0500

I support adoption, but I also don't fear transport downgrade in the way I
fear TLS downgrades, because I think they're different threat models, FWIW.

On Wed, Dec 11, 2019 at 8:18 PM Kazuho Oku <[email-masked]> wrote:

>> is an important extensibility mechanism for QUIC. Not having a mechanism
>> means that any work on a next version (even local experiments) is
>> effectively stymied, which increases the risk that this extensibility
>> mechanism becomes unusable. Not only should we adopt this document, we
>> should act towards shipping this soon after (or even at the same time as)
>> QUICv1 ships.
>>
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 07:20:03 +0000

I support the adoption of this work, should progress ASAP
Roni

> -----Original Message-----
> From: QUIC [mailto:[email-masked]] On Behalf Of Mark Nottingham
> Sent: Wednesday, December 11, 2019 11:36 PM
> To: IETF QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: draft-schinazi-quic-version-negotiation
>

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 12 Dec 2019 08:12:00 -0500

I support adoption of this document by the WG.

  - Dmitri.

---

From: Martin Duke <[email-masked]>
Date: Thu, 12 Dec 2019 08:55:40 -0800

I support adoption.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 12 Dec 2019 09:26:11 -0800

+1

....Roy

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Dec 2019 10:45:40 -0800

+1,

I’m slightly worried about fingerprinting of the clients supported
versions, but I guess it is not worse than other transport parameters.

I also note that the need to be able to read old Initial packets may affect
the choice of transport parameter encoding since this can now span many
versions, also versions that do not necessarily use TLS (#3294).

Mikkel

On 12 December 2019 at 18.26.47, Roy T. Fielding ([email-masked]) wrote:

+1

.....Roy

---

From: Roberto Peon <[email-masked]>
Date: Thu, 12 Dec 2019 19:23:35 +0000

Supported.
-=R

On 12/11/19, 1:36 PM, "QUIC on behalf of Mark Nottingham" <[email-masked] on behalf of [email-masked]> wrote:

    This is a Call for Adoption of the following document:
      https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dschinazi-2Dquic-2Dversion-2Dnegotiation-2D02&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=kHQ9ImTE44OQ2zCF3MKJMyU2h9m1st3pL6ua2zVPzns&s=eXvz0TldUFEfKAJwjxUkNtK_ytYXbHJ9gZrUwbjiWEo&e= 

    
    
    Regards,
    
    --
    Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=kHQ9ImTE44OQ2zCF3MKJMyU2h9m1st3pL6ua2zVPzns&s=KdY6JWcUJMTZkJDWTtQKYlnDyhc8KggF3viXYo4--Z0&e=

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 12 Dec 2019 22:56:41 -0800

I support adoption of this document.

Thanks,
Eric

> On Dec 12, 2019, at 11:23 AM, Roberto Peon <[email-masked]> wrote:
> 
> Supported.
> -=R
>

---

From: Marten Seemann <[email-masked]>
Date: Sat, 14 Dec 2019 08:03:53 +0400

+1 for adoption.

On Fri, Dec 13, 2019 at 10:56 Eric Kinnear <ekinnear=
[email-masked]> wrote:

> > On 12/11/19, 1:36 PM, "QUIC on behalf of Mark Nottingham" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >    Please state whether you support adoption of the document by the
> Working Group, and any additional information that you feel may be helpful.
> >
> >    Mark Nottingham
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=kHQ9ImTE44OQ2zCF3MKJMyU2h9m1st3pL6ua2zVPzns&s=KdY6JWcUJMTZkJDWTtQKYlnDyhc8KggF3viXYo4--Z0&e=
> >
> >
> >
>
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Dec 2019 18:17:41 +0000

It’s true that an experiment could define how to do version negotiation as part of the experiment, but the reality is that someone needs to build this part to have a robust deployment of more than one version at once.

From: QUIC <[email-masked]> On Behalf Of Ryan Hamilton
Sent: Wednesday, December 11, 2019 6:06 PM
To: Jana Iyengar <[email-masked]>
Cc: Lars Eggert <[email-masked]>; Mark Nottingham <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Call for Adoption: draft-schinazi-quic-version-negotiation

On Wed, Dec 11, 2019 at 1:50 PM Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
 Not having a mechanism means that any work on a next version (even local experiments) is effectively stymied,

Eh? That's a bit overbroad isn't it? If you want to locally experiment with a non-standardized QUIC v2, surely you can experiment with a non-standardized VN mechanism, right? Or you can even do no VN at all if your local clients can learn out of band (alt-svc) that your local server supports your new v2.

Cheers,

Ryan