Subject: Second Implementation Draft Guidelines

From: Martin Duke <[email-masked]>
Date: Wed, 21 Jun 2017 14:11:53 -0700

All,

As promised, I've created a set of guidelines for what should be in the
Second Implementation draft. If deadlines hold, I believe we will actually
start implementing this draft after Seattle in October.

Once we've reached reasonable consensus, this should serve as a basis for
prioritizing issues to resolve through Seattle.

The current version is very much a starting point for discussion. I've
presented some items I think are important to include, and others that we
could bring in depending on our appetite for work. The final version will
simply have "Must Include" and "should not include".

<http://goog_314636520>
https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft

I look forward to your comments.

Martin

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 21 Jun 2017 14:22:31 -0700

This is a great start, thanks for getting it going.
Just one thought: You may want to explicitly "include" fixed-time
RTO-recovery. It appears right now as a side note in what's not included.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 22 Jun 2017 17:07:51 +0000

I don’t feel I came away from the Paris Interim with a clear idea of the approach to the second implementation draft. There was a lot of discussion around whether bugfixes in new I-D drafts (that address issues identified in the first implementation draft) would contribute to a first.1 implementation draft (all the way up to first.N) or if they would be put into the second.

Side note: Personally, I don’t particularly like the terminology of first, second etc for the reason that it gets hard to rev/iterate on a particular one. However, perhaps it was purposely chosen to disambiguate from the I-D versions?

The strawman suggests to me that the direction is to lump both fixes and new features into the second implementation draft. I don’t necessarily have an argument against that but think it would help to clearly identify where things have been fixed, changed completely, been overtaken by other changes etc. Understandably it is too early to do that at this stage.

Finally, being super picky, the second implementation doesn’t seem to cover non-critical shortcomings

Regards
Lucas

From: QUIC [mailto:[email-masked]] On Behalf Of Jana Iyengar
Sent: 21 June 2017 22:23
To: Martin Duke <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Second Implementation Draft Guidelines

This is a great start, thanks for getting it going.
Just one thought: You may want to explicitly "include" fixed-time RTO-recovery. It appears right now as a side note in what's not included.

On Wed, Jun 21, 2017 at 2:11 PM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:
All,

As promised, I've created a set of guidelines for what should be in the Second Implementation draft. If deadlines hold, I believe we will actually start implementing this draft after Seattle in October.

Once we've reached reasonable consensus, this should serve as a basis for prioritizing issues to resolve through Seattle.

The current version is very much a starting point for discussion. I've presented some items I think are important to include, and others that we could bring in depending on our appetite for work. The final version will simply have "Must Include" and "should not include".

<http://goog_314636520>

Martin