Discuss counter-measures to version ossification

[mirjak]

See also issue quicwg/base-drafts#2496

[mirjak]

Good Strategy probably is to move quickly to new version and/or deploy draft versions in order to keep the version number field as dynamic as possible. However, if there will be ossification there is probably still a possibility to implement some kind of alternate version negotiation in the encrypted part of the packet and pretend on the outside to use the supported version (similar as TLS1.3 does); of course there is a performance/overhead trade-off.

With the uncertainty about what will happen in respect to ossification, it might not be worth is to try and solve the problem now and pay the complexity up front.

[britram]

does not appear as though the discussion on the list has converged yet; will wait to see at happens in the base drafts before addressing this one in ops.

[britram]

Consensus to handle "weak" version ossification via a mechanism in the transport; holding this issue open until that converges, but probably not useful to have text in manageability.

[britram]

This converged in Singapore to no-action in v1.

[britram]

Fixed by #89