RE: Re-chartering for extension work

"Lubashev, Igor" <ilubashe@akamai.com> Wed, 18 December 2019 23:39 UTC

Return-Path: <ilubashe@akamai.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 8B112120116 for <quic@ietfa.amsl.com>; Wed, 18 Dec 2019 15:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 v_U1br_jeLvO for <quic@ietfa.amsl.com>; Wed, 18 Dec 2019 15:39:14 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73E2120013 for <quic@ietf.org>; Wed, 18 Dec 2019 15:39:13 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBINMxTL004259; Wed, 18 Dec 2019 23:38:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0YSrDcIjpbey690GRC86NBxBUl7MMhkRipF36NPtscw=; b=C4P23GSz8MFDpl7Uk1u9gHDA4lrbFjDTvnKrRvIoeOLaTRHyi7CR31NHGQDcqeZlxF7n UVUn9SSzyE8drRZrJKQLqfyVHIwisfcCt7Q0VnPohnsRT6mpBk7TWV84OKl2zwMfPj6Z kinvO84egNCVME8fw8Ki2gVFAON+OJVOTsXQPg6g/51PAtrWVx2KTlBJYWsXezl4dwWz axyfCxXqkuOvlAnqA4Lar10/xXKysO8+CFjvQ5+5+bmaeeY4I68A53xGRRo27Vf/FxEb Dg0oJLMYFoVazaMs4brzH7WARPODMjvdf5Ev4nRiQY26r2bWCQ2sHGNSUDu+d8I2kPZK Sw==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wvr91hv69-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Dec 2019 23:38:59 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBINXLIV008825; Wed, 18 Dec 2019 18:38:58 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint4.akamai.com with ESMTP id 2wvuy5kq3t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Dec 2019 18:38:58 -0500
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 17:38:57 -0600
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) with mapi id 15.00.1473.005; Wed, 18 Dec 2019 15:38:57 -0800
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "mnot@mnot.net" <mnot@mnot.net>
CC: "lars@eggert.org" <lars@eggert.org>, "quic@ietf.org" <quic@ietf.org>
Subject: RE: Re-chartering for extension work
Thread-Topic: Re-chartering for extension work
Thread-Index: AQHVsGtbz4hcPwmxz0WVLe+SyklylKe2dFkAgAAC9YCAAAPbgIAAAG8AgAAHYACAABf/gIAADD+AgAADBqCACd+dgIAAT5YA//+2KfA=
Date: Wed, 18 Dec 2019 23:38:57 +0000
Message-ID: <3237f66fd3414a979496f662531b9224@ustx2ex-dag1mb6.msg.corp.akamai.com>
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> <28639c145dae9d10c3bbc8328aa93ea4feb8a7de.camel@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD27D363CE@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD27D363CE@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.117.196]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-18_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912180174
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-18_08:2019-12-17,2019-12-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 mlxscore=0 mlxlogscore=999 suspectscore=0 phishscore=0 spamscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912180173
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/lv8CB95Bphz7CyskW0fNQHDEEqw>
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: Wed, 18 Dec 2019 23:39:17 -0000

Magnus,

I support considering WG Charter as a "promise to IETF" as to the scope of work the group will and will not do.  As such, re-chartering frequently is the same as changing your promises frequently.  Not good.  If a re-charter is needed, I'd rather it be honest and complete and not to contain an expectation that there may be another re-charter "soon".

- Igor

P.S.
  When I hear that lossbits "likely to require much discussion" as a reason for exclusion from the charter, I am not sure about the criteria used here. Several of the about-to-do-adopted/in-the-proposed-charter works are likely to generate a significant discussion and a significant rework (more so for the loadbal work, less so for datagrams).  If the concern is about the limited group meeting time, chars indicated that they are very capable of managing meeting time productively.  (I'd note that the entire lossbits discussion in Singapore took less mic time than Retry checksum bikeshed(?), and a good number of people indicated willingness to work on lossbits, including to participate in privacy analysis.)


> From: Roni Even (A) <roni.even@huawei.com>
> 
> Magnus,
> I am confused, I was not asking for adoption of the work but to have it in the
> charter so it can be discussed on the list and worked upon without being
> contested as non-chartered work. This is at least my understanding about
> the difference between the charter and adoption
> 
> Roni
> 
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> > Sent: Wednesday, December 18, 2019 4:49 PM
> > To: Roni Even (A); mnot@mnot.net; ilubashe@akamai.com
> > Cc: lars@eggert.org; quic@ietf.org
> > Subject: Re: Re-chartering for extension work
> >
> > Hi Igor and Roni,
> >
> > The three work items being proposed for adoption and recharter are
> > seen as highly relevant, constrained, and likely to make good progress
> > and have limited impact on the v1 work. I think the call for adoption
> > is good indicator of  the support for these items.
> >
> > The Loss bits even if there is significant interest in them I don't
> > expect to make rapid progress and likely to require much discussion.
> > Those the potential for causing impact on the v1 work is significant
> > even if it is not a direct dependency. That alone is enough from my
> > perspective to not include this in this step of adopting things.
> >
> > It is good that you continue to work on it and progress important
> > aspects, like privacy and security considerations.
> >
> > Hope that clarifies the reasoning.
> >
> > Cheers
> >
> > Magnus
> >
> >
> >
> > On Thu, 2019-12-12 at 16:14 +0000, Lubashev, Igor 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-73cb4
> > > > > > > > > > > 5af-
> > > > >
> > > > > 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
> > >
> > >
> > --
> > Cheers
> >
> > Magnus Westerlund
> >
> >
> > ----------------------------------------------------------------------
> > Networks, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Torshamnsgatan 23           | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > ----------------------------------------------------------------------
> >