Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

Ryan Hamilton <> Wed, 06 November 2019 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5C1A120154 for <>; Tue, 5 Nov 2019 17:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 xYUNkf4K7zOw for <>; Tue, 5 Nov 2019 17:36:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2ED42120041 for <>; Tue, 5 Nov 2019 17:35:58 -0800 (PST)
Received: by with SMTP id t26so1506438wmi.4 for <>; Tue, 05 Nov 2019 17:35:58 -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=anwoqdWzFr0SVd2T9Nn/JPq2JPCLjRhHa2QbGe0BP+M=; b=EWcWTfoFa1h1v6Y6dZpQddw8OEEXD6KRigmgB7WB0MKKNekiPUtJjRr4nc0nCDTlrr cpAorHDPWTJ3oItijLIcjeh0/k44Mc2RIn9qFRO7+/NHYqpl9Iv3DGX/DPcq/kB4N2pr /5oggIz/+m4Xc5F8nksDyJVmo56PAVkFBfhD/TtsHoo9Hyaez+sO6wzOY2CJZvmTxT0C zUFGeLersr/OURTSw18KZjRKYgmsgnO3GEV6XEL07bynoQbBUDFNRQLXp5x7d6oqozhN H+Je6Q5u59qRbsZMZueh4c1ETSGKmUZO8yCaVm3k7nz3xQfbFoe3sJn2okBUC/k4lMyr q9cg==
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=anwoqdWzFr0SVd2T9Nn/JPq2JPCLjRhHa2QbGe0BP+M=; b=S5issJvGkPfqTGYfYIffV2qbH3wRl5rrSgzjWkyF4EvI4KQM+vdPpKmpT5+j73DSJm XGjH9MQFYKCAJxUTK9fRnFas6ffBiNOYrdwg+SBaRseq6BANIFbwnmRT4dB9p4dxcXXz t8dSXnEj32MuMcIjccSrzIMPRLRquk1KGTb2+SNIH0v/auXPtWfRNDfXH4zwH9aXv1ps fxVMz6HJSX08om+uCzLAytp8Huaq7tQ94zu1J5CQRyI93/5Nt+Ns4aeI9bzvqbCGl3vH wCXHtZpPPOuadrPjegJWGyidZt05pK7N36MJbbb/X+EEws7Pnx7CtFJKOAGcdmRg4QVH OEqg==
X-Gm-Message-State: APjAAAU1tWuD2nej+XsH9sLIlU15LLxyiuC8vq0222Ef1SBkMdSoCz0s eDnTFl5QZed6ideK78VaV5GeCohT6ZbMqPunWtSj7bq77bg=
X-Google-Smtp-Source: APXvYqyyTtMHHkfagotXHw8ha5UTD7pbZ2Q2LIvobCU/Qk0lElSscdwQS/NiNwCN4eiuDhoC6edsT08oGdPetInEjCQ=
X-Received: by 2002:a05:600c:12:: with SMTP id g18mr166538wmc.44.1573004156068; Tue, 05 Nov 2019 17:35:56 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ryan Hamilton <>
Date: Tue, 5 Nov 2019 17:35:43 -0800
Message-ID: <>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
To: Mark Nottingham <>
Cc: IETF QUIC WG <>, Lars Eggert <>
Content-Type: multipart/alternative; boundary="000000000000f443460596a39145"
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: Wed, 06 Nov 2019 01:36:48 -0000

For QPACK and Recovery, this sounds great to me. For  HTTP/3, as I
understand it, we still have a design team working on priorities. Can you
clarify how this effort is affected by the late stage process? (Or is is
basically unaffected as it is an open issue?)

On Tue, Nov 5, 2019 at 5:02 PM Mark Nottingham <> wrote:

> Previously, we've moved to the 'late-stage process' documented at [1] for
> the Transport and TLS drafts. The chairs and editors now feel that it's
> time to move the Recovery, HTTP/3, and QPACK drafts to that process as well.
> As before, this is because we're getting to a stage we feel the documents
> would benefit from slower and slightly more formal process, so that the
> rate of change is not so high, changes that do occur are well-vetted, and
> the documents get closer to reflecting consensus in the working group.
> If we do this, we're saying that we have gained consensus on what remains
> in these documents, excepting their outstanding issues. As per our charter:
> """
> Note that consensus is required both for changes to the current protocol
> mechanisms and retention of current mechanisms. In particular, because
> something is in the initial document set does not imply that there is
> consensus around the feature or around how it is specified.
> """
> That doesn't mean that new issues can't be raised against those drafts.
> However, new issues against them will be judged for whether they contain
> new information (in particular, security or interoperability impact), a
> clear technical defect, or have significant (in the judgement of the
> chairs) support for further discussion. If the issue isn't well-described
> or atomic, it may be closed with a request to refactor, or refactored for
> you.
> Again, this does not affect editorial issues.
> Practically speaking, it means that new issues will be triaged by the
> Chairs -- not the editors (although they can still "claim" purely editorial
> issues) -- and those that don't meet the criteria above will be closed.
> Those that do will be labeled (again, by the Chairs only) as `design`.
> It also means that all of the closed `design` issues against these drafts
> will be marked as `has-consensus`. Additionally, the `quicv2` issues
> against them will be closed and marked `has-consensus`.
> The issues that will be labeled `has-consensus` (and closed, if still
> open) are listed here:
> We believe that all of these issues have been discussed and the group has
> formed consensus on them; this only formalises that.
> If you have concerns or questions, please discuss them on-list; barring
> pushback, we'll adopt this on 15-Nov-2019.
> Cheers,
> 1.
> --
> Mark and Lars, QUIC WG Chairs