Re: QUIC - Our schedule and scope

[Martin Duke <[e-mail]>]

Lars and Mark,

I'm comfortable with being a little more aggressive with respect to the
schedule, as you suggest.

One practical suggestion: can we create an issue category for "deferred"
stuff? There are probably a dozen or issues that are good ideas floating
around (a couple of mine) that we may not have time to address in 2018, but
shouldn't be lost. I would feel a lot better about my stuff being punted if
I knew the WG would formally consider it in v2.

Martin

On Mon, Oct 30, 2017 at 4:42 AM, Roni Even <[e-mail]> wrote:

> Hi,
>
> Maybe we can say that future versions may have a different header size
> signaled for example by the message type . So the location of the payload
> is not fixed based on having 1 or 0 in the header form bit.
>
> Roni
>
>
>
> *From:* Philipp S. Tiesel [mailto:[e-mail]]
> *Sent:* יום ב 30 אוקטובר 2017 12:34
> *To:* Eggert, Lars
> *Cc:* Roni Even; Mark Nottingham; QUIC WG; Spencer Dawkins at IETF
> *Subject:* Re: QUIC - Our schedule and scope
>
>
>
> 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…
>