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

Mark Nottingham <> Mon, 11 November 2019 01:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2965F1200F4 for <>; Sun, 10 Nov 2019 17:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=zgCDn3Ej; dkim=pass (2048-bit key) header.b=yydV22Rv
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D-M9YWX2TMce for <>; Sun, 10 Nov 2019 17:01:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F9041200E5 for <>; Sun, 10 Nov 2019 17:01:31 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6373D21B10; Sun, 10 Nov 2019 20:01:30 -0500 (EST)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Sun, 10 Nov 2019 20:01:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=i b39KCe29g0ywekDhcgk9O/xVX9Anb2/kRrv3vZEIMI=; b=zgCDn3EjdEom9nF1L yNm1VfLJ/GDREa4l+nq0NDQpchuHiV5S6Ktvavt1rjnxubOg7GV4phVs4K2Cqzw1 t1kiclg9/OqxP+5uwfYodtrJ46Iwq7fAdbnnzqNvlPXAY1eONXHTxPGCNDJ+jSxX bSa1p9e98699AbWspNO+ihc3GHoMRaiDFY4GZ4vl9ZXAMIEwKHuib3nUG2igaUNL jTesDyFXXJLXfs4dJNajGgUXCJB/Tj/791pdoFDEyvlr2+flay+XRmXJgBhqJuCm 3kayeWIbKeuk5g2zi3NZyTb3rWqKsX3YhOC0ng5Q/XD+W022Al1MpCAzy6EJ/4i+ rwCfw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ib39KCe29g0ywekDhcgk9O/xVX9Anb2/kRrv3vZEI MI=; b=yydV22RvGBzgWy878h5/30ESGiHQBqaKsr+XxQS8b1Yy7KEE4qwnfVKp+ mtt4zEIVdhk6rAKgDwRdmVOWUeTnPIQdHyNVrrJ4ol/hen7MTH70z8uOLVWjmvgv KPeKbeSyFMnQFP5Ly1aLwWiI5s30FN7vohn+b0rZ0lwDmWi9O7QmZH5yC+I6l6oi rQb8FXUIofrYoN6x3Jd9STpaD2Y/uTwLCTdxGx/QBKCv82ceKkg9egzyLf/o5ZlI CVhpzCuJeBLi1fxPI6KHZ8wpN9voQLvOSaqPcpU/+ds9jx//EMpneB7IQeyG2oR0 dc1rsQdknHgXG4Dwq0EpO+6b5UI6Q==
X-ME-Sender: <xms:6bLIXU8bX3AZu9T2gaXyGreI6M26ygeQ38TvV8M4A1HnEKW_OQgmbg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddviedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh ephhhtthhpfegrnhguqhhprggtkhgurhgrfhhtshhtohhthhgrthhprhhotggvshhsrghs figvlhhlrdgrshdpghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepuddule drudejrdduheekrddvhedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:6bLIXY3_sxOdyn7CUIufjlrQzCqPyqVD-RZMs_2B0yzWjcumHh3juA> <xmx:6bLIXWLw7WSC_HSMgHLXEiATkaqdstoOty3mde6rEPbRR6zw-lejbg> <xmx:6bLIXZFZTZ-tjoa2qRa7ZdXUVKG7B_FRNRRihon0yN-KRgTjbjog3g> <xmx:6rLIXSoj5ujSx5w2DFpRUnSTxa5eJs8iZhnJu7WiwAzSet7Wmf3VoA>
Received: from (unknown []) by (Postfix) with ESMTPA id E2C87306005E; Sun, 10 Nov 2019 20:01:27 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
From: Mark Nottingham <>
In-Reply-To: <>
Date: Mon, 11 Nov 2019 12:01:25 +1100
Cc: Mike Bishop <>, Ryan Hamilton <>, Lars Eggert <>, IETF QUIC WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3601.0.10)
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: Mon, 11 Nov 2019 01:01:37 -0000

Hi Gorry,

> On 7 Nov 2019, at 11:38 pm, Gorry Fairhurst <> wrote:
> I don't think Recovery has that level of maturity yet.
> To me, QUIC transport contains protocol specs that are the same as other protocols - albeit inter-twined with the encryption model and HTTP-specific aspects, but the recovery spec is focused on the protocol mechanisms, and needs to be correct with respect to the implications on other transport flows sharing capacity with QUIC.
> In that space, we indeed need to get the spec correct. That may mean late comments (alas); but hopefully things will move faster if we focus on resolving issues and if work separates a little to http3 v recovery topic, actually most of the comments seem to come from a few people. If the process somehow impeded that I would be concerned.

I think the group would easily consider an issue regarding fairness to be worth discussion, so adopting the late-stage process shouldn't cause concern along these lines. The goal here is to beat any remaining issues out of the bushes (so to speak), and assure that we don't have an onslaught of "well, I would have done it this way..." issues crop up.

> Maybe I might feel happier after a detailed review of the latest text in 24 and a check through the issues -  I undertake to do this before the Singapore meeting!

That's reasonable; I think we can delay making a decision until then.


> Gorry
> On 06/11/2019 15:59, Mike Bishop wrote:
>> Also, the design team is an HTTP design team focused on having a coherent story around prioritization across HTTP versions.  They/we might propose text back to HTTP/3, or they might define HTTP/3 extensions in an HTTPbis document, or they might do something else entirely.  This working group should consider the design team output if it comes before the document is done, and if not will need to make a decision about whether to proceed without it.
>> -----Original Message-----
>> From: QUIC <> On Behalf Of Mark Nottingham
>> Sent: Tuesday, November 5, 2019 8:41 PM
>> To: Ryan Hamilton <>
>> Cc: Lars Eggert <>rg>; IETF QUIC WG <>
>> Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
>> Hi Ryan,
>> I think our intent was that it's an open issue, but I see that we haven't captured that in the current issues list. Good catch; let's go ahead and open one.
>> Cheers,
>>> On 6 Nov 2019, at 12:35 pm, Ryan Hamilton <> wrote:
>>> 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
>> --
>> Mark Nottingham

Mark Nottingham