Benjamin Kaduk's No Objection on charter-ietf-quic-02-01: (with COMMENT)

Benjamin Kaduk via Datatracker <> Thu, 25 February 2021 14:40 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3120C3A1AC8; Thu, 25 Feb 2021 06:40:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <>
To: "The IESG" <>
Subject: Benjamin Kaduk's No Objection on charter-ietf-quic-02-01: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.26.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <>
Message-ID: <>
Date: Thu, 25 Feb 2021 06:40:59 -0800
Archived-At: <>
X-Mailman-Version: 2.1.29
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, 25 Feb 2021 14:40:59 -0000

Benjamin Kaduk has entered the following ballot position for
charter-ietf-quic-02-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:


      * 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.

nit: the list structure is not parallel -- "security and privacy" are abstract/generic concepts
but the rest of the list are properties of the QUIC base specification.  I think adding "properties"
would help.

      WG adoption of work items falling into this first area of 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.

While I expect a diverse set of such applications in the near future, I'm not entirely
sure how accurate the statement is right now.  The WG produced HTTP/3, of course, but
in terms of items adopted by IETF WGs I see only DNS and MASQUE; there are many
other individual drafts but I don't know if that qualifies for "applications that have adopted"

  Specifications describing how new or existing application protocols use the
  QUIC transport layer need not be specified in the QUIC WG, although they can.
  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.

nit: this seems to be the first time we talk about  (application protocol) "mappings"
(onto QUIC), so a couple more words of introduction might be in order.