Re: Re-chartering for extension work

David Schinazi <dschinazi.ietf@gmail.com> Fri, 13 December 2019 00:10 UTC

Return-Path: <dschinazi.ietf@gmail.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 05C5D12012E for <quic@ietfa.amsl.com>; Thu, 12 Dec 2019 16:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 4uvr783smItp for <quic@ietfa.amsl.com>; Thu, 12 Dec 2019 16:10:46 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222CD120090 for <quic@ietf.org>; Thu, 12 Dec 2019 16:10:46 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id m6so579068ljc.1 for <quic@ietf.org>; Thu, 12 Dec 2019 16:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ANg7BchmZ0DK4rtWTHqfZKrE5vJvZwlFj6Y8t4kSpb4=; b=UHCbAOzFxZml9gPkVPfF10z1AfChrzUZtqWjfdQNhbuGoWl0FpOu+3SQB0Kx4LDbSU o9tQQH6Ggv2ajHUa+6kNVV53tEhczglSenQ++IqwbMfeuK9tCVF40RO9BP9MmxO/AGYC E8hTaES7RgpQqziMmROFeNca7hvV68QHGdZcsXW+Tr73HKInxwPjUX5KGArHZP35yCzf nVeaWbTth/qXtNNLToXZXCrfSLs6aVpkyizJv1kBzGDnxVGIuClOL6oR04qt55mXflDG F408xmuz/C39Y2IwsG6uV7xooUB2wPUhJ3rBxTI0Q2lnjQFyPpe2G5kJFFBcqS9u14Q0 8XEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ANg7BchmZ0DK4rtWTHqfZKrE5vJvZwlFj6Y8t4kSpb4=; b=snA0MGis4REbdNRFSwJ5Hw76E9VJADl59YVtExpQhsgM2rEVlTC0fwItU1Zcbcptiw yWYb672oNbE56CFLOfgvhPy5QbTRqcQHRKAb+MqAQt7TG1vZxXPpc5VCw+x+s+MiAbbg Y/oLQ5+x3wJc+MSccE+XLDzWizV9j6wECNJlEF3hcbPUhufYSRreOr4q48zQ84ioyiY8 6XnXAwno958zYR+E5MGqOAHvkW8wH1g+OH+FKnADGQFeMBgkjQYP+aaweBqllGlW2aEf OUaBQhpTkzAm/UVhGPGwkqz9I5d884ExcRsRECvqzholyrSvwI/9vOsotg+YRWha73Wt UaFg==
X-Gm-Message-State: APjAAAWvfk/mijudp7tCLgRsXL2J7PgHbKGkAFKybka+no5N6DQfq8xI wMxe7VIbKr3gs5h33aRaKmNTqrMuQr3BqKfGMwI=
X-Google-Smtp-Source: APXvYqw+pcmJiNPmhLuUMjMch22+sDGxhRRTEdQPEFPT6AkRaPvwM+/kWQj55k+uNiZz9Z4iuF/A07jl/Hy8jXVcxSw=
X-Received: by 2002:a2e:914d:: with SMTP id q13mr7758879ljg.198.1576195844248; Thu, 12 Dec 2019 16:10:44 -0800 (PST)
MIME-Version: 1.0
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> <CAPDSy+65DX4havw8DScDeQv5TEwrms+5cH3hz5Qb-bep-hagaw@mail.gmail.com> <AD10DCC8-D8DF-451E-B89F-62C7EEE01E49@mnot.net>
In-Reply-To: <AD10DCC8-D8DF-451E-B89F-62C7EEE01E49@mnot.net>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 12 Dec 2019 16:10:32 -0800
Message-ID: <CAPDSy+6O7OgrDY4tiCj9_6Y+=htm9GR7FDkR9ej58jZWygmNWA@mail.gmail.com>
Subject: Re: Re-chartering for extension work
To: Mark Nottingham <mnot@mnot.net>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Lars Eggert <lars@eggert.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006497e505998ab1f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sq_d8cBm_93WicVi24r_erghQ_c>
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: Fri, 13 Dec 2019 00:10:50 -0000

On Thu, Dec 12, 2019 at 3:19 PM Mark Nottingham <mnot@mnot.net>; wrote:

> > On 13 Dec 2019, at 7:50 am, David Schinazi <dschinazi.ietf@gmail.com>;
> wrote:
> >
> > In general, I'm very supportive of rechartering to allow these new
> extensions.
> >
> > I'd prefer to have the charter just allow all extensions, and then use
> the WG call for adoption consensus process to decide whether extensions are
> in-scope at a given moment in time or not. But if the chairs/ADs think that
> is too broad I can live with only opening up for specific topics.
> >
> > One important problem though, is in the DATAGRAM case, the topic of flow
> identifiers. Earlier, draft-pauly-quic-datagram-03 contained flow
> identifiers. Based on community feedback, the authors removed them from
> -04, and moved them to a separate draft-schinazi-quic-h3-datagram. I'll
> admit that draft-schinazi-quic-h3-datagram is still very immature, but with
> the new charter, I want to make sure we don't end up in a state where we
> can discuss draft-pauly-quic-datagram but not
> draft-schinazi-quic-h3-datagram. Some folks feel strongly that flow
> identifiers should exist, and if we tell them that they're not in scope of
> the WG they might be sad.
>
> It's good to know about these requirements, and of course once the
> document is adopted, we can discuss issues against it. However, if you want
> to discuss datagrams in HTTP/3, we need to have a discussion about whether
> it'd be more appropriate to do that in this WG or in the HTTP WG --
> remembering that once HTTP/3 ships, it takes over maintenance of that spec.
>

Thanks, that makes sense to me. Happy to take
draft-schinazi-quic-h3-datagram to HTTPBIS (or will it be HTTPTER ?). Just
wanted to make sure that discussing it in context
of draft-pauly-quic-datagram is OK.

David


Cheers,
>
> >
> > Because of this, I think the new charter should discuss topics as
> opposed to specific draft names (which is what I assume Mark meant by [
> adopted extensions ] )
> >
> > David
> >
> > On Thu, Dec 12, 2019 at 8:15 AM Lubashev, Igor <ilubashe@akamai.com>;
> 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
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>