Re: Re-chartering for extension work

Mark Nottingham <mnot@mnot.net> Thu, 12 December 2019 23:19 UTC

Return-Path: <mnot@mnot.net>
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 1FCF812012C for <quic@ietfa.amsl.com>; Thu, 12 Dec 2019 15:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ehpVZl/K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rN/17RJk
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 dA9STC_z0kRn for <quic@ietfa.amsl.com>; Thu, 12 Dec 2019 15:19:14 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E761812012A for <quic@ietf.org>; Thu, 12 Dec 2019 15:19:13 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 53BC8227D5; Thu, 12 Dec 2019 18:19:13 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 12 Dec 2019 18:19:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=r r2uo9z9HwjONIxf8Nt+RoXzXzbaR+QoFIJz7iedVRY=; b=ehpVZl/KUV/l3o3kX SnR9pVg6WRuoljN/TnOy+04mayrAcquPFNs08yxsT84xC3tLuEzrRebR1m0FdvT2 LR3+U+0V/Spy3zXQABYEB2hK44Mel6j7juO3fCncnWD0xzcwOfmTgKVShpaO0e2v 0QRBmKE5eK5dsnRn7ytqcEDExOxc5cWdUD5btdytT6zETknyuprRdsEvXPEP2mOU 9xOF+5U8MAKh8g777VTcv9/Vy5aUT0o/ydVyWJ1PsmfL2HC0rxPdSZ2ZpeeMpUKQ LBGUn9t/7VSPCTSIDRcnBzEDn4aWyBsZIrOGxW5938oLma0mb2Glgh8LERFcZi7C YgpiQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=rr2uo9z9HwjONIxf8Nt+RoXzXzbaR+QoFIJz7iedV RY=; b=rN/17RJk4B2pvr1XvZ945/5l39pOBnkFI8b0ItXQ+M/MDi4KvqWBpB6Mt AQ/KiIdIy6H+U5p/jRDtVzZACyOVLwn4TwGnI9uHvjJcZzLJDNCoRAlzoLhSz7b2 0mFBMPGvjQZvR21xGcUfortAhc/lgoJ73HRRHg43cFGUmPUKejCr+IM9jjBFkF33 0r9BieFNgOLVjV3y3miouvnRj4tsGghTzG86Umk6S2WonPvnQghhW7dz8CWHmesR j7VzAf+XZqJ/54pzYzEKixySDdDGuq/bZiGdScX27Gs+fCyI7kSpgb2MCJ+lCTsI UIjaCS4qfJRTBLa+Z9DCc4047wVnQ==
X-ME-Sender: <xms:78ryXVZ7FHDWEMV_XEOVWGgnf6fXOSk8q16eiJ3ShborIhdcHKICyg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudelkedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucfkphepuddule drudejrdduheekrddvhedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:78ryXXjtS81gA-XB0oXuOywgDs2lPrt4TXrMYyR3mc-wbj9LcpiUYA> <xmx:78ryXdUG2MUIiLTta-Ch6A_YEHxZ80Plz9rvIMzIhgsMOgCC6qUzOg> <xmx:78ryXTcGwFVAHneJalM6WrP80zjfaAhFbHoy4mIIcEdVH0WRf_ya3A> <xmx:8cryXVTb_PgZq5YWFFnzTnis8x4iJ6DIpIHxa9g6XxJdS-2ZfkPnvA>
Received: from attitudadjuster.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id DFB9D3060134; Thu, 12 Dec 2019 18:19:08 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Re-chartering for extension work
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAPDSy+65DX4havw8DScDeQv5TEwrms+5cH3hz5Qb-bep-hagaw@mail.gmail.com>
Date: Fri, 13 Dec 2019 10:19:05 +1100
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Lars Eggert <lars@eggert.org>, "quic@ietf.org" <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD10DCC8-D8DF-451E-B89F-62C7EEE01E49@mnot.net>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <6E58094ECC8D8344914996DAD28F1CCD27D34F98@dggemm526-mbx.china.huawei.com> <A51C42AD-6D1C-432D-99B4-8BB0FB824348@mnot.net> <6E58094ECC8D8344914996DAD28F1CCD27D34FD8@dggemm526-mbx.china.huawei.com> <18FA3A15-D580-43FD-A64C-E12E79D91419@mnot.net> <6E58094ECC8D8344914996DAD28F1CCD27D35044@dggemm526-mbx.china.huawei.com> <1575ae9dcdcade6a8ec68289fd6b735eae04ed32.camel@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD27D3512A@dggemm526-mbx.china.huawei.com> <c98ddfd008714672857833383153efb7@ustx2ex-dag1mb5.msg.corp.akamai.com> <CAPDSy+65DX4havw8DScDeQv5TEwrms+5cH3hz5Qb-bep-hagaw@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/J_UTVTSrjAl2mcQ0DyA_gkGW25Y>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 12 Dec 2019 23:19:16 -0000

