Re: Getting to a First Implementation Draft

[Patrick McManus <[e-mail]>]

I don't really know how I feel about this wiki page.. without ratholing too
deeply on it I think that while it tries to facilitate testing and interop,
it treads pretty significantly into the land of project management which is
squarely out of bounds for the working group. I'm willing to see how it
goes but that's my concern - I would rather the WG focuses on the complete
picture while providing more of a forum for pair (or more) wise testing.

anyhow wrt specifics -  ekr points out the 2 major inconsistencies.. tbh I
would require exporters and the ability to do at least one non-0 stream. At
that point you have a hello world milestone, which is always the first
stage worthy of a toast. Its ok by me if the transport params are just
profiled.

On Sat, May 13, 2017 at 2:54 PM, Eric Rescorla <[e-mail]> wrote:

> A few comments on this proposed list:
>
> > Integration with TLS 1.3 handshake - The basic 1-RTT mode must be
> > supported. TLS exporters are not needed, nor are session
> > tickets. Basic key exchange is sufficient and implementations can
> > use any certificate. All MTI algorithms listed in TLS 1.3 are
> > expected.
>
> I note that this and the transport parameters and HRR stuff below
> necessitate the generic changes to the TLS library to permit adding
> extra extensions. I wonder if it might make life better to just have a
> canned set of parameters for now. It's not that it's a lot of work,
> it's just that it's not critical path otherwise.
>
>
> > Packet protection - All post handshake packets must be sent with
> > 1RTT keys and packet protection.
>
> This is inconsistent with not requiring exporters above. As far
> as I can tell, if you're not doing NST, you don't need post-handshake
> packets anyway here, so you can probably skip this.
>
>
>
> On Wed, May 10, 2017 at 9:53 PM, Mark Nottingham <[e-mail]> wrote:
>
>> Previously, we've mentioned an intention to have a First Implementation
>> Draft -- that is, an Internet-Draft that we feel is suitable for
>> implementers to write code to, for the purposes of interoperability testing
>> and gathering feedback -- shortly after the Paris interim.
>>
>> Due to the size and complexity of HTTP-over-QUIC, implementing all four
>> drafts for this purpose on a reasonable timeline isn't workable.
>>
>> Instead, the editors have identified a subset of functionality that they
>> believe will serve as a suitable starting point. See:
>>   https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft
>>
>> They've also identified the set of issues that we believe will be
>> necessary to have proposals for before Paris; see:
>>   https://github.com/quicwg/base-drafts/milestone/1
>>
>> If all goes well, the plan is to have a set of drafts out (very) soon
>> that do so; then, we can discuss them and the First Implementation Draft
>> Candidate in the lead-up to and during the Paris interim.
>>
>> After Paris, we'll make any necessary adjustments to the documents and
>> publish another set, which will be the First Implementation Draft.
>>
>> Please comment / raise concerns / make suggestions on-list.
>>
>> Regards,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>