Re: Rechartering QUIC for Post Version 1 Work

Spencer Dawkins at IETF <> Fri, 29 January 2021 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DD7C3A1801 for <>; Thu, 28 Jan 2021 16:04:14 -0800 (PST)
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 IPQ46f9vWch7 for <>; Thu, 28 Jan 2021 16:04:11 -0800 (PST)
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 4E3CB3A1800 for <>; Thu, 28 Jan 2021 16:04:11 -0800 (PST)
Received: by with SMTP id x78so7202163ybe.11 for <>; Thu, 28 Jan 2021 16:04:11 -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 :cc; bh=7typdl0LkbnJ2SiejueX+EkMLeu3b66/9YMJo9UL/ak=; b=t368QogG06RC+2OoCEFXO9DvQYN4IF5lJQkIcO0XablzjcY0GvljMV7CX9ICuZkbza YbN6X7Jh0THmgFCcIhFfytl0N8uNbS5Wuty6YOJ5Zh/b9/gT9/0B8VbvkWbIzh8MZsH6 ByBNcKbz4N/LOGoZEyAIBs906GZSUHnchw7XhLpDe9BQWsTaZpNfoucWHi03ckqbbTVZ +5lJYIvCfj4qWfBxAudiz5lEQWjDVLDYdhTmgLlD4cvMJcuuDOhsT5H5/oj9n0Yog3BE bCr2FLvksHgJCsmtdVgpRdYnfdgVl9iDV26K3Kz9Q1FsT0o27GtjMPnjpiozZ47lUoiw bwmg==
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=7typdl0LkbnJ2SiejueX+EkMLeu3b66/9YMJo9UL/ak=; b=gZzRX2nd9WGi91vMHYWH4GP7jtEqwOrtErQbDKPSGiN0bJxGGBf9HmVedqRwTNyGSa 9cdrh102UMu4fE3ny+g7VzhItd/nzzKSHkxBGhZlMXed/k8aDGfAJQd/g9qP+v5eLdYD 7D8Hypg8yT4NagBumAQ3fXVJPb59d8UN7a+3zMHvkQ53Eb8d9QwEoUP7ieFUfQigaJvL XHDi+BNFzj5YndEDmETwI3o71RB26sr7gBKULFLTawTaJZqibJGkjxDLyPI9+11QrNjs Q2DY8V2ZjdLGkjhBBFpzxQimJ2/u3JJgA6tgH1A4AjRwds8ni7kSVIPG63T8Y9knY8oQ yRBA==
X-Gm-Message-State: AOAM532b+ixbvcUlWOl53Lt52UYJ+oyKEOgrzADFL0wLM+d+rab1ZaaR gRTYcWHgvCng1ur2kxoD0WO/OTjLAFynUeX4fx0=
X-Google-Smtp-Source: ABdhPJwOW4wj4EaETTnDnL2Qjqz9egfrqiiAWgQPJBOKm0HYpXBp2SSOLOK/jgzpIDwCY4G8vfF6HKq+1LFLwdpVqlo=
X-Received: by 2002:a25:e84:: with SMTP id 126mr2389563ybo.297.1611878650504; Thu, 28 Jan 2021 16:04:10 -0800 (PST)
MIME-Version: 1.0
References: <> <20210126170048.GB364092@okhta> <> <20210126170932.GC364092@okhta> <> <20210126184815.GD364092@okhta> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 28 Jan 2021 18:03:44 -0600
Message-ID: <>
Subject: Re: Rechartering QUIC for Post Version 1 Work
To: Roberto Peon <>
Cc: Lars Eggert <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000006269be05b9febe54"
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: Fri, 29 Jan 2021 00:04:14 -0000

I left a comment on the PR about a broader issue that might be useful for
me to bring to the mailing list.

Please see below.



On Thu, Jan 28, 2021 at 1:30 PM Roberto Peon <>

> Hey Lars!
> What would your answer be on where partially-reliable HTTP work would be
> homed (where it mostly requires QUIC changes, and may require some HTTP
> changes)?
> -=R
> ´╗┐On 1/28/21, 5:09 AM, "QUIC on behalf of Lars Eggert" <
> on behalf of> wrote:
>     Hi,
>     I've prepared in an
> attempt to address the comments received on the charter update.
>     - remove "if necessary" to make it more clear that the WG may do a new
> version of QUIC
>     - talk more generally about "a logging format" and tweak the wording
> for the second work area, to make it more clear that the listed things are
> non-exclusive examples of work items
>     - take David Schinazi's advice and remove the text about standards
> track
>     Please let me know if this is clearer, and should be merged into the
> text for the continuation of the discussion.

I THINK I'm reading this as the QUIC working group requesting groups that
realize that their applications require QUIC extensions to consult with the
QUIC working group, and seek review. Is that the intention?

I'd expect that to be stronger, simply because (based on experiences with
protocols like SIP) popular protocols tend to collect applications from
people who don't understand the underlying protocol as well as the people
who are responsible for the underlying protocol. If you can say "but you
can accomplish the same thing by using QUIC as it is now", sooner rather
than later, that would probably make everyone's lives simpler.

In addition to just being nice to other people, I'd kind of expect that
review will happen eventually for any QUIC extension that makes it to
Publication Requested status in its own working group and goes for IETF
Last Call, whether the review happens because a TSVART reviewer is
assigned, or because some QUIC expert saw the Last Call announcement and
became curious. But that's about as late as Late Surprises ever get.

So, maybe that could say something like "are encouraged to consult with the
QUIC WG and obtain early review of proposals, thereby avoiding late
Do the right thing, of course.