Re: Proposed Charter Text

Jana Iyengar <jri.ietf@gmail.com> Tue, 28 January 2020 00:28 UTC

Return-Path: <jri.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 AD2B03A11A4 for <quic@ietfa.amsl.com>; Mon, 27 Jan 2020 16:28:59 -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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 DJjIxDyTHS5H for <quic@ietfa.amsl.com>; Mon, 27 Jan 2020 16:28:57 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 844BE3A11A3 for <quic@ietf.org>; Mon, 27 Jan 2020 16:28:56 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id z18so7713232lfe.2 for <quic@ietf.org>; Mon, 27 Jan 2020 16:28:56 -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=7gYHuq3XvL3KWQ9n8mApxfTOPeIuDzlYukJrDQG1e1M=; b=LwMh7eV35v35I1MjEWLLHnV2fPV/w0exA3EJvcFRgq775mxNBYhWuvY5OYbOukP8p0 VuDCKCWtlQJcMhnyGHPcc6C9mXcP+5kULfxyOULL1PQJf0Hr7mo0TAAFrEm06NwrStnS 7bGbYaK8gh7XALdNrZL8uoF/k37QOsozQISHqfloY9yC9TLFpnBGdCNvcDt068GHuAEQ ph6SkcWAqcJ/7u2WCu0cVrK+Sn4oH2F27cS0Lfgx/e5Jv2InQQnuwD7bSsbrxejzJWwG Xidw/2ur+wjJmReBpqMxuWTA1wYPuaiixbbq49eT/ff8Fa0FrA/7LqkdDgZLnNC4m/6S NTCg==
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=7gYHuq3XvL3KWQ9n8mApxfTOPeIuDzlYukJrDQG1e1M=; b=oTP2POXKIig9gotoPsGaPSe/7/n3GpW+08isAMThVrc9AwEOuKtAl9azgSE+ELQvA1 OZ8m4EY2yhdWVkFhwZHW3xaYe4xiahYQSmKRXmmkCbYNJ2QN6agbKWxWPLtSDHAS96aO kCEFsRfB7Ijz507xEidQY7uf9WO+KCbr+tm0S8OGy6RyWtfGRdvNdigeFoPLERIk346p TqwplHlGt0FcZnsUNN28NiqZ7key5G8/3n1Jfl2+Cv7sx1T6QtMf2pFqm96aISYaqVgg 6MFwYv52ullDWll7uVb0d7Gnqhw2i1ELGt7Qgiq69h5MmgycIGWd8q4jxebh+l9sSnm0 Vm1g==
X-Gm-Message-State: APjAAAVTIlwLSTN2KWHCspK6jAFBWZabvqHPUdWBnoOJaaD63Pgcdp6E KSnfbfkYdMn7jT9f97vLb+u6GUa6x9BBY/hoYTM=
X-Google-Smtp-Source: APXvYqztwF8pRPVXKDwGusgi7U5WK3tZWzFYj3pgDGn5ewoFa5TvbguckiCYMVOD0WzL9Sw87XkJccEedlyrddJgoPU=
X-Received: by 2002:ac2:58c2:: with SMTP id u2mr715403lfo.206.1580171334408; Mon, 27 Jan 2020 16:28:54 -0800 (PST)
MIME-Version: 1.0
References: <ff12ef2fd1890c0bed636007f9e99e37b6b9c463.camel@ericsson.com> <c5b083a96cd718d4a77ba11bb214aebc407147b8.camel@ericsson.com> <CAKcm_gPQ3J=FyW248Vuu0zj_tRe_y11bs1vj_-8Y=n+F2ufiKQ@mail.gmail.com> <CH2PR22MB20862FBAA90E983E1B526B5BDA0B0@CH2PR22MB2086.namprd22.prod.outlook.com> <F72844E5-978A-48D3-A3B9-EE40F8F9B3F8@fb.com> <CH2PR22MB20863A220AAA21A4289C1BC1DA0B0@CH2PR22MB2086.namprd22.prod.outlook.com>
In-Reply-To: <CH2PR22MB20863A220AAA21A4289C1BC1DA0B0@CH2PR22MB2086.namprd22.prod.outlook.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Mon, 27 Jan 2020 16:28:43 -0800
Message-ID: <CACpbDcdt17Dk+3_N_+pzQRHfJWJuVZ66x1uaW-6v92cBn2dCZQ@mail.gmail.com>
Subject: Re: Proposed Charter Text
To: Mike Bishop <mbishop@evequefou.be>
Cc: Roberto Peon <fenix@fb.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000125cdf059d284f51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/fDjMzLQ1rklnbSnIzNU2FBmeYx4>
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, 28 Jan 2020 00:29:00 -0000

Looks fine.

Since you've made broader changes, some nits on the rest of the text:

- "Upon completion of that mapping, additional protocols may be added by
updating this charter to include them, or working elsewhere." This sentence
does not make sense anymore. What is that "or working elsewhere" supposed
to be adding? Should this phrase be dropped?