> On 13 Dec 2019, at 7:50 am, David Schinazi <dschinazi.ietf@gmail.com>; wrote:
> 
> In general, I'm very supportive of rechartering to allow these new extensions.
> 
> I'd prefer to have the charter just allow all extensions, and then use the WG call for adoption consensus process to decide whether extensions are in-scope at a given moment in time or not. But if the chairs/ADs think that is too broad I can live with only opening up for specific topics.
> 
> One important problem though, is in the DATAGRAM case, the topic of flow identifiers. Earlier, draft-pauly-quic-datagram-03 contained flow identifiers. Based on community feedback, the authors removed them from -04, and moved them to a separate draft-schinazi-quic-h3-datagram. I'll admit that draft-schinazi-quic-h3-datagram is still very immature, but with the new charter, I want to make sure we don't end up in a state where we can discuss draft-pauly-quic-datagram but not draft-schinazi-quic-h3-datagram. Some folks feel strongly that flow identifiers should exist, and if we tell them that they're not in scope of the WG they might be sad.

It's good to know about these requirements, and of course once the document is adopted, we can discuss issues against it. However, if you want to discuss datagrams in HTTP/3, we need to have a discussion about whether it'd be more appropriate to do that in this WG or in the HTTP WG -- remembering that once HTTP/3 ships, it takes over maintenance of that spec.

Cheers,

