Re: QUIC - Our schedule and scope

["Eggert, Lars" <[e-mail]>]

Hi,

On 2017-10-27, at 17:13, Patrick McManus <[e-mail]> wrote:
> On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <[e-mail] <mailto:[e-mail]>> wrote:
> 
> To address this, we think two things are necessary:
> 
> Just for clarification, you're suggesting these 2 bullets as updates in some form to the wg charter?
> 
> 1) Our Milestone for delivering the "core" QUIC documents (plus applicability and manageability statements) to the IESG should be moved to December 2018, with the understanding that this is a deadline we intend to meet.
> 
> 2) V1 of QUIC should *only* address the use case of HTTP.

I haven't synced with Mark on this, but my personal view is that neither of these affect the charter text. (1) changes the date of our milestones. (2) is - in my view at least - already what the charter expresses: it doesn't talk about applications other than HTTP as something that work is occurring on.

> This has a few implications:
> 
> * Proposals for changes that are not realistically achievable in the timeline of #1 will be rejected on that basis, because the WG has consensus that the schedule is important.
> 
> This needs to be severely unpacked and I do not support it in the way I'm interpreting it.
> 
> I think the only way we're going to finish quickly and still create a good product is if all the participants are focused on getting to yes. A shot clock process fix isn't going to get a high quality result - we need an attitude fix :)

Agreed.

> The current charter says "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." This remains an important property for the evolution of IETF QUIC. We need to work through all the details as a working group.. I think we can do it faster, but not by inventing an arbitrary forcing function.

Reading your comment, I can now see how the original text could be interpreted this way. However, at least my understanding of what we were trying to express that there is an urgency to deliver, and we hope that by narrowing the discussion on what is important for H2 we can avoid going down some ratholes that are unrelated, or at least avoid going down them quite as deeply.

But if there are design choices that the WG has consensus on that are important for H2, and they would postpone shipping v1 *and* the WG is OK with that, too, then that's what it'll be. But we should all be conscious of the quality vs. time tradeoff.

> A firm timebox severely undermines the consensus process via simple gamificiation to 'run out the clock' in favor of existing text. That is not in the interest of the end result or getting consensus in a multi-stakeholder process. Indeed it probably increases the chances for a disastrous last call period. However, getting to yes is in everybody's interest. That's a much better motivator.

Full agreement.

> I think a better path would be for the chairs to more aggressively declare rough consensus at an earlier stage of discussion than is typically done. I'm not suggesting a different threshold of consensus, just less indulgence in letting issues play all the way out in hopes of convergence. Perhaps also an appeal to all WG members to consider the implications of expressing an opinion on a topic .. Every issue does not need to be a poll for everyone's opinion.. save it for places where your opinion makes a material difference to you. (i.e. acknowledge that two people will disagree on what is a bikeshed vs what is meaningful and stay out of it in the name of progress if you are on the bikeshed side).

These are good suggestions. Instead of the chairs declaring consensus earlier, we preferred to give the editors a lot of discretion about merging changes. Maybe the chairs need to become more involved in cases where there is disagreement amongst some editors.

Lars

> I have no objection to updating the milestone delivery date to something more reasonable, but I do think elevating schedule to be a higher order concern than consensus on the RFC content is wrong.
> 
> I think your second suggestion, scoping around HTTP for v1, is more likely to get us to a successful finish. As we get later in this process, it will be more important.
> 
> 
> * Discussion of anything else (including issues, drafts, proposals) that doesn't address the needs of HTTP-over-QUIC will be postponed until after V1 has shipped.
> 
> 
> Browsing through the archives I actually don't see very many issues that are totally non-http (certainly < 10%). But there probably are quite a few that are simpler to resolve if only http is taken into account.
> 
> -P
>