RE: Re-chartering for extension work

Mike Bishop <mbishop@evequefou.be> Tue, 17 December 2019 17:11 UTC

Return-Path: <mbishop@evequefou.be>
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 C7EFB120830 for <quic@ietfa.amsl.com>; Tue, 17 Dec 2019 09:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 qPOfO3SVmJF7 for <quic@ietfa.amsl.com>; Tue, 17 Dec 2019 09:11:39 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2102.outbound.protection.outlook.com [40.107.237.102]) (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 BB528120220 for <quic@ietf.org>; Tue, 17 Dec 2019 09:11:39 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HuWpWArewi5xYHkhlhRKez78AvW0uOx7SPHvJjnnNz2yTuYd/dzBOCPuCRVZTLaLaznmO5iToxNYPxaVeyt6CfXJ85CX6XvypAYd4pUoa0FvXFC1PH2HlagwvXWvONo8xws4V4KsJHcvsjaPyih0ZFIQo5Zri1nDfnZ6EeShC3VqaeMFawwC93F8508oyh11C8WE1aoPizaCLsKsCxPJA2/v3Nhpq23giK0ZhDkLU3OJ330+csnV5SfwOyAAY/lWY+Xns7bG8f0p4HBd05T8A1J9IUHPBjlldaVIBadEivLSbYd77uG1VLuweRnAmcSjL/ly6E9PFRZa9ryvk3jGrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9E2xNHqCY91JCb3lD9MuuTS/JK9Q9XYNruC/3048rpU=; b=PevzKPSQMnxlllYpvFyh7LQsaDVtrIT89we/HV2KS6yTLSt3PwvW849rDcStmgeArbc2RkpgVcFwK8SqEDQr3WwhPfWhJAo8E+fBWUbAty1p8qeasVz2iJL63JACT8ocwb1gAGY+Of1wRLHuWK8WO/lYqLRj7cCsnd3h/nJlrrprprzhNfX69Dn0MHm8tHzUakHg2ogyVH8Af/5Js85dWjeMb5Gq3AoC/mtMPtUVv4J0JAK1Kbddvn5yLvovhQkijuc71mHGn7u4XFfvFY1bZiCL3fCzZc0j4eJKu2jnWorjaGYbAGwqWb1YHgLsm0RouisA7Wc9o9wI6/Ly0OtECg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9E2xNHqCY91JCb3lD9MuuTS/JK9Q9XYNruC/3048rpU=; b=I6vh3NsKUExonLM+nSPg9yVpKUK/LrMEHd81/SjueUwjXOZDUz2jCyP6bF3z7+UiKCSKE6PK3ovIx/y55Z5LzoRKWpzW4pa+XIU5S+TWE+0F6dzD/X2RDa7phbUV2xPDVKx3KOyIOntY6Occ0Knfjt2zyhw0rFFm1963yomX6OE=
Received: from DM6PR22MB2010.namprd22.prod.outlook.com (20.180.22.24) by DM6PR22MB1916.namprd22.prod.outlook.com (20.180.23.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.17; Tue, 17 Dec 2019 17:11:36 +0000
Received: from DM6PR22MB2010.namprd22.prod.outlook.com ([fe80::e09c:cecd:389d:d9f3]) by DM6PR22MB2010.namprd22.prod.outlook.com ([fe80::e09c:cecd:389d:d9f3%6]) with mapi id 15.20.2538.019; Tue, 17 Dec 2019 17:11:36 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Mark Nottingham <mnot@mnot.net>, Jana Iyengar <jri.ietf@gmail.com>
CC: Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Re-chartering for extension work
Thread-Topic: Re-chartering for extension work
Thread-Index: AQHVsGtc1habKoWIXUae66NR77fDcKe1hdeAgACMTICACIMNAA==
Date: Tue, 17 Dec 2019 17:11:36 +0000
Message-ID: <DM6PR22MB201009C7E48ACE27A1271CB0DA500@DM6PR22MB2010.namprd22.prod.outlook.com>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <CACpbDcdaQGmSGvb+skNEenEuMXESPi1sFPs5Bi_YwvdQzawD1w@mail.gmail.com> <010EBBDD-5C7E-4B18-B98C-3770430D2C8C@mnot.net>
In-Reply-To: <010EBBDD-5C7E-4B18-B98C-3770430D2C8C@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2600:2b00:931f:a301:e553:3c6c:a947:cb14]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3a7ccd1c-2279-40f3-3b14-08d783142c92
x-ms-traffictypediagnostic: DM6PR22MB1916:
x-microsoft-antispam-prvs: <DM6PR22MB19160AF2739CD0DCE9D6CF00DA500@DM6PR22MB1916.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02543CD7CD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(346002)(376002)(39830400003)(199004)(189003)(13464003)(86362001)(110136005)(33656002)(54906003)(66946007)(76116006)(66556008)(64756008)(316002)(4326008)(66476007)(71200400001)(66446008)(186003)(52536014)(8676002)(7696005)(53546011)(6506007)(966005)(5660300002)(9686003)(2906002)(8936002)(3480700005)(508600001)(81166006)(55016002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR22MB1916; H:DM6PR22MB2010.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: R5TACbKr2gvFhUAt3R1KUTuIaKfaI1fOQGwwceKp+tYydYPtAlk6UdhFCTJhjK6OKK5CNgDPmmqL2ONdkxPI91N6mLVWYLU8t2MjKIVg7fZcl4kw7E1IrD8e2O/I2yBq+VDD5MntGspE7nSnaThNsJj3dZNL5BzL8eEFgZ0Aq5GSMy96/PzCGfbOGRZIKaEt+XvZnNXjq/yIKMfpcItBGDadxaB7/BNOFkgyFeE2KLc/4NN3MQ0pIkjngMv+HN+7q925N35/WwuSgtAZzemIiWbpI6KTinafxnutvwaEPaI5gCu5HPHA09qwIIa4sq+0I0ckmgg718rAeFqRDhRNlRnl1T7vipQbVexjAfaDoV+kQxshJCBKqH0FjWQHO3VCtZRW99UlkFXMVdNSWdTJqGzjceCeFeP5/zjbLJBg24H8f8ayOrM2wsecRBjXiTG4PjTGNGo6F0SOoNh92eanreXkl7SEmFQSjvNZj4lQ7ii5p6wi3TfiAUU9EWU8faIyyvYrGWt+l8UhZgMU5yBNSlnmS32WYiVQ9F//2fSM7VA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a7ccd1c-2279-40f3-3b14-08d783142c92
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2019 17:11:36.5554 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: p9aGnfFMsxayRngCvM5nlzCXAStr5M96OgDV0NVdEpCE21TNKTHdixb4F9RXYsbx6NcM1Xn5U4d0Xfp+6WX22w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR22MB1916
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FVPJ_7U4VBI5PziEnks6CFVlEb0>
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: Tue, 17 Dec 2019 17:11:42 -0000

I think I would approach this a little differently.  I understand the desire for caution about letting extensions derail the core documents, but I'm hesitant to require another recharter to adopt more extensions.  Perhaps we could consider something more like HTTP/2 did, permitting us to work on extensions only to the extent that they don't delay our work on the core documents.  Or explicitly list the extensions we're allowed to adopt before RFC publication.

I understand the current plan is for two recharters, and maybe they're lightweight enough that that's fine.  I'm just unenthusiastic about having to agree on the exact set of extensions we're allowed to discuss before we can formally discuss any of them.

-----Original Message-----
From: QUIC <quic-bounces@ietf.org> On Behalf Of Mark Nottingham
Sent: Thursday, December 12, 2019 1:58 AM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Re-chartering for extension work



> On 12 Dec 2019, at 9:35 am, Jana Iyengar <jri.ietf@gmail.com> wrote:
> 
> Mark,
> 
> I'm supportive of changing the language in the charter. 
> 
> When we wrote the charter, the intent was to preclude work that might have interfered with getting the important work of the core protocol done, and the things we could think of at the time were partial reliability and FEC. That's clearly an incomplete list, as we can see with the extensions that are being proposed.
> 
> I am supportive of the new language you propose.
> 
> That said, I'd like to tease something out. If I understand this correctly, the charter as it is allows for at least one of the currently proposed extensions to be adopted -- the version negotiation extension. Under the proposed language, we couldn't have adopted this extension since it wouldn't have been on a list of extensions. The rest of the charter talks about focus areas, not about specific documents and extensibility mechanisms. The proposed text lists extensions, which means that any extensions, even minor ones, will require a recharter. This is a tightening of the charter, which I support.
> 
> If my understanding is correct, I would hope that we remain open to rechartering as and when the wg agrees on adoption of new extensions.

That's the intent, yes; while eventually we might open up, we want to be deliberate about adding new work items while we're still focused on QUICv1.

Cheers,


> 
> - jana
> 
> On Wed, Dec 11, 2019 at 1:38 PM Mark Nottingham <mnot@mnot.net> wrote:
> 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/