RE: Re-chartering for extension work
"Lubashev, Igor" <ilubashe@akamai.com> Thu, 12 December 2019 01:15 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 BECBA1200F8 for <quic@ietfa.amsl.com>; Wed, 11 Dec 2019 17:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=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 qn8l9G16oqBM for <quic@ietfa.amsl.com>; Wed, 11 Dec 2019 17:15:02 -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 CABD61200F7 for <quic@ietf.org>; Wed, 11 Dec 2019 17:15:02 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBC1EZbN017688; Thu, 12 Dec 2019 01:14:56 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 : mime-version; s=jan2016.eng; bh=iS1DlNkZilQK4TYzAuTdNJLKbb8/Pnn66VFmGg3nhCo=; b=eru380k7KJeixS/3M0fSZbMdo9OilkQVYM1A4SdY5KueT7ueThKlvNDU5o3kTHJ4iSUo jcVixcYvrBJsu7OKmvxMLRgWnodnjrxP1E47g1/oPknWPviecTEzNM4pkpGK7Ualb6N5 T+CKf/6HQj4Z3/idGr5TpxZQPbxcfPM5FrEq18M1NVJqYOnGAwvX03pzZeSMwrf57dFt q6ysdCdSIpae1BTrxzxM5nJZhnmFYOtAY5GufQ1MGFSwVyIH9a+hNiGK6YpYvzoTaMIq kgcicl6gLW9mlAVtInA96mge0SOS2IukgXAjrIIP+lz2vJBjGy/ze5EZc1dHyelaNvG+ lA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2wu7wkgra0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Dec 2019 01:14:56 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBC14BAt006281; Wed, 11 Dec 2019 20:14:55 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wr8a13rn3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 20:14:55 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 19:14:54 -0600
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Wed, 11 Dec 2019 19:14:53 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Jana Iyengar <jri.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>
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: AQHVsGtbz4hcPwmxz0WVLe+SyklylKe16m2A///A8LA=
Date: Thu, 12 Dec 2019 01:14:53 +0000
Message-ID: <d3c537ffdd5348df98099017363b4352@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <CACpbDcdaQGmSGvb+skNEenEuMXESPi1sFPs5Bi_YwvdQzawD1w@mail.gmail.com>
In-Reply-To: <CACpbDcdaQGmSGvb+skNEenEuMXESPi1sFPs5Bi_YwvdQzawD1w@mail.gmail.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.113.178]
Content-Type: multipart/alternative; boundary="_000_d3c537ffdd5348df98099017363b4352ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-11_07:, , 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-1912120001
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-11_07:2019-12-11,2019-12-11 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 impostorscore=0 clxscore=1015 mlxscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912120003
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/msb6aR9eROt02czLWTbjJv-BwbY>
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 01:15:05 -0000
Mark, How would the WG operate with the proposed charter? If there is a proposed extension work that is not already named in the charter, it is out-of-scope and cannot be adopted (and hence a Call for Adoption cannot be made). But updating the charter would require naming the proposed extension that has not, yet, been adopted. Would we be replacing a Call for Adoption with a Call for Charter Update? This seems to invite a confusion in the process. I understand that we want to protect our ability to deliver QUIC v1 ASAP. Would it work to state explicitly in the charter that QUIC v1 (and HTTP binding) work will always have a priority over extensions in allocating WG meeting time at IETF meetings and interims? * Igor On Wed, Dec 100 at 2019 5:36 PM, 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. - jana On Wed, Dec 11, 2019 at 1:38 PM Mark Nottingham <mnot@mnot.net<mailto: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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_wg_quic_about_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=rk0iVRG56sOYkHN38optDbyqD46-Xipkv0G_Fq5xzXg&s=MoD-CaRMGGLqvBj7zU7nMUSRSK25lnl3xR6jMFXtGgg&e=> -- Mark Nottingham https://www.mnot.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=rk0iVRG56sOYkHN38optDbyqD46-Xipkv0G_Fq5xzXg&s=FI__zKN--MpO5urwCLnWVnP16lhh3L5cWMY2QWHYou4&e=>
- Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Jana Iyengar
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Salz, Rich
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Multipath (was: Re: Re-chartering for extension w… Lars Eggert
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Christian Huitema
- RE: Re-chartering for extension work Mike Bishop
- RE: Re-chartering for extension work Kuhn Nicolas
- Re: Re-chartering for extension work Ian Swett
- Re: [EToSat] Re-chartering for extension work Christian Huitema
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Multipath (was: Re: Re-chartering for extensi… Florin Baboescu
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Multipath (was: Re: Re-chartering for extensi… Ryan Hamilton
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Jana Iyengar
- RE:(2) Multipath (was: Re: Re-chartering for exte… Madhan Raj Kanagarathinam
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Lars Eggert
- RE: Re-chartering for extension work Roni Even (A)
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Kuhn Nicolas
- RE: [EToSat] Re-chartering for extension work Kuhn Nicolas
- Re: Multipath Gorry Fairhurst
- Re: Re-chartering for extension work Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Tommy Pauly
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- RE: Multipath (was: Re: Re-chartering for extensi… tim.costello
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Lucas Pardue
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Tommy Pauly
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Eric Rescorla
- Re: QUIC re-chartering: include DNS-over-QUIC? Ted Hardie
- Re: QUIC re-chartering: include DNS-over-QUIC? Jari Arkko
- Re: QUIC re-chartering: include DNS-over-QUIC? Magnus Westerlund
- Re: QUIC re-chartering: include DNS-over-QUIC? Stephen Farrell
- Re: QUIC re-chartering: include DNS-over-QUIC? Christian Huitema
- Re: QUIC re-chartering: include DNS-over-QUIC? Daniel Migault
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Christopher Wood
- Re: QUIC re-chartering: include DNS-over-QUIC? Ian Swett
- Re: QUIC re-chartering: include DNS-over-QUIC? Vidhi Goel
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Duke
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Mikkel Fahnøe Jørgensen
- Re: QUIC re-chartering: include DNS-over-QUIC? Lucas Pardue
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Thomson
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie