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

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Nov 2019 12:01:34 +1100

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:
  
https://github.com/quicwg/base-drafts/issues?q=is%3Aissue+is%3Aclosed+label%3Adesign+-label%3Ahas-consensus+-label%3A-transport+-label%3A-tls

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. https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#late-stage-process

--
Mark and Lars, QUIC WG Chairs

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 5 Nov 2019 17:35:43 -0800

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 <[email-masked]> 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.
>
> 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`.
>
> 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.
> https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#late-stage-process
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Nov 2019 12:41:27 +1100

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 <[email-masked]> 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?)
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mike Bishop <[email-masked]>
Date: Wed, 6 Nov 2019 15:59:28 +0000

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 <[email-masked]> On Behalf Of Mark Nottingham
Sent: Tuesday, November 5, 2019 8:41 PM
To: Ryan Hamilton <[email-masked]>
Cc: Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

Hi Ryan,

Cheers,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 6 Nov 2019 10:39:35 -0800

> On Nov 5, 2019, at 5:01 PM, Mark Nottingham <[email-masked]> wrote:
> 

I don't think that process has worked well for QUIC.

There are specific issues that are contentious enough to timebox
and conclude, in a formal (and faster) fashion than was done before.
That makes sense when needed for a specific issue. I don't know
of any such issues for those three drafts. IOW, I don't know of any
issues for which it makes sense for the Chairs to pre-empt the
specification authors in deciding what can or cannot result in
changes to the drafts just because of the timing of when the
issue was raised.

The late-stage process seems to focus all of our energy into
in/out-of-scope arguments rather than actual text in the specifications.
The last interim spent easily twice as much time discussing process
and process planning than it did HTTP/3. Prior interims were worse.
I don't even recall the last time contents of the HTTP/3 spec being
discussed on list, outside of very specific issues related to transport.

I would like to see HTTP/3 written with HTTP in mind, not as a set
of diffs against h2. I would like this working group to shift its focus
away from transport issues (now that they are largely resolved and
awaiting final edits) and into active discussion of HTTP/3. The only
example we have of that is the https discussion, which revealed a
necessary issue for http-core to resolve and is expected to iterate
back onto HTTP/3.

This is not a small undertaking, but it isn't a massive one either.
Basically, import the bits of h2 that are necessary to explain HTTP/3's
operation and intent, and then start referencing the http-core drafts
instead of 723x. Yes, I know that is risky, but it is the right thing to do.
And it needs to be done before http-core is finished, since that effort
exists largely to place the right content (in the right places) for
HTTP/3 to reference.

That's a far better use of our time than arguing about what stage
the HTTP/3 documents are in.

I would also like to see the details of interop testing reported on list,
to the extent that people are willing/able to report them in public
(i.e., nothing specific to vendors or products). In particular,
I'd like to know how much of HTTP practice has actually been
exercised by those tests. Is it still limited to HTTP/0.9 interop?
Have we looked at long sessions interleaved with short spatter?
What about API-driven, non-browser traffic?

I have no idea what the status is with QPACK, but we should
learn a lesson from the last time and make sure the fixed
compression dictionary (if any) is based on traffic at more than
one proxy or origin server. Or at least have each of the major
deployments generate their local "best" encoding and do some
cross-testing of the N choices (plus one or two based on a
hand-crafted expert merge).

I would like for HTTP/3 to have a mechanism for communicating
metadata (like trailers) in mid-stream, both for requests (e.g., priority)
and responses (e.g., chained sigs). That has been a design goal for HTTP
since 1995 or so. HTTP/1.1 had it, albeit limited to chunked extensions.
It has been proposed multiple times and keeps getting postponed
because of "concern about scope". This is not a semantics issue
(they are just optional trailers that arrive early) -- it is a multiplex
framing issue (a new frame type and expectation to process).

> 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 imp…

-1  I don't think the non-transport issues have been discussed to the
     point where most issues could be reasonably opened, so saying
     we have consensus on the initial document is premature.
     We have been waiting for a transport consensus.
     Let's get that consensus and spend more energy on HTTP/3.

....Roy

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 6 Nov 2019 12:56:21 -0800

On Tue, Nov 5, 2019 at 5:41 PM Mark Nottingham <[email-masked]> wrote:

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

Done. https://github.com/quicwg/base-drafts/issues/3198

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 7 Nov 2019 12:38:18 +0000

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.

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!

Gorry

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Nov 2019 12:00:30 +1100

Hi Roy,

Responding to the parts relevant to this CfC.

> On 7 Nov 2019, at 5:39 am, Roy T. Fielding <[email-masked]> wrote:
> 

Noted.

> changes to the drafts just because of the timing of when the

You misunderstand the process; the Chairs aren't pre-empting anything, the group is attempting to agree to a path to completing this work.

> in/out-of-scope arguments rather than actual text in the specifications.

I don't see any evidence for that claim; what makes you believe that?

> and process planning than it did HTTP/3. Prior interims were worse.

We spent a day talking about transport and TLS, part of a morning talking about planning the future of our work (if you want to call that "process and process planning") and the bulk of the (longer) afternoon session talking about H3. This isn't surprising, since our goal for the meeting was to get the Transport and TLS documents close to finished.

> of diffs against h2.

That is by charter; we're largely limited to mapping H2 onto QUIC. 

> exists largely to place the right content (in the right places) for

AIUI that is still our intent, and shouldn't be impeded by the late-stage process, since that work should be editorial.

> framing issue (a new frame type and expectation to process).

Where are the multiple proposals you refer to? We've been working on h3 now for more than three years. If you submit them now, they'll be design issues.

I'd say that the Late-Stage process (or at least the proposal of adopting it) is working exactly as intended here -- making people realise that if they still have issues / changes that they want discussed, they need to bring them to our attention now, not as we go to WGLC.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Nov 2019 12:01:25 +1100

Hi Gorry,

> On 7 Nov 2019, at 11:38 pm, Gorry Fairhurst <[email-masked]> wrote:
> 
> 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.

Cheers,

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Nov 2019 15:40:32 +0000

I'll also note that it's relatively easy from a spec perspective to allow trailers to arrive before the end of the body, or to allow multiple sets of trailers to arrive.  I suspect most clients won't process trailers until they have the body anyway, but the real question is what clients do with multiple trailer sets.  I'm not certain whether that's in our scope or not, but that's a separate conversation.  Feel free to open an issue for that specific discussion.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Mark Nottingham
Sent: Sunday, November 10, 2019 8:01 PM
To: Roy Fielding <[email-masked]>
Cc: Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

Hi Roy,

Noted.

> There are specific issues that are contentious enough to timebox and 
> conclude, in a formal (and faster) fashion than was done before.
> That makes sense when needed for a specific issue. I don't know of any 
> such issues for those three drafts. IOW, I don't know of any issues 
> for which it makes sense for the Chairs to pre-empt the specification 
> authors in deciding what can or cannot result in changes to the drafts 
> just because of the timing of when the issue was raised.

> I would like to see HTTP/3 written with HTTP in mind, not as a set of 
> diffs against h2.

> Basically, import the bits of h2 that are necessary to explain 
> HTTP/3's operation and intent, and then start referencing the 
> http-core drafts instead of 723x. Yes, I know that is risky, but it is the right thing to do.
> And it needs to be done before http-core is finished, since that 
> effort exists largely to place the right content (in the right places) 
> for
> HTTP/3 to reference.

> I have no idea what the status is with QPACK, but we should learn a 
> lesson from the last time and make sure the fixed compression 
> dictionary (if any) is based on traffic at more than one proxy or 
> origin server. Or at least have each of the major deployments generate 
> their local "best" encoding and do some cross-testing of the N choices 
> (plus one or two based on a hand-crafted expert merge).
> 
> I would like for HTTP/3 to have a mechanism for communicating metadata 
> (like trailers) in mid-stream, both for requests (e.g., priority) and 
> responses (e.g., chained sigs). That has been a design goal for HTTP 
> because of "concern about scope". This is not a semantics issue (they 
> are just optional trailers that arrive early) -- it is a multiplex 

Cheers,

---

From: Martin Duke <[email-masked]>
Date: Tue, 12 Nov 2019 16:42:12 -0800

IMO the recovery draft is in the midst of a major revision dealing with the
aftereffects of discarding the crypto timeout. Ian still has a bunch of
stuff in flight for this. When all of those PRs land I would like to have a
short period to review the working draft and see if it looks good.

On Mon, Nov 11, 2019 at 7:40 AM Mike Bishop <[email-masked]> wrote:

> I'll also note that it's relatively easy from a spec perspective to allow
> trailers to arrive before the end of the body, or to allow multiple sets of
> trailers to arrive.  I suspect most clients won't process trailers until
> they have the body anyway, but the real question is what clients do with
> multiple trailer sets.  I'm not certain whether that's in our scope or not,
> but that's a separate conversation.  Feel free to open an issue for that
> specific discussion.
>
> >> 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
> >> 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.
> >
> You misunderstand the process; the Chairs aren't pre-empting anything, the
> group is attempting to agree to a path to completing this work.
>
> We spent a day talking about transport and TLS, part of a morning talking
> about planning the future of our work (if you want to call that "process
> and process planning") and the bulk of the (longer) afternoon session
> talking about H3. This isn't surprising, since our goal for the meeting was
> to get the Transport and TLS documents close to finished.
>
> AIUI that is still our intent, and shouldn't be impeded by the late-stage
> process, since that work should be editorial.
>
> Where are the multiple proposals you refer to? We've been working on h3
> now for more than three years. If you submit them now, they'll be design
> issues.
>
> I'd say that the Late-Stage process (or at least the proposal of adopting
> it) is working exactly as intended here -- making people realise that if
> they still have issues / changes that they want discussed, they need to
> bring them to our attention now, not as we go to WGLC.
>
> Cheers,
>
> --

---

From: Martin Duke <[email-masked]>
Date: Tue, 12 Nov 2019 16:42:49 -0800

Put another way, I think Gorry's planned review of draft-24 is probably
premature.

On Tue, Nov 12, 2019 at 4:42 PM Martin Duke <[email-masked]> wrote:

> IMO the recovery draft is in the midst of a major revision dealing with
> the aftereffects of discarding the crypto timeout. Ian still has a bunch of
>> You misunderstand the process; the Chairs aren't pre-empting anything,
>> the group is attempting to agree to a path to completing this work.
>>

---

From: Ian Swett <[email-masked]>
Date: Wed, 13 Nov 2019 09:39:26 -0500

I'm not aware of anything important in-flight( :) ) for recovery.  #3066
<https://github.com/quicwg/base-drafts/pull/3066> has been in the editor's
copy for over a week now, and did not quite make -24, so I would recommend
reading the editors copy.  There is one handshake optimization PR(#3080
<https://github.com/quicwg/base-drafts/pull/3080>) and an alternate
solution to the amplification deadlock(#3162
<https://github.com/quicwg/base-drafts/pull/3162>), but neither is critical
in my opinion.

There is a possibility of the discard keys conversation changing recovery,
though at least one solution(HANDSHAKE_DONE
<https://github.com/quicwg/base-drafts/pull/3145>) does not require any
changes.  If changes are required, I expect them to be ~2-3 sentences.

On Tue, Nov 12, 2019 at 7:43 PM Martin Duke <[email-masked]> wrote:

>>> I'll also note that it's relatively easy from a spec perspective to
>>> allow trailers to arrive before the end of the body, or to allow multiple
>>> sets of trailers to arrive.  I suspect most clients won't process trailers
>>> until they have the body anyway, but the real question is what clients do
>>> with multiple trailer sets.  I'm not certain whether that's in our scope or
>>> not, but that's a separate conversation.  Feel free to open an issue for
>>> that specific discussion.
>>>
>>> We spent a day talking about transport and TLS, part of a morning
>>> talking about planning the future of our work (if you want to call that
>>> "process and process planning") and the bulk of the (longer) afternoon
>>> session talking about H3. This isn't surprising, since our goal for the
>>> meeting was to get the Transport and TLS documents close to finished.
>>>
>>> > This is not a small undertaking, but it isn't a massive one either..
>>> AIUI that is still our intent, and shouldn't be impeded by the
>>> late-stage process, since that work should be editorial.
>>>
>>> I'd say that the Late-Stage process (or at least the proposal of
>>> adopting it) is working exactly as intended here -- making people realise
>>> that if they still have issues / changes that they want discussed, they
>>> need to bring them to our attention now, not as we go to WGLC.
>>>
>>> Cheers,
>>>
>>> --

---

From: Martin Duke <[email-masked]>
Date: Mon, 18 Nov 2019 08:24:21 +0800

OK, I apparently missed taht a few of these pushed to master. Yes, let's
move for late-stage

On Wed, Nov 13, 2019 at 10:39 PM Ian Swett <[email-masked]> wrote:

> <https://github.com/quicwg/base-drafts/pull/3066> has been in the
> editor's copy for over a week now, and did not quite make -24, so I would
> recommend reading the editors copy.  There is one handshake optimization PR(
> #3080 <https://github.com/quicwg/base-drafts/pull/3080>) and an alternate
> <https://github.com/quicwg/base-drafts/pull/3162>), but neither is
> critical in my opinion.
>
>>>> >> 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.
>>>> >>
>>>> metadata

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Nov 2019 08:58:20 +1100

These documents are now in the late-stage process.

Thanks,

> On 6 Nov 2019, at 12:01 pm, Mark Nottingham <[email-masked]> wrote:
>