Rechartering QUIC for Post Version 1 Work

Lucas Pardue <> Tue, 26 January 2021 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FE2F3A0A4C; Tue, 26 Jan 2021 08:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Status: No, score=0.052 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 15IsA7GLrG6W; Tue, 26 Jan 2021 08:45:36 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 556F53A0A3B; Tue, 26 Jan 2021 08:45:36 -0800 (PST)
Received: by with SMTP id r12so23854871ejb.9; Tue, 26 Jan 2021 08:45:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=8aP36uBhTVr4SjAmFWxtPLXr6uZBj6sKpMRQxTu4qg4=; b=fubnPkkZAdNnN5KWRdSMBN5O4WRqaXsTjdelNCZ/HyiHTEr4odbdL9IS+yrmHsfueU CvfXqXNGY7+HMG5U/AQlDGBQJAXxiKqKqVa+x9qiTgtGTN828w06Ef1UTsHgP+HiXYTL UqzGZvFZm40D1LFTgEcu4GvWmFaUY1nfPE7sOcZ/gvFODzIrxRGBBAbvp1tX0mEGdrXJ /9bjwjqFlgYpdHxBOSj5Mypq4XwtKRZ//W/A/4MizBzfygyTd8T06ItZFf0JtSVHEfBb /ARhxsipHW8M9r3k8TYW0VHfpmVZzRAnLWL2aPu8evD58U062f+1QGTm8+L9720Oy043 Dwvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=8aP36uBhTVr4SjAmFWxtPLXr6uZBj6sKpMRQxTu4qg4=; b=X73+kigZnvDe4Dz7Z4EW0U9u+PGogFM6FuntsBCcMe7twswnmCmDbg+xuhhuM6CNoH jxh9g3S061lBH2zMf0l73M8QYTE+US1SjEn2epMVZpXv3q45j0s6TI6fuPtwPC0lTWaP qkfNm0Sgtk8i0nNx0eWwPf+SxQTnYNpKVOCQ14LPHwpCc6WlehpvCHY6DewnVrW4u2yB gAR6pY1e3ytQVo5kKlbjxseM/xIjBXzAJrqqaAKAAIrnTf8QfJ0JITcVSLWIt78w+Rv1 IJQmLSHwJlFiE62N0wgMDUDToAuPzPdruP8DhbRdct4WxGq7N4vE6B5tch5C8myuMbNd DRrQ==
X-Gm-Message-State: AOAM531jNjV5n4uvX69pgjleJC8SOe13OBUvmYI5D8fSDmYZFrFb/2+0 tlYkixWn6j34dfC4k4THkjzTSRND/CtTqYa95YhvFKq4nrw=
X-Google-Smtp-Source: ABdhPJzYfWNILJjwlf+BBJIyp16Zdptd27lXzFT81uyTOC4ixdWdQTGC1vXDrxAkJMVkP7ca+ztUrSw5YcES6aSfIBw=
X-Received: by 2002:a17:906:607:: with SMTP id s7mr4016370ejb.301.1611679534091; Tue, 26 Jan 2021 08:45:34 -0800 (PST)
MIME-Version: 1.0
From: Lucas Pardue <>
Date: Tue, 26 Jan 2021 16:45:23 +0000
Message-ID: <>
Subject: Rechartering QUIC for Post Version 1 Work
To: QUIC WG <>
Cc: WG Chairs <>,
Content-Type: multipart/alternative; boundary="0000000000001f13e405b9d06219"
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 16:45:39 -0000


As you will be aware, the base-draft documents comprising QUIC version 1
are making steady progress through the IESG review process. Building from
that, we expect the Applicability and Manageability drafts to be stable and
fresh, and ready for WG last call soon. Furthermore, we also expect some
effort to get directed towards the three adopted extensions: Load
Balancers, Version Negotiation, and Datagram.

With the WG nearing the delivery of its first major milestones, we're in a
bit of a natural transition period. Now is a good time to look again at the
WG charter and consider where else we might choose to direct focus. We
anticipate QUIC version 1 to generate interest, deployment experience, and
new ideas for extensions. The Chairs and responsible AD would like to
position the QUIC WG as the focal point for any QUIC-related work in the
IETF, especially with respect to protocol maintenance and evolution. We
believe a recharter will make it clear what is in scope for the WG to work
on next. Being a focal point, however, does not mean that *all*
QUIC-related work should be done in this WG. For example, new application
protocol mappings can likely be successfully done in the appropriate ART WG
with little interaction required.

As you may have noticed, draft-iyengar-quic-delayed-ack,
draft-marx-qlog-event-definitions-quic-h3, and
draft-thomson-quic-bit-grease have,  based on interest to date, been marked
as candidates for adoption by the WG. However, our current charter prevents
us from formally adopting such work. The intention of the new charter is,
among other things, to allow the WG to formally adopt and develop these

The Chairs have worked with the responsible AD and current document editors
to prepare a new draft charter for the QUIC WG post version 1. We invite
the WG to review this charter at
and file issues or suggestions on GitHub. For convenience, the text as of
commit 9471611 is reflected below:

QUIC Working Group Charter

The QUIC WG originated the specifications describing version 1 of QUIC, a
UDP-based, stream-multiplexing, encrypted transport protocol.

The WG acts as the focal point for any QUIC-related work in the IETF. It is
chartered to pursue work in the areas detailed below.

The first area of work is maintenance and evolution of the existing QUIC


   Maintenance and evolution of the QUIC base specifications that describe
   its invariants, core transport mechanisms, security and privacy, loss
   detection and recovery, congestion control, version and extension
   negotiation, etc. This includes the specification of new versions of QUIC,
   if necessary.

   Maintenance and evolution of the specifications of QUIC extensions.

Maintenance and evolution work needs to be strongly motivated by existing
or ongoing production deployments of QUIC at scale, and needs to carefully
consider its impact on the diverse set of applications that have adopted
QUIC as a transport.

The second area of work is supporting the deployability of QUIC, which
includes specifications and documents, such as it applicability and
manageability statements, improved operation with load balancers, the
specification of a logging format and schemas for QUIC and HTTP/3 endpoints
(qlog), etc.

The third area of work is the specification of new extensions to QUIC.
Extensions intended for Standards Track need to have general applicability
to multiple application protocols. The WG may also decide to publish
extensions as Informational or Experimental documents, e.g., to allow
vendors to publicly document deployed proprietary extensions or to enable
wider experimentation with new protocol features.

Specifications describing how new or existing application protocols use the
QUIC transport layer do not need to be specified in the QUIC WG. The QUIC
WG will collaborate with other groups that define such application
protocols that intend to use QUIC. New mappings might require QUIC
extensions and it may be efficient to define these alongside the mapping
specifications. Groups that define application protocols using QUIC, or
extensions to QUIC in support of those protocols, are requested to consult
with the QUIC WG and seek review of proposals. This is intended to reduce
the possibility of duplicate work and/or conflicts with other extensions.

The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the QPACK
header compression scheme. These specifications are now maintained in the

Defining new congestion control schemes is explicitly out of scope for the
WG. However, new QUIC extensions that support development and
experimentation with new congestion control schemes may fall under the
third work area.
Lars, Lucas and Matt
QUIC WG Chairs