Re: Rechartering QUIC for Post Version 1 Work

David Schinazi <> Tue, 26 January 2021 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 956003A10A7 for <>; Tue, 26 Jan 2021 13:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 n14uhHIbro-x for <>; Tue, 26 Jan 2021 13:53:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 176FC3A10B1 for <>; Tue, 26 Jan 2021 13:53:22 -0800 (PST)
Received: by with SMTP id q20so11252768pfu.8 for <>; Tue, 26 Jan 2021 13:53:22 -0800 (PST)
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; bh=ryFpz27MUxCm/QZiUob4IZgJ6+rwFn0KVe2ApsLmrOE=; b=amPVZIOSlJ7rKUBJSbY7Md8P7ryPb6+scXIQZp5LuczqBNa4ZEuC8Mk+BJucR4RyG3 G+Ub9Tq02pYazs8WRCBeD9Wsq+d2moPvR4EdWM6vMET0MvW+FIesgZnKZibOeTXTQqfo kmm/cuwLKKibgg0q9RZJCg/sfnURGZLyZKFSoYuuYSH16mLUFGl7/Lpfa0kIHvUfRI95 Rn7gLzyNzmIgMvEHYjT7NvLGmA2jR21WNkMmGE2hBfoliWZfC04Mttz8Fu7f7bFwcci6 48zs0lQ7W84swLxnn8GGOat7EhrRUVpqWKnhXKeeV8cqF1tpYQ6mPxsCBNL9GVK3nesf 3rTA==
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; bh=ryFpz27MUxCm/QZiUob4IZgJ6+rwFn0KVe2ApsLmrOE=; b=CAI508NxLd4b3Ea81D33l48I53i9bfxPg2b8xXdT97VEu2nRnGNrCkDuOTaDpSgWht A0+/zG0VPr4SPhV95wPKGY1LDgXC41oN8Z6Ol0r0bwqXLycN4GOyXj0c93EEi0Cxfy9d 8oYgopR+a9fi3zyS/dmt3y6jdEdUZGe8vsEwtSu6X3OTkwbqgbnfqNiilTj3p4O23cZQ liaELvomvKSWSwl912reYUCXJklcCMdjZRuMhzOVA0E+KAXbfSthQ8po/S0gW0q8f3ie VuHWGYFIFLKc2E0i33TMUshxo87+ishtFhbhE4e9Zp9IH4v47W6+YiI8tSWVVPZBhcG3 yOpQ==
X-Gm-Message-State: AOAM533QYep4SDDBjYgrgYmyPf3nMIuoNfNnlQVLZLsBfFGrklzS2zBq FHg0PIr/I4V1Iopvi6ilsZfHYRbBXkv0mXUG8FIEapLC9/0=
X-Google-Smtp-Source: ABdhPJx1T+fWL2DBqRQSiZjXQn8/XYPY9GJs0H/IHhSO7YltOdE2Cureyae31xyL6f//zK4ySZRYY6xc+EN/HIRrmP4=
X-Received: by 2002:a62:1558:0:b029:1b7:fbf9:25f0 with SMTP id 85-20020a6215580000b02901b7fbf925f0mr7195795pfv.79.1611698001884; Tue, 26 Jan 2021 13:53:21 -0800 (PST)
MIME-Version: 1.0
References: <> <20210126170048.GB364092@okhta> <> <20210126170932.GC364092@okhta> <> <20210126184815.GD364092@okhta> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 26 Jan 2021 13:53:10 -0800
Message-ID: <>
Subject: Re: Rechartering QUIC for Post Version 1 Work
Content-Type: multipart/alternative; boundary="000000000000e338d305b9d4aecd"
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: Tue, 26 Jan 2021 21:53:30 -0000

I'm supportive of the overall direction of this rechartering, with some
concerns though:

1) multipath is not mentioned in this charter - based on the conversations
we've had over the past months, I think we should be explicit about whether
multipath is in or out of scope

2) +1 to Ian and Dmitri's comments about mentioning current examples in a
way that seems to preclude other extensions, we could remove the examples
to help clarify

3) I was surprised by "Extensions intended for Standards Track need to have
general applicability to multiple application protocols." and I don't think
our charter should preclude these. We shouldn't ban standard-track
protocols that require a QUIC extension to function properly. Perhaps
another way we could phrase this would be to say that "The QUIC WG is only
chartered to work on extensions that have general applicability to multiple
application protocols. Extensions that are specific to an application
protocol should be defined in the WG responsible for that protocol, in
consultation with the QUIC WG." -- without stating anything about Standards

4) It seems off to me to simultaneously declare HTTP/3 logging in-scope and
HTTP/3 out-of-scope. I think qlog is useful, but if we want to use it
outside of the QUIC transport protocol then maybe it should live in another

5) "Maintenance and evolution of the QUIC base specifications" isn't very
clear to me - does that mean that working on future versions of QUIC is in
or out of scope?


On Tue, Jan 26, 2021 at 1:00 PM Ian Swett <ianswett=> wrote:

> In the past, I felt there was quite a bit of resistance to accepting new
> documents not explicitly listed in the charter, which makes me share some
> of Dmitri's concerns.
> Mentioning qlog specifically made me a bit nervous, because the other
> examples were worded broadly enough that they could encompass different
> drafts if needed.
> Minus that concern, LGTM.
> On Tue, Jan 26, 2021 at 1:48 PM Dmitri Tikhonov <
>> wrote:
>> OK, hopefully that's how it works out in the end.
>> Thanks,
>>   - Dmitri.
>> On Tue, Jan 26, 2021 at 05:27:11PM +0000, Lucas Pardue wrote:
>> > Waiting for the new documents to get proposed and adopted, as a new
>> > precedent for future work in this area doesn't IMO help much. We already
>> > have precedents, which I trust the WG to be capable of applying without
>> > being too literal.
>> >
>> > Cheers,
>> > Lucas