Re: QUIC - Our schedule and scope

[Patrick McManus <[e-mail]>]

Hi All,

First, the observation that elapsed time impacts participation and
participation impacts quality is a good observation. Finishing faster (I
personally want to go way way faster) is consistent with that and we should
look at how we're organized to help make that a reality. Thanks for doing
that.

I'm also not quite as pessimistic as the chairs are. I don't really think
this is a linear process - as we get more input from more implementations I
think the process will naturally accelerate. The challenge at that later
stage will be on not re-opening issues that we have reached consensus on.
That's different than the challenge we've been going through for the last
year; for the last year we've been building up the basic blocks from an
explicitly 0-consensus starting point. Its both not surprising, and a good
thing, that many issues have been given scrutiny during that phase.


On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <[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.
>
> 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 :)

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.

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.

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

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