Re: QUIC - Our schedule and scope
Patrick McManus <pmcmanus@mozilla.com> Fri, 27 October 2017 15:13 UTC
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED28C13B42C for <quic@ietfa.amsl.com>; Fri, 27 Oct 2017 08:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level:
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUQN04XQgDg5 for <quic@ietfa.amsl.com>; Fri, 27 Oct 2017 08:13:45 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7E1386DE for <quic@ietf.org>; Fri, 27 Oct 2017 08:13:45 -0700 (PDT)
Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id CD3573A0A4 for <quic@ietf.org>; Fri, 27 Oct 2017 11:13:44 -0400 (EDT)
Received: by mail-lf0-f50.google.com with SMTP id 90so7770396lfs.13 for <quic@ietf.org>; Fri, 27 Oct 2017 08:13:44 -0700 (PDT)
X-Gm-Message-State: AMCzsaV6sWaKrkifzE95X1An3ERoKMy/vxE9FzDCM90yHY1ahNYYvE0C w84cK6I/BPkV+f3Q0bd5g49zQCRC2oCyqu5m5zs=
X-Google-Smtp-Source: ABhQp+QWHdGYgqm4Rw2t2IZDvD7YJ6E/0F5pqfwwNRWaqDQu2JLzJeKqz+SaVVb8qMJhD6k48li/N8Eab1GNdsU3oNQ=
X-Received: by 10.25.23.214 with SMTP id 83mr271241lfx.213.1509117222950; Fri, 27 Oct 2017 08:13:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.21.22 with HTTP; Fri, 27 Oct 2017 08:13:42 -0700 (PDT)
In-Reply-To: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 27 Oct 2017 11:13:42 -0400
X-Gmail-Original-Message-ID: <CAOdDvNqdXLXEQff03t_YSLMpUpeT74E6XuAMh_C8GNiMM9f_Uw@mail.gmail.com>
Message-ID: <CAOdDvNqdXLXEQff03t_YSLMpUpeT74E6XuAMh_C8GNiMM9f_Uw@mail.gmail.com>
Subject: Re: QUIC - Our schedule and scope
To: Mark Nottingham <mnot@mnot.net>
Cc: QUIC WG <quic@ietf.org>, Lars Eggert <lars@netapp.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a1142cb34ff9e32055c88bb8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vIiipptlxJlwSsa7dq14KRp6EWM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2017 15:13:48 -0000
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 <mnot@mnot.net> 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
- QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Ian Swett
- Re: QUIC - Our schedule and scope Patrick McManus
- Re: QUIC - Our schedule and scope Salz, Rich
- Re: QUIC - Our schedule and scope Salz, Rich
- Re: QUIC - Our schedule and scope Eric Rescorla
- RE: QUIC - Our schedule and scope Lucas Pardue
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Willy Tarreau
- Re: QUIC - Our schedule and scope Göran Eriksson AP
- Re: QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Mark Nottingham
- RE: QUIC - Our schedule and scope Mike Bishop
- Re: QUIC - Our schedule and scope Brian Trammell (IETF)
- RE: QUIC - Our schedule and scope Salvatore Loreto
- RE: QUIC - Our schedule and scope Roni Even
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Christian Huitema
- Re: QUIC - Our schedule and scope Colin Perkins
- Re: QUIC - Our schedule and scope Spencer Dawkins at IETF
- RE: QUIC - Our schedule and scope Mike Bishop
- Re: QUIC - Our schedule and scope Philipp S. Tiesel
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Martin Duke
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Olivier Bonaventure
- RE: QUIC - Our schedule and scope Lubashev, Igor
- Re: QUIC - Our schedule and scope Quentin De Coninck
- Re: QUIC - Our schedule and scope Ian Swett
- RE: QUIC - Our schedule and scope Lubashev, Igor
- Re: QUIC - Our schedule and scope Ian Swett
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Bernard Aboba
- Re: QUIC - Our schedule and scope Colin Perkins
- Re: QUIC - Our schedule and scope Joerg Ott