Re: Consensus on Deploying QUIC v1 with HTTP/3

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 06 May 2021 19:32 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15903A2DDE for <quic@ietfa.amsl.com>; Thu, 6 May 2021 12:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHtNl3lE3qBS for <quic@ietfa.amsl.com>; Thu, 6 May 2021 12:32:16 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4883A2DDC for <quic@ietf.org>; Thu, 6 May 2021 12:32:15 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id y2so8826449ybq.13 for <quic@ietf.org>; Thu, 06 May 2021 12:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CALGR9obE-Dbm5Rwmr=h_34vaps1pcv36Jg0MTS_o0mZHEF1FvA@mail.gmail.com> <6740dcaa-3c43-faf2-826e-1cb3bb113aff@gmx.de> <CADdTf+gKZwcZD12he2YaGpWpOePZp_EB4J0QoXL6ozfx0BgJDg@mail.gmail.com> <CADdTf+h=iEjJ6k6FmDBOhYY7iLTjyDPWBejdU+ocyUCiGA09yQ@mail.gmail.com> <6b0ce1c8-bbe4-f8cd-b9c9-8e2eb378bd6d@gmx.de> <CALGR9oag_Q-yj2jVvqrKfswAJn4FiNQ_A4H20_dHxmrrCPV80A@mail.gmail.com> <CAKKJt-cq=LGgDnkQYDLxDtSfqSv5aUE82XQsQ57YNrc3Q6R-qg@mail.gmail.com> <CALGR9oZmOcq2Re2QpU9NRYPegRRBMpbw7YhZs1xGsYemhCqymw@mail.gmail.com>
In-Reply-To: <CALGR9oZmOcq2Re2QpU9NRYPegRRBMpbw7YhZs1xGsYemhCqymw@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 6 May 2021 14:31:48 -0500
Message-ID: <CAKKJt-d8-9YoWkb7U3H6oVuzQJo6VOt2CCyZArWmYfxxCvabpw@mail.gmail.com>
Subject: Re: Consensus on Deploying QUIC v1 with HTTP/3
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005187e905c1ae5e59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/shMTZyLa7ZiYfX0PSoQp7IQIrjY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <lucaspardue.24.7@gmail.com>
wrote:

> Hi Spencer,
>
>
> On Thu, May 6, 2021 at 4:18 PM Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>>
>> The QUIC working group could reasonably do a short Applicability
>> Statement (https://datatracker.ietf.org/doc/html/rfc
>> <https://datatracker.ietf.org/doc/html/rfc2026#section-3.2>
>> 2026#section-3.2
>> <https://datatracker.ietf.org/doc/html/rfc2026#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 <https://datatracker.ietf.org/doc/html/rfc2026#section-3.3>
>>    3.3 <https://datatracker.ietf.org/doc/html/rfc2026#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
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#ref-QUIC-INVARIANTS>].

   To refer to QUIC version 1, cite this document.  References to the
   limited set of version-independent properties of QUIC can cite
   [QUIC-INVARIANTS
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#ref-QUIC-INVARIANTS>].


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.

Best,

Spencer


> Cheers
> Lucas
>
>