Re: QUIC - Our schedule and scope
Willy Tarreau <w@1wt.eu> Fri, 27 October 2017 19:13 UTC
Return-Path: <w@1wt.eu>
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 811FD13F5C1 for <quic@ietfa.amsl.com>; Fri, 27 Oct 2017 12:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 EigTvRTXMpaj for <quic@ietfa.amsl.com>; Fri, 27 Oct 2017 12:13:20 -0700 (PDT)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3122213F42B for <quic@ietf.org>; Fri, 27 Oct 2017 12:13:20 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9RJDECf001000; Fri, 27 Oct 2017 21:13:14 +0200
Date: Fri, 27 Oct 2017 21:13:14 +0200
From: Willy Tarreau <w@1wt.eu>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Mark Nottingham <mnot@mnot.net>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@netapp.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: Re: QUIC - Our schedule and scope
Message-ID: <20171027191314.GA997@1wt.eu>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <CAOdDvNqdXLXEQff03t_YSLMpUpeT74E6XuAMh_C8GNiMM9f_Uw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOdDvNqdXLXEQff03t_YSLMpUpeT74E6XuAMh_C8GNiMM9f_Uw@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6Csu_LBb7g_sAPFNWa-k87qxcI0>
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 19:13:22 -0000
On Fri, Oct 27, 2017 at 11:13:42AM -0400, Patrick McManus wrote: > A shot > clock process fix isn't going to get a high quality result - we need an > attitude fix :) I agree. It's also important to keep in mind that there are periods in the year where people are more busy by their work than other periods and this can give the impression that everything stalls, but participating less does not necessarily imply not thinking to come back later with clearer views or more willingness to accept others' proposals. > 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 . That's exactly what I was thinking as well. I'm fine with delaying a release for a very good reason, but in general very good reasons more easily achieve a rough consensus. It's the same with accepting not to delay because the reason is not very good. If all WG members keep in mind that they take a responsibility for delaying stuff by opening issues, it can get better. > 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. Agreed as well, we all know a few minor design mistakes that ended up in H2 and HPACK for the sole reason that we stubbornly refused to play with a few bits at the end. It makes none of us suffer, but it makes implementations slightly more painful to write and the protocol slightly less efficient. I tend to consider that important design must be defined first and that small variations must be considered at the end. But we must just accept the fact that a deployed beta version doesn't count as a good reason for not fixing the last bits at the end, otherwise everyone will still bikeshed to ensure the small bits that matter to them are committed first to prevent the H2 process from happening again. > 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. I think it's reasonable as well, it's hard to try to design for everything at once, especially in such a very new area. > > * 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. In fact we should start to speak about QUICv1 (Q1?) and not QUIC to make this clear for everyone. Just my two cents, Willy
- 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