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

Hi, Eric,

Thanks for your comments. Please see inline.

On Mon, Sep 12, 2016 at 6: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.
>

Consider it struck.

> > 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.
>

I'm sympathetic to this point. We are also having a parallel chat about how
closely tied to TLS 1.3 (as opposed to future TLS versions) QUIC will be.
So, if this was

- Providing secure transport by default

or

- Providing secure transport by default using TLS,

would either of those work as well?

>
> > 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.
>

I agree. That's going to be in 00-03.

> > 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 strongly suspect that everyone involved to date knows this so nobody
bothered saying it, which could be fine when we're having a BOF, but is not
so fine when we're chartering a working group that involves people who
weren't present at the beginning of the conversation. I'm proposing

"QUIC will work closely with the HTTPbis working group, especially on the
third
focus area."

Would that work for you?

Thanks,

Spencer

> -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
>>
>>
>