Re: The first octet

[Martin Thomson <[e-mail]>]

On Wed, Aug 8, 2018 at 5:41 PM Kazuho Oku <[e-mail]> wrote:
> My understanding is that we do not avoid conflict in the invariants,
> but you suggest to avoid them in v2.

v1.

Yes, that was the idea.  The protocols we're talking about could have
the luxury of being able to negotiate versions carefully, and avoid
any version that doesn't suit.

> For example, is it the case that you think avoiding conflict in the
> short term is worthwhile, at the same time keeping the possibility to
> change the decision in the future versions of QUIC?

That is certainly true.  See Colin's response too.  He managed to
summarize the thinking here fairly well.

> Honestly, I do not have a strong opinion here, although I worry about
> ossification when we decide not to grease the bits. Therefore, I would
> like to understand why you think avoiding conflict in v2 but not in
> invariant is worth considering.

Yes, the risk exists.  We could, for example decide to try to mitigate
this risk by choosing something maximally bad for 7983 demux and force
folks who want to do that to define a new version, thereby generating
two variants in relatively quick succession and pinning our hopes on
that helping.  I tend to think that things ossify on longer timescales
than that and so am willing to risk those bits sticking for this gain.
For the short header, it would be exactly one bit.

Invariants is part of our protection here.  It might turn out to be
futile, I don't know.  But I would be very happy to define a new
variant that set that bit to zero.