Re: Proposed Charter Text

[Ian Swett <[e-mail]>]

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=
[e-mail]> 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/
> >
> > 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
> >
> > 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  [phone]
> <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile [phone]
> <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>