Re: QUIC - Our schedule and scope

["Philipp S. Tiesel" <[e-mail]>]

Hi

> On 29. Oct 2017, at 07:45, Eggert, Lars <[e-mail]> wrote:
> 
> Hi,
> 
> On 2017-10-29, at 7:33, Roni Even <[e-mail]> wrote:
>> I think we must be very careful when defining the "invariants" to allow for other uses.
> 
> agreed. And, we must be very careful to not make future extensions like multipath, partial reliability, etc. more difficult to support than necessary.
> 
> So to me personally, that kind of forward-looking discussion - to ensure we retain the extensibility needed for the future - remains fully in scope. But there is a fine line between a general extensibility argument and an argument that says "my proposal for future extension X is this, and therefore QUICv1 needs to do Y now”.

For the sake of getting things done, I totally agree with this statement.

But, as someone working on the yet-out-of-scope feature, I think the WG should find a gentle way to include these projects, and make sure it does to move towards squishing them.

Therefore, I propose 15min yet-out-of-scope feature report in the meetings.

I also think a kind of guideline how yet-out-of-scope features should give input could help, something along:
 - Have a separate daft on the feature with importing considerations and lessons learned from implementation.
 - Have a 4-line TL;DR regarding whether 
   1-2) how difficult implementing the feature is (given the current drafts)
   3-4) roughly what changes would be needed to add the feature
 - Don’t file pull-requests on the current drafts, but maybe have a fork with diffs ready.
 - Raise hands if changes under discussion would totally block / significantly complicate adding the feature later on  
 - Raise hands if changes under discussion would enable / ease implementation of this feature - these arguments might be tie breakers.

Based on that, I will continue to submit draft-tiesel-quic-unreliable-streams-01 today

AVE!
  Philipp S. Tiesel / phils…