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

Lucas Pardue <> Sat, 22 January 2022 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7D913A1ED8; Sat, 22 Jan 2022 07:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W9Xchpq_UPgz; Sat, 22 Jan 2022 07:06:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3EAF3A1ED5; Sat, 22 Jan 2022 07:06:15 -0800 (PST)
Received: by with SMTP id l5so30883154edv.3; Sat, 22 Jan 2022 07:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4PAJtZeB34P9l4M1HUB/YpzHvWK0rqeVyrTFY8cjuFk=; b=PD+Oq1qts9CdEOWNTTrszVJnyfoPdW+1iOD3ej8Endu70sVN3hLHJH6qrPj37YtLOD lh6TWEpmxNueWYCMR2CVGd8flIMtxI1jQG4VbrNkz8tfv6C1dUu41YSimbT+2b3O8vDf Vq3lu2v3BAJvraD3pAODc5B0dvtci7Jg+1ncl2Qad6iS4jqM3KNiS2nG57P/VrnFwW75 QFv0YSwadU9tTaCvjJFdaCBh97wZm0JFC7vy4nA4Mt8S/2rut9aYp8wL8CJeMEZMYbR2 m0wz7Z9WRbRUzw4mgzLdSGsRq1uw70e1xScswwPsX9LVhMZLWer7bHCNQzabTPIloiCd 8M7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4PAJtZeB34P9l4M1HUB/YpzHvWK0rqeVyrTFY8cjuFk=; b=GsU3wyOCD4yRGpX4CiagLGb+otNmgLUtre6ZzHjxg0tteiRLVQHEqBc9j7sw8xUfvi d6sWbb9B76ms/xH2quLFufCJzyyKqnSoYklICZCMHEDIxUjf6CsXas8NxmlFAPyTndIh NGn0bBmGKZTZ1XOK1QfqndFzC/b7T+mX52E3U5RkTB1gEvqOk2gjyJVdONxQkXWa04gV s54I/UO9RN2eRu5ZDKhGHwxU0mT1iz2876Tx4tHrvs16dqNUx/IdMo6T+qhZboApzcfm rVALEPM52mYisvoJ7jzYExZhujMy7s/fm9XTEq+2LswCOZM2deQxhwKGuaJSr44U8hTD eX5g==
X-Gm-Message-State: AOAM532flyhX62DwcLMn6Az6CmizQ6pxUGIUkREnPTb+WnKlj579deP3 FN7oxIDFPCA6g3SHjkBbrDcMGisleX84N0R3l70=
X-Google-Smtp-Source: ABdhPJwBZDdwyjNLtE/n6NFsfhifjFpxXG5pSoKw0BLE7kJn5uEieXRwcTuqnOEwcupah5k1u8VTgqP7gmvhxFy+WuE=
X-Received: by 2002:a50:8ad0:: with SMTP id k16mr8311935edk.368.1642863972821; Sat, 22 Jan 2022 07:06:12 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Sat, 22 Jan 2022 15:05:58 +0000
Message-ID: <>
Subject: Re: I-D Action: draft-ietf-quic-v2-01.txt
To: "Martin J. Dürst" <>
Cc: Martin Duke <>, IETF QUIC WG <>,
Content-Type: multipart/alternative; boundary="00000000000083af3205d62d13b3"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Jan 2022 15:06:21 -0000

Hi Martins,

Wearing no hats.

On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, <> wrote:

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

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.


[1] -