Subject: I-D Action: draft-ietf-quic-v2-01.txt

From: [email-masked]
Date: Fri, 21 Jan 2022 16:12:50 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : QUIC Version 2
        Author          : Martin Duke
	Filename        : draft-ietf-quic-v2-01.txt
	Pages           : 15
	Date            : 2022-01-21

Abstract:
   This document specifies QUIC version 2, which is identical to QUIC
   version 1 except for some trivial details.  Its purpose is to combat
   various ossification vectors and exercise the version negotiation
   framework.  It also serves as a template for the minimum changes in
   any future version of QUIC.

   Note that "version 2" is an informal name for this proposal that
   indicates it is the second standards-track QUIC version.  The
   protocol specified here will receive a version number other than 2
   from IANA.

   Discussion of this work is encouraged to happen on the QUIC IETF
   mailing list [email-masked] or on the GitHub repository which contains
   the draft: https://github.com/quicwg/quic-v2.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-v2/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-quic-v2-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-v2-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Martin Duke <[email-masked]>
Date: Fri, 21 Jan 2022 16:22:21 -0800

All outstanding issues are resolved. The biggest practical change for
developers is the random version number, although many asked for the
narrative about how compatible negotiation works, which is now there.

In some sense, this is ready for WGLC, but we may want to wait for the VN
draft to catch up. David and I had to sort out which draft covered certain
areas, and in many ways they are tightly linked.

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 22 Jan 2022 11:05:26 +0900

Hello everybody,

The following concern just popped up in my mind:

Some people (in particular the press,...) may take version numbers very 
seriously. Reading "QUIC version 2", my guess is that there might be 
articles saying things such as "Quic already is at version 2" or "Quic 
version 1 is outdated, use version 2", and so on.

Everybody on this list (including me) of course understands that such 
stuff is completely wrong, and it's easy for people who want to figure 
out that it's wrong. Nevertheless, there are quite a few instances where 
version numbers have taken a life of their own.

The purpose of this mail is that everybody consider the risk of the 
above "misunderstandings". If we are fine with that risk, then let's go 
with "version 2". If we have some doubts, it would be easy to change the 
version number to something else, such as 1.1, or 0.99, or A.bc, or 
whatever.

Regards,   Martin.

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 22 Jan 2022 15:05:58 +0000

Hi Martins,

Wearing no hats.

> version number to something else, such as 1.1, or 0.99, or A.bc, or

Whatever moniker we chose, I think there will be some part of the
population that will be surprised and read something more into it than what
the specification is attempting to do or solve. Personally I think QUIC 1.1
would be a very bad name though.

I've lost count of the times I've seen a comment like "I've only just heard
about HTTP/2, and now there is an HTTP/3?".

This spec will help exercise our version negotiation mechanism and help
prevent stagnation and ossification. In some sense we are trying to build
an evergreen transport, to borrow a w3c term [1].  Perhaps people should
become accustomed to a new version of QUIC being released on a regular
cycle, so that implementer and operators build out the processes needed to
stay compatible and up-to-date.

Cheers
Lucas

[1] - https://www.w3.org/2001/tag/doc/evergreen-web/

---

From: Robin MARX <[email-masked]>
Date: Mon, 24 Jan 2022 18:52:27 +0100

Hello Martin,

As someone who had seen a lot of misinformation spread about HTTP/2
and actively tried to prevent the same happening for HTTP/3 and QUIC
by providing "correct" sources early on, I can sadly only agree with Lucas
here.

There will always be people who don't do any of the legwork required to
actually
understand what's happening and who take things at face value. This is why
even today we have articles claiming HTTP/3 doesn't retransmit lost data
because
it uses UDP under the hood... Switching to another naming scheme just to
appease
this group would probably not have the intended effect + make it more
obtuse for
the rest in the long run.

So I'd personally also advocate just calling it 2QUIC2Soon.

With best regards,
Robin

On Sat, 22 Jan 2022 at 16:06, Lucas Pardue <[email-masked]>
wrote:

> I've lost count of the times I've seen a comment like "I've only just
> heard about HTTP/2, and now there is an HTTP/3?".
>

-- 

dr. Robin Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media

*Cellphone *+32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Jan 2022 09:43:56 +0200

On 2022-1-22, at 17:05, Lucas Pardue <[email-masked]> wrote:
> Whatever moniker we chose, I think there will be some part of the population that will be surprised and read something more into it than what the specification is attempting to do or solve. Personally I think QUIC 1.1 would be a very bad name though.

"QUIC Version 1 Alternate"?

Lars