> 
> Because of this, I think the new charter should discuss topics as opposed to specific draft names (which is what I assume Mark meant by [ adopted extensions ] )
> 
> David
> 
> On Thu, Dec 12, 2019 at 8:15 AM Lubashev, Igor <ilubashe@akamai.com>; wrote:
> Mark,
> 
> Speaking of lossbits, the work has been discussed at several meetings and there was a significant show of willingness of work on lossbits at the mic line in Singapore, on the condition that the work is (a) a negotiated extension, (b) the use of the bits is strictly specified, and (c) it is not blocking for QUIC v1.
> 
> We were planning to present the draft of lossbits as a negotiated extension in Zurich, but given that the time for the inclusion in the Charter is now, we can get the draft out next week.  Given the prior discussion and expressed willingness of at least a part of the WG to work on this, would you include that extension draft in the WG adoption call prior to the charter update?  (As usual, adoption != publication, which is subject to the deliberations of the WG, including a positive privacy/security analysis.)
> 
> - Igor
> 
> 
> > On Thu, Dec 12, 2019 at 4:52 AM, Roni Even (A) <roni.even@huawei.com>; wrote:
> > 
> > Hi
> > This clarifies the proposed charter and the priority of the V1 document  but
> > as for future extensions the text from the meeting notes says
> > 
> > "Mnot: If you do think you have an extension which is generic enough, we
> > will reserve time for it during the quiet for disucssion on the list. For this, we
> > will need a charter change for that, but we've been talking to the ADs about
> > that, and we'll put a proposal out for comment."
> > 
> > How is this reflected in the charter, which extensions will be considered
> > "generic enough" and appear by name in it. There are three extensions for
> > adoption and they look generic enough more (version negotiation,
> > datagrams)   or less (LBs), so why not lossbit, for example or any other from
> > the related I-Ds that are "generic enough". The problem in my view is that if
> > all these drafts are not in the proposed charter, they cannot be discussed at
> > all during the "quiet" .  I would prefer to allow in the charter and decide if to
> > create a milestone.
> > 
> > Roni
> > 
> > > -----Original Message-----
> > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> > > Sent: Thursday, December 12, 2019 11:08 AM
> > > To: Roni Even (A); mnot@mnot.net
> > > Cc: lars@eggert.org; quic@ietf.org
> > > Subject: Re: Re-chartering for extension work
> > >
> > > Hi,
> > >
> > > I want to give my input as AD into this process. We are intentionally
> > > keeping this rechartering very narrow in scope and do not intended to
> > > open up for general extension adoption in the WG at this moment. The
> > > extensions currently on call for adoption is selected set which
> > > appears important, tractable and with clear scope. However, the
> > > primary focus will remain on finishing the core specification of
> > > version 1 of QUIC. The chairs have my full confidence in managing the
> > > process and are communicating with us ADs regularly.
> > >
> > > As Mark stated before discussion of future extensions can occurr if
> > > time permits, we will also consider other ways of enabling the
> > > discussion like a QUIC dispatch session. However, as v1 finish we will
> > > take a new look at the QUIC WG charter and do a more thourgh recharter
> > > at that stage. That discussion will then happen in the context of the
> > > discussion that will have occurred between now and then. However,
> > > starting v2, how to handle both bigger and smaller extensions to the
> > > protocol and any additional guidance documents needed will clearly
> > > need changes to the charter.
> > >
> > > I hope that clarifies the road forward.
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > > On Thu, 2019-12-12 at 07:41 +0000, Roni Even (A) wrote:
> > > > Hi Mark,
> > > > I know that it was discussed in tsvarea session. I noticed that are
> > > > currently
> > > > 19 individual drafts in QUIC. I am not sure that all of them should
> > > > be
> > > adopted
> > > > as chartered work in QUIC. My view is that the WG should at least
> > > > say so
> > > and
> > > > propose to the authors to take it to a named WG ( probably need
> > > recommendation
> > > > from the Ads) instead of keeping them alive in the QUIC as related IDs.
> > > > Currently the authors can ask to add these documents to the charter
> > > > based
> > > on
> > > > the proposed charter change
> > > >
> > > > " The Working Group may consider other extension work, but adopting
> > > further
> > > > extensions requires updating this charter."
> > > >
> > > > This is like a new call for adoption process, instead for asking for
> > > > adoption the question will be call for re-charter.
> > > >
> > > > Roni
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Mark Nottingham [mailto:mnot@mnot.net]
> > > > > Sent: Thursday, December 12, 2019 9:15 AM
> > > > > To: Roni Even (A)
> > > > > Cc: IETF QUIC WG; Lars Eggert
> > > > > Subject: Re: Re-chartering for extension work
> > > > >
> > > > >
> > > > >
> > > > > > On 12 Dec 2019, at 6:13 pm, Roni Even (A) <roni.even@huawei.com>;
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > HI Mark,
> > > > > > I looked at your response to Jana, I do not have a better text
> > > > > > suggestion
> > > > >
> > > > > but I think that adding specific extensions can be discussed by
> > > > > asking the WG to create a new milestone. Yet I understand that the
> > > > > charter should be
> > > clear
> > > > > about what is in scope for the WG. I think that maybe the charter
> > > > > should also say that the WG can direct proposal for new work to
> > > > > another WG (sort of dispatch for QUIC).
> > > > >
> > > > > That's been discussed (at the Transport Area meeting in
> > > > > Singapore); we might try an experiment where we do something like
> > > > > that in Vancouver,
> > > but
> > > > > it's not clear that *this* WG should be the locus of
> > > > > quic-dispatchy things quite yet.
> > > > >
> > > > > Cheers,
> > > > >
> > > > >
> > > > > > One other thing, I think that when asking for adoption of a
> > > > > > document
> > > you
> > > > >
> > > > > are asking to create a milestone and adopt the document as the
> > > > > initial document to address the milestone.
> > > > > > Sorry for sounding like someone whose focus is on the process
> > > > > > and not
> > > the
> > > > >
> > > > > content.
> > > > > >
> > > > > > Roni
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Mark Nottingham [mailto:mnot@mnot.net]
> > > > > > > Sent: Thursday, December 12, 2019 9:00 AM
> > > > > > > To: Roni Even (A)
> > > > > > > Cc: IETF QUIC WG; Lars Eggert
> > > > > > > Subject: Re: Re-chartering for extension work
> > > > > > >
> > > > > > > Hi Roni,
> > > > > > >
> > > > > > > See my response to Jana regarding naming of extensions.
> > > > > > >
> > > > > > > Regarding milestones - yes, we'll do that when the rest of the
> > > > > > > changes go through. Thanks for the reminder.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > >
> > > > > > > > On 12 Dec 2019, at 5:49 pm, Roni Even (A)
> > > <roni.even@huawei.com>;
> > > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Mark,
> > > > > > > > I am not sure why you need to name extensions in the
> > > > > > > > charter. I think that
> > > > > > >
> > > > > > > the extension work in the charter should be general and the
> > > > > > > discussion about specific ones would be about creating a new
> > > milestone..
> > > > > > > >
> > > > > > > > BTW: maybe it will be good to update the milestones
> > > > > > > >
> > > > > > > > Roni Even
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of
> > > > > > > > > Mark Nottingham
> > > > > > > > > Sent: Wednesday, December 11, 2019 11:38 PM
> > > > > > > > > To: IETF QUIC WG
> > > > > > > > > Cc: Lars Eggert
> > > > > > > > > Subject: Re-chartering for extension work
> > > > > > > > >
> > > > > > > > > We've just put out Calls for Adoption for extensions to
> > > > > > > > > QUICv1, as we believe that the group has some capacity to
> > > > > > > > > discuss them as it finishes work on the core protocol.
> > > > > > > > >
> > > > > > > > > However, our charter [1] precludes work on at least some
> > > extensions.
> > > > > > > > > The specific text in question is:
> > > > > > > > >
> > > > > > > > > """
> > > > > > > > > Extensions that will support partial reliability, and
> > > > > > > > > negotiation and use of Forward Error Correction schemes,
> > > > > > > > > are out of scope in this version of the working group charter.
> > > > > > > > > """
> > > > > > > > >
> > > > > > > > > *If* we do decide we'd like to adopt, we'll need to update
> > > > > > > > > it to something
> > > > > > > > > like:
> > > > > > > > >
> > > > > > > > > """
> > > > > > > > > Additionally, the Working Group will deliver [ adopted
> > > > > > > > > extensions
> > > ].
> > > > > > > > > The Working Group may consider other extension work, but
> > > adopting
> > > > > > > > > further extensions requires updating this charter.
> > > > > > > > > """
> > > > > > > > >
> > > > > > > > > Please take a look and discuss any concerns; we'll be
> > > > > > > > > asking our ADs for such a modification (with appropriate
> > > > > > > > > changes to the list of extensions adopted) once our Calls for
> > Adoption complete.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > >
> > > > > > > > > 1. https://datatracker.ietf.org/wg/quic/about/
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Mark Nottingham
> > > > > > > > > https://protect2.fireeye.com/v1/url?k=2f5948b0-73cb45af-
> > > 2f59082b-0cc47ad93db4-7b6490019ba3569f&q=1&e=4eadb99e-52e4-49b3-
> > > adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > > > >
> > > > > > > --
> > > > > > > Mark Nottingham
> > > > > > > https://protect2.fireeye.com/v1/url?k=bc29a42a-e0bba935-
> > > bc29e4b1-0cc47ad93db4-eaf17369ba9839a7&q=1&e=4eadb99e-52e4-49b3-
> > > adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > >
> > > > > --
> > > > > Mark Nottingham
> > > > > https://protect2.fireeye.com/v1/url?k=21be3936-7d2c3429-21be79ad-
> > > 0cc47ad93db4-613c07cadcb96094&q=1&e=4eadb99e-52e4-49b3-adef-
> > > 683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > >
> > > >
> > > --
> > > Cheers
> > >
> > > Magnus Westerlund
> 

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