- The fifth focus area should be described _after_ the paragraph starting
with "Current network management practices", since that para is related to
the fourth focus area.

- In the fifth focus area, "the Working Group will delivery a mechanism to
assist load balancers in their handling of QUIC."
  First, a nit: "delivery" --> "deliver".
  Second, perhaps I'm wrong, but I don't remember that we agreed
to deliver a "mechanism" for this. A more inclusive phrasing here might be
"will deliver solutions for load balancers to handle QUIC traffic."

- Final nit that has already been noted, "the QUIC mapping for HTTP/2". If
we are going to touch that text, let's change it to "the QUIC mapping for
HTTP". I agree with Mike that we've used HTTP/2 as the effective API that
we're building to, but I think that purpose has been served. I don't we're
in danger of veering way off-course on the HTTP mapping from HTTP/2, if
only for pragmatic reasons.

On Mon, Jan 27, 2020 at 1:32 PM Mike Bishop <mbishop@evequefou.be> wrote:

> Per previous thread, the intent is a small recharter to permit working on
> the extensions we believe need to be “with or not long” after the main
> drafts, while we finish up those core documents.  Once the core documents
> for v1 have actually shipped, we’ll be open for a larger recharter.
>
>
>
> I previously expressed my preference to do the larger recharter now, but
> the chairs and AD would rather ensure we don’t lose momentum on v1.
>
>
>
> *From:* Roberto Peon <fenix@fb.com>
> *Sent:* Monday, January 27, 2020 4:28 PM
> *To:* Mike Bishop <mbishop@evequefou.be>; Ian Swett <ianswett=
> 40google.com@dmarc.ietf.org>; Magnus Westerlund <magnus.westerlund=
> 40ericsson.com@dmarc.ietf.org>
> *Cc:* quic@ietf.org
> *Subject:* Re: Proposed Charter Text
>
>
>
> Quite frankly, if we’re proposing to allow extensions for datagrams, but
> not partial reliability, I don’t understand the motivation and I won’t
> support it.
>
> Is that the case here, ‘cause we’re not explicitly talking about it at all
> with the proposed change?
>
> -=R
>
>
>
> *From: *QUIC <quic-bounces@ietf.org> on behalf of Mike Bishop <
> mbishop@evequefou.be>
> *Date: *Monday, January 27, 2020 at 10:06 AM
> *To: *Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Magnus Westerlund
> <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
> *Cc: *"quic@ietf.org" <quic@ietf.org>
> *Subject: *RE: Proposed Charter Text
>
>
>
> This is true, but has also been a useful guide to our work on HTTP/3.  As
> you note, “HTTP/2 semantics” isn’t really a thing – HTTP/2 is a mapping of
> HTTP semantics over TCP – but we’ve interpreted this as saying that HTTP/3
> by default has the same feature set as HTTP/2.  We’ve required consensus in
> both QUIC and HTTP working groups to deviate from that (e.g. priorities).
> Clarifying that language wouldn’t be inappropriate, but also isn’t closely
> bound to the point of this update.
>
>
>
> Depends how much we want to fix existing text, just like any other PR, I
> suppose.  😊
>
>
>
> Other feedback:
>
>    - Formatting nit:  Your “key goals” bullet points are folded into a
>    single mishmash paragraph
>    - With the removal of the mention of the initial documents, do we need
>    the discussion about how we decide what to keep/change from those initial
>    documents?
>
>
>
> *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of *Ian Swett
> *Sent:* Monday, January 27, 2020 9:25 AM
> *To:* Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
> *Cc:* quic@ietf.org
> *Subject:* Re: Proposed Charter Text
>
>
>
> Thanks for the update.  The original charter mentions HTTP/2 multiple
> times, but except for when it's in reference to extensions, I think it
> would be preferable to use HTTP instead of HTTP/2.  For example, "The first
> mapping will be a
>
> description of HTTP/2 semantics using QUIC," and  "especially on the QUIC
> mapping for HTTP/2" are quite odd now that HTTP/3 is it's own thing which
> shares very little with HTTP/2.
>
>
>
> And two small comments below.
>
>
>
> Ian
>
>
>
> On Mon, Jan 27, 2020 at 9:07 AM Magnus Westerlund <magnus.westerlund=
> 40ericsson.com@dmarc.ietf.org <40ericsson..com@dmarc.ietf.org>> wrote:
>
> Hi,
>
> Due to the reshuffeling it may be hard to see exactly what is changing. So
> to
> clarify in text what is being changed.
>
> The big change is to allow work on three "extension": Version Negotiation,
> datagram (these two are listed under fourth focus area) and how to better
> support load balancers (fifth focus area).
>
> Otherwise the changes are:
> - removal of the initial input drafts to base the work on in first
> paragraph.
> - Reshuffling of the paragraphs, the one "current practices for network
> management ..." is moved down.
> - Removal of pragaraph regarding interim during first year.
> - Removal of stand alone paragraph preventing extension work. The no other
> extensions is now baked into paragraph on fourth focus area.
> - Clarification that mapping work may also be done outside of QUIC WG.
>
> Cheers
>
> Magnus Westerlund
>
> On Mon, 2020-01-27 at 12:22 +0000, Magnus Westerlund wrote:
> > WG,
> >
> > Below you will find the draft charter text proposed by ADs and WG
> chairs. I
> > intended to have the IESG agree to send this out for External Review at
> the
> > next
> > IESG meeting (2020-02-06). So if you have any comments and proposal for
> > changes
> > now is a good time.
> >
> > Below is a copy of the current draft in the datatracker:
> > https://datatracker.ietf.org/doc/charter-ietf-quic/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_charter-2Dietf-2Dquic_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Oxj1kvN-LjOkmr3LdrkicI0j3dYN4OJ9MubaLhrPTio&s=tCGdU8vOsfsd2Z93vRiTrTNHpvg7aH-w1UUkC5HUtbw&e=>
> >
> > Diff:
> >
>
> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-01-00.txt
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl1-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fcharter-2Dietf-2Dquic-252Fwithmilestones-2D01.txt-26url2-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fcharter-2Dietf-2Dquic-252Fwithmilestones-2D01-2D00.txt&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Oxj1kvN-LjOkmr3LdrkicI0j3dYN4OJ9MubaLhrPTio&s=zwde8IigreGbeTV4UygZyuNjtORKPz4DKDHe3qW8Nm8&e=>
> >
> > QUIC WG Draft Charter (01-00)
> >
> > The QUIC working group will provide standards-track specifications for a
> > UDP-
> > based, stream-multiplexing, encrypted transport protocol, based on
> > pre-
> > standardization implementation and deployment experience.
> >
> > Key goals for QUIC are:
> >
> > - Minimizing connection establishment and overall transport latency for
> > applications, starting with HTTP/2; - Providing multiplexing without
> > head-of-line blocking; - Requiring only changes to path endpoints to
> enable
> > deployment; - Enabling multipath and forward error correction
> extensions; and
> > -
> > Providing always-secure transport, using TLS 1.3 by default.
> >
> > The work of the group will have five main focus areas, corresponding to
> five
> > core deliverables.
> >
> > The first of these is the core transport work, which will describe the
> wire
> > format, along with the mechanisms for connection establishment, stream
> > multiplexing, data reliability, loss detection and recovery, congestion
> > control, and options negotiation. Work on congestion control will
> describe use
> > of a standardized congestion controller as a default scheme for QUIC.
> Defining
> > new congestion control schemes is explicitly out of scope for this
> group. QUIC
> > is expected to support rapid, distributed development and testing of
> features.
> >
> > The second of these focus areas is security. This work will describe how
> the
> > protocol uses TLS 1.3 for key negotiation and will also describe how
> those
> > keys
> > are used to provide confidentiality and integrity protection of both
> > application data and QUIC headers. This work will ensure that QUIC has
> > security
> > and privacy properties that are at least as good as a stack composed of
> TLS
> > 1.3
> > using TCP (or MPTCP when using multipath).
> >
> > The third focus area will describe mappings between specific application
> > protocols and the transport facilities of QUIC. The first mapping will
> be a
> > description of HTTP/2 semantics using QUIC, specifically with the goal of
> > minimizing web latency using QUIC. This mapping will accommodate the
> extension
> > mechanisms defined in the HTTP/2 specification. Upon completion of that
> > mapping, additional protocols may be added by updating this charter to
> include
> > them, or working elsewhere.
> >
> > The fourth focus area will be on extensions to core protocol facilities,
> to
> > enable datagram delivery, version negotiation, and multipath
> capabilities..
> > Other extensions are out of the scope of this charter.
> >
> > The fifth focus area will provide an Applicability and Manageability
> > Statement,
> > describing how, and under what circumstances, QUIC may be safely used,
> and
> > describing deployment and manageability implications of the protocol.
> > Additionally, the Working Group will delivery a mechanism to assist load
> > balancers in their handling of QUIC.
>
>
>
> delivery -> deliver
>
> >
> > Current practices for network management of transport protocols include
> the
> > ability to apply access control lists (ACLs), hashing of flows for
> equal-cost
> > multipath routing (ECMP), directional signaling of flows, signaling of
> flow
> > setup and teardown, and the ability to export information about flows for
> > accounting purposes. The QUIC protocol need not be defined to enable
> each of
> > these abilities, or enable them in the same way as they are enabled by
> TCP
> > when
> > used with TLS 1.3, but the working group must consider the impact of the
> > protocol on network management practices, reflecting the tensions
> described in
> > RFC 7258.
> >
> > Note that consensus is required both for changes to the current protocol
> > mechanisms and retention of current mechanisms. In particular, because
> > something is in the initial document set does not imply that there is
> > consensus
> > around the feature or around how it is specified.
>
>
>
> I think the above paragraph should now be removed.
>
>
>
> >
> > The QUIC working group will work closely with the HTTPbis working group,
> > especially on the QUIC mapping for HTTP/2.
> >
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079
> <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>