Re: [QUIC] Alissa Cooper's Yes on charter-ietf-quic-00-01: (with COMMENT)

On Mon, Sep 12, 2016 at 4:39 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> I had a few comments on the draft charter:
>
> > There is emerging implementation and deployment experience with QUIC, a
> > UDP-based protocol that provides a stream-multiplexing encrypted
> transport.
> > Based on that implementation and deployment experience, the QUIC working
> group
> > will provide a standards track specification generalizing the design
> described
> > in the initial set of draft-tsvwg-quic-protocol, draft-tsvwg-quic
> -loss-recovery,
> > and related documents.
>
> "initial set" is ungrammatical here. Strike it.
>
>
> > 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;
> > - Enabling deployment over unmodified Internet paths; and
> > - Enabling multipath and forward error correction extensions.
>
> I would like to see a security objective here, as I think we all agree
> that it's a first-class priority.
>
> - Providing secure transport by default using TLS 1.3.
>
>
> > This work will ensure that
> > QUIC using TLS1.3 has security and privacy properties that are at least
> as good
> > as a stack composed of TLS1.3 using TCP (or MPTCP when using multipath).
>
> This "QUIC using TLS 1.3" language is a little weird. I would just say
> "QUIC". I believe MT provided a similar comment.
>

At the moment, QUIC is being defined in the initial docs to be the
transport protocol that requires a handshake mechanism. This is why the
TLS1.3 mapping document exists separate from the QUIC document. It would be
odd to just say QUIC if you mean QUIC + TLS1.3.

> The third focus area will describe mappings between specific
> applications???
> > semantics 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.
>
> I'm not sure this should be in QUIC so much as HTTP. Minimally it somehow
> needs to be in cooperation and I don't see anything here. I certainly don't
> want this to preclude a mapping of only HTTP/2's transport facilities.
>

I don't expect this work to necessarily show up in the QUIC wg later, but
there may be parts of this work that do show up. I think there's value in
stating that other apps will be considered in the future, but I don't have
a strong opinion on what the charter should say about work that is to be
done post re-charter. Can you send a PR?

> -Ekr
>
>
> On Thu, Sep 1, 2016 at 7:02 AM, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>> Hi, Alissa,
>>
>> On Thu, Sep 1, 2016 at 8:47 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>>
>>> Alissa Cooper has entered the following ballot position for
>>> charter-ietf-quic-00-01: Yes
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/charter-ietf-quic/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> What is the status of these PRs?
>>> https://github.com/IETF-QUIC/Charter/pulls
>>
>>
>> I checked two of the PRs. One looks like it's reflected in the
>> datatracker, but the other does not. I'll make sure the proponents think
>> the datatracker text reflects what they want to go with, before this goes
>> for external review.
>>
>> Spencer
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>