Re: Re-chartering for extension work

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 19 December 2019 09:16 UTC

Return-Path: <magnus.westerlund@ericsson.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 5F13B120227 for <quic@ietfa.amsl.com>; Thu, 19 Dec 2019 01:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_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=ericsson.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 0mnY84D97u9v for <quic@ietfa.amsl.com>; Thu, 19 Dec 2019 01:16:18 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30054.outbound.protection.outlook.com [40.107.3.54]) (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 9554E12021D for <quic@ietf.org>; Thu, 19 Dec 2019 01:16:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k5J/o8tD7Dqfi6dOi58UHfpRcLif4/Bqb947nSl4rPVupapcmPurx7TII/Dc8BecBI5gZ1maNRPfoCUiHwaYZ6rVul7omtZ1lMD4DloEp9IQ4fKBJBcOKg0K2W8t1UHN9om85+BsbmOmzcG8rwQJ069QR3GzR8MuSt6WVQ1tkSvWwjdys3sbj48qcL1B31PLTCUmi2wNTCUS4aFRHSWxAN71j1/E/5ziuAQBQb+kqXxl1A019ySbOFx+4K2G6cnDxKjX3mfnrQd+pWNr//0sPh5kde7t3CW3DLIcs5PBWyyxU5E+A480lNGY/nO4uq2IAkI3sJKe2e5E+EQdLP5G2w==
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=5le1jGtYXRIe4lw4nSUyorEg+UzPEnD6q7WQe7G3s8c=; b=c6HJu1FQqlP5zBA0yLuWhjb+3lTc6tGt2kfBE3z6sbjoTYoKQTi4R7dbQWPxgaYbtIOM4FKU124yrFLIn7hGJKlZyuOSPcxAzqM6ca4+8h7bdWbdnBJAj+Erp9R0/of0u/Hzerpr3FPgPXaFb6RfPA2qvW+iD6YVdK0wPEN/Y0I7amJn1VlMwzb7v1t/ruHCHNs61daTY1RGAn2PC8ioVU2VpmbitVjFudRx3QU2IBNu2RyctZIPgLnfUJ+WsEUI3QU3+tnLO/MyLrcThriU08Dlw5zFA/UpThcow4aTdtxSn6mWB87lfN1w2UV5kA100Yx3i238Ma4nowNBXGeWeQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5le1jGtYXRIe4lw4nSUyorEg+UzPEnD6q7WQe7G3s8c=; b=W9nGSafDPFicog92/jt+1x0yM1n5Rf6p+JI7DoG+xs7FFfkblLJXbLb+79G0sSfYH6vchtbTiBap0v6hh6iW+ljaVbtN/qBO6BK1pCf/lowVQFg2U2x5384OFXRReIvCisB7mrwd4AuCuAa10Yavfqi6XDFujL7yJUJ4sYdBhDg=
Received: from VI1PR07MB5310.eurprd07.prod.outlook.com (20.178.12.13) by VI1PR07MB5248.eurprd07.prod.outlook.com (20.178.9.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.12; Thu, 19 Dec 2019 09:16:15 +0000
Received: from VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64]) by VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64%4]) with mapi id 15.20.2581.005; Thu, 19 Dec 2019 09:16:14 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "roni.even@huawei.com" <roni.even@huawei.com>, "jri.ietf@gmail.com" <jri.ietf@gmail.com>
CC: "mnot@mnot.net" <mnot@mnot.net>, "ilubashe@akamai.com" <ilubashe@akamai.com>, "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: AQHVsGthvrPnRGuak0uJGGF6+agGyae2D8QAgAAC9YCAAAPbgIAAAG8AgAAHYACAABf9gIAADEGAgABrEACACVYLAIAAT5cAgACPuQCAADMlgIAAIt0A
Date: Thu, 19 Dec 2019 09:16:14 +0000
Message-ID: <0c4176d76e2f8078c877ea1693e5c0a69b7dba9a.camel@ericsson.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> <CACpbDcedzKCEEH=4=Sjw8E8j7yGGsmUp5P+t6JHwi_5Dv9brMA@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD27D36559@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD27D36559@dggemm526-mbx.china.huawei.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8538412f-2cb9-4d49-366e-08d784641929
x-ms-traffictypediagnostic: VI1PR07MB5248:
x-microsoft-antispam-prvs: <VI1PR07MB52483C7E2488091046A75C6A95520@VI1PR07MB5248.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(136003)(376002)(346002)(51444003)(51914003)(13464003)(199004)(189003)(66476007)(64756008)(110136005)(8676002)(6512007)(66446008)(4326008)(71200400001)(66556008)(4001150100001)(36756003)(2616005)(8936002)(76116006)(316002)(91956017)(6486002)(66946007)(54906003)(44832011)(26005)(186003)(5660300002)(66616009)(81156014)(53546011)(6506007)(966005)(3480700005)(2906002)(478600001)(30864003)(81166006)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5248; H:VI1PR07MB5310.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 38DNlk8jTGy49UXifLR+er/mWzozthkrWBMwnxXZIoHqZdq/ySS2vI2r4YyhzlwQMqCvKNYlsznS+etDPGmxSy1LP62umMtTlOMZum4YuDMgHdP5J/d2YafmkzdkVw+0z9LcsrAd050kDaraTP8TTpZsdJKbqk9GCdlcJLfWKcIdkpZ3XM/b91n0GIns/EyO+ydSu0Us5NE0U1nV6naKotj8q3XV/uVNqiSGfpjTQxZbBI9r3wZVI3Z/iJtZQVPBdvKRlQW+GLUWQtehhGOkwIwfNWpmwy+8gakfBnmPqzrZjkU/Z3eLKeVhaNAEUYNK1rcE9sQ1cOn6jyNtJ6TiLKrjH6mB3rC0NR9H6lKfcFqjO5sQ0ZtIpE1Mzgb4c6OX8nDqEVLfwdic/augYQFyAt+yk9rxZPel5LMyK/UmSkLFBUPbcEzn/7Wo5JCFz3Io0qyZnsAVmFYvNGTv8ahzRXRatLnCIWgc5Y06+BCDAdTuxZLUMC9YxfmPRvvGHsLaRAcDp+l1W6HRWGx8BBA3UbaVzTPxZ0Ef2XFLOZXPg6qZz2UlNhqmBiYzYvEdAnjrKalH2EMJtmZxq3juj4IKeg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-98odpWgv2Ep0xxekHvjz"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8538412f-2cb9-4d49-366e-08d784641929
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2019 09:16:14.8782 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WzMSRulSnLr0FvRS7Ud7pXnBT/P4IiNLjRb2rexbzlwKsU+4QECLdJxd59MgPIWwCv+voIvrbwJIS4Jd5idqqPaVTKB2F4MM9X2WTOVlW5Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5248
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AJMV6s5HfAQuwYm3ZP7xVSo4iIU>
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, 19 Dec 2019 09:16:21 -0000

Roni,

The current charter does not allow us to do some of the proposed near term
additional work, especially datagrams. Thus, we need to do something about the
charter if we are going to do that work at all. At the same time it does not
appear to be the right time either to have the bigger discussion of how the next
longer term charter should look like. 

I understand you are arguing for that it should be in the WGs discression to
adopt extensions to QUIC. From my perspective it is not that simple, as we need
to put wording in to delimit that work in a reasonable way. As AD I need to
understand how we handle work that have sufficient interest but may not fit the
next steps of QUIC WG. This requires some though and coordination with other
areas also, especially ART. It is also only since Singapore we gave the message
that extensions and other new work will be possible to consider going forward.
Thus, I also want to give people some time to make their proposals if they
haven't already due to we having said not yet, please wait. I do expect us all
to have a firmer understanding of the situation at the next meeting. We will
hoepfully also know better how much work remains on QUIC v1. 

It is my decision as the responsible AD to do this in two steps. First a minimal
recharter to allow for the work that the adoption call is done for. Later next
year we will have the bigger recharter discussion. 

And yes the current set of three work items being proposed for adoption and
rechartering have been picked by the chairs and the ADs based on relevance,
interest in the work from the WG, expectations on how it can be completed, and
that it will not significantly impact the QUIC v1 progression. Yes, this may not
be the most open process, but the alternative from our side is to delay adopting
any additional work until we can fit that bigger discussion. I at least don't
see that as good either. If the WG participants would prefer such a process you
are welcome to speak up and object to the recharter. 

Cheers

Magnus Westerlund
TSV AD

 

On Thu, 2019-12-19 at 07:11 +0000, Roni Even (A) wrote:
> Hi Jana,
> The loss bit is an example, there are multiple individual drafts in the QUIC
> document list and I think that naming extensions in the charter is not the
> right direction.
> As for the management, not being a lawyer, the charter text say consider the
> impact not about addressing the impacts or extending the protocol.
>  
> Roni
>  
> From: Jana Iyengar [mailto:jri.ietf@gmail.com] 
> Sent: Thursday, December 19, 2019 6:08 AM
> To: Roni Even (A)
> Cc: Magnus Westerlund; mnot@mnot.net; ilubashe@akamai.com; lars@eggert.org; 
> quic@ietf.org
> Subject: Re: Re-chartering for extension work
>  
> Roni,
>  
> The charter will retain the part that allowed discussion of this work in the
> working group so far:
> "the working group must consider the impact of the protocol on network
> management practices, reflecting the tensions described in RFC 7258"
>  
> Work obviously does not need to be adopted for it to be discussed. It needs to
> be covered in the charter, which this is.
>  
> - jana
>  
> On Wed, Dec 18, 2019 at 11:34 AM Roni Even (A) <roni.even@huawei.com> wrote:
> > 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-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
> > > >
> > > >
> > > --
> > > 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
> > > ----------------------------------------------------------------------
> > >
> > 
-- 
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
----------------------------------------------------------------------