RE: Re-chartering for extension work

"Roni Even (A)" <roni.even@huawei.com> Thu, 12 December 2019 07:41 UTC

Return-Path: <roni.even@huawei.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 67DE312083D for <quic@ietfa.amsl.com>; Wed, 11 Dec 2019 23:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 tgX4BfGh_8kP for <quic@ietfa.amsl.com>; Wed, 11 Dec 2019 23:41:56 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 694A512008C for <quic@ietf.org>; Wed, 11 Dec 2019 23:41:56 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0C8901EE40B53B0507C6 for <quic@ietf.org>; Thu, 12 Dec 2019 07:41:55 +0000 (GMT)
Received: from lhreml714-chm.china.huawei.com (10.201.108.65) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 12 Dec 2019 07:41:54 +0000
Received: from lhreml714-chm.china.huawei.com (10.201.108.65) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 12 Dec 2019 07:41:54 +0000
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 12 Dec 2019 07:41:54 +0000
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.101]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Thu, 12 Dec 2019 15:41:51 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Mark Nottingham <mnot@mnot.net>
CC: IETF QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Subject: RE: Re-chartering for extension work
Thread-Topic: Re-chartering for extension work
Thread-Index: AQHVsGtkwQYlvsKzDkalKC49qw+Rnqe2Dx2A//99gICAAIfrsP//fF8AgACKPOA=
Date: Thu, 12 Dec 2019 07:41:50 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD27D35044@dggemm526-mbx.china.huawei.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>
In-Reply-To: <18FA3A15-D580-43FD-A64C-E12E79D91419@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.67]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/l2FlVP6sf8b6jLIjvY_XVStfkUQ>
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 07:41:59 -0000

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://www.mnot.net/
> >>>
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >
> 
> --
> Mark Nottingham   https://www.mnot.net/