Re: Consensus on Deploying QUIC v1 with HTTP/3

Spencer Dawkins at IETF <> Thu, 06 May 2021 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A15903A2DDE for <>; Thu, 6 May 2021 12:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_FROM=0.001, HTML_MESSAGE=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 qHtNl3lE3qBS for <>; Thu, 6 May 2021 12:32:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B4883A2DDC for <>; Thu, 6 May 2021 12:32:15 -0700 (PDT)
Received: by with SMTP id y2so8826449ybq.13 for <>; Thu, 06 May 2021 12:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H89kZwbFNXGlIx8kW22EWkNyEAecncoAbmyOYmJiII0=; b=fM9wid7pubGBQNa0Qz82IZd3xE8ZRVXynikh54LF/gD8GVoiLgL6YzvprP8VZbiWwG E32QPWr9TNGv25md2b1ktB7XvFaGG1rWmqQKlZsRmmYUO2LFJ4RD1Gf0t84Xwk63YW0X +YO/ZSWGKZN8RsAtCn5HNSiZBFgTe1fBIcx8ewAIwtonIbh3zG9qFdZXXGvO91JU/Fy9 HEC1W3iC+fcEIHZkn9KFDGOcKKZtKSXjuLOqEprobKxCP7xK8KbrBtGFZlXTw8H8FMIQ 1TLnT3eomF8tlq1bGbmhr+sWFnhAaCScK3SyVcTGuGyirec7sjNZhmH5HF2+cljIfxDw /5zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H89kZwbFNXGlIx8kW22EWkNyEAecncoAbmyOYmJiII0=; b=rtl0lgflYFIepumVLHtNrEBMyOFHVuWyLGjMpkxIii8oMPINZvC64NNlqBHxLldfYA jRcji/lokKTZ808AQa8uF54YTPs+0TkyaKsy5rasiRwlMvpnB8KWecp6+oASCqGGqynm QEfgBKIZtuna+DC64LdReNXreBrZan2wHEcp36hXWbTexWfg+6BcWsvxcA+ApYWYOwTC Oc15wqpE/lTMOKeWIqiPnyrhiPyEsEqP1SkLfGrCpkkZHXVt0ULxi528vbuOfmHhRW4R lQvbeUQ22G87sOcWqwxppM7Z43J7F+25eiB2lHHvjwy/TIIH7KA80oDWM64airl7sp6/ Zd+g==
X-Gm-Message-State: AOAM530j5+o3WCKKpf8HUbWJEuVsnr+yab+zDpCCrFjmcbv1qHAB6Wx1 vx7an0CPXIKlJ4kelh63H7jduEEHHa6hv3FtPA4=
X-Google-Smtp-Source: ABdhPJwf9umaYYigeb66noCk2CE+RzjAdR93Hx2A6Fq2n6dBKsZNI2F1nHf+1JyZlqiahAUFbaqrrtcasYW6euM0wls=
X-Received: by 2002:a25:11c6:: with SMTP id 189mr8234628ybr.154.1620329534423; Thu, 06 May 2021 12:32:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 6 May 2021 14:31:48 -0500
Message-ID: <>
Subject: Re: Consensus on Deploying QUIC v1 with HTTP/3
To: Lucas Pardue <>
Cc: QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000005187e905c1ae5e59"
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: Thu, 06 May 2021 19:32:21 -0000

Hi, Lucas,

On Thu, May 6, 2021 at 11:06 AM Lucas Pardue <>

> Hi Spencer,
> On Thu, May 6, 2021 at 4:18 PM Spencer Dawkins at IETF <
>> wrote:
>> The QUIC working group could reasonably do a short Applicability
>> Statement (
>> <>
>> 2026#section-3.2
>> <>) that (as
>> part of the RFC 2026 description)
>>    An AS identifies the relevant TSs and the specific way in which they
>>    are to be combined, and may also specify particular values or ranges
>>    of TS parameters or subfunctions of a TS protocol that must be
>>    implemented.  An AS also specifies the circumstances in which the use
>>    of a particular TS is required, recommended, or elective (see section <>
>>    3.3 <>).
>> And THEN, we could just refer to one specification that explained what we
>> mean when we say "QUICv1", or "core QUIC", or whatever we want to call it,
>> and everyone would know what we mean, without having to guess. This would
>> be especially helpful for participants in other SDOs, but not only for
>> them.
>> I'm not sure whether the QUIC community would ever advance QUICv1 to full
>> Internet Standard, when it would become eligible for a STD  designation
>> that could include the relevant RFCs, but even if you do, that's probably
>> years in the future (and a lot of successful IETF protocols don't advance
>> beyond Proposed Standard).
>> If that was the right thing to do, I'd be happy to knock out a -00.
>> Please advise.
> The document draft-ietf-quic-transport contains in the first paragraph of
> Section 1:
> >   QUIC is a secure general-purpose transport protocol.  This document
> >   defines version 1 of QUIC, which conforms to the version-independent
> >   properties of QUIC defined in [QUIC-INVARIANTS].
> Subsequent paragraphs go on to explain how -tls and -recovery relate to
> the -transport document.

Understood (and I had seen that text previously). So, that's a fine start.

> That seems to cover your goal of pointing people to a single document
> explaining the relationships between documents. But if I'm overlooking
> something please say.

I'd ask about these points:

draft-ietf-quic-transport is (checks -34) over 180 pages long. This
material is at the beginning of the Introduction (that's good), but it's a
tiny bit less clear how someone who's not familiar with the QUIC document
suite knows to start there (yes, having QUICv1 published as RFCs at least
makes that a bit more obvious on the documents page, at least at first).

At the bottom of Section 1.1, I find this text,

   This document defines QUIC version 1, which conforms to the protocol
   invariants in [QUIC-INVARIANTS

   To refer to QUIC version 1, cite this document.  References to the
   limited set of version-independent properties of QUIC can cite

but that's following the description of the structure of
draft-ietf-quic-transport. Maybe just moving these paragraphs to Section 1
would be useful?

I note that people who understand QUIC much better than I do had to ask
what "the QUIC RFCs" were in this thread, so I was hoping that might be an
indication that things could be a bit clearer for us all! :-)

Do The Right Thing, of course.



> Cheers
> Lucas