[tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt

[Tom Herbert <[e-mail]>]

Hello, I have a comment about the discussion of protocol ossification.
>From the draft:

"A reliance on the presence and semantics of specific header
information  leads to ossification, where an endpoint could be
required to supply a specific header to receive the network service
that it desires.  In some case this could be benign or advantageous to
the protocol"

I am dubious about any statement that protocol ossification of
transport layer by middleboxes is a good thing. There are too many
examples where protocol ossification has impeded or prevented
deployment of IP protocols or features (QUIC, MPTCP, TFO, SCTP, EH,
etc.). Yes, we need to take effects of protocol ossification into
consideration when deploying a new end to end protocol or features,
but that is for practicality and not by choice. IMO, protocol
ossification is something we have to work around and undo, not a
principle to embrace.

If there is some case that is "benign or advantageous to the protocol"
then please provide a _specific_ example. And if such a case exists
then I'd expect there would be general consensus that the protocol
definition was wrong in the first place to have allowed so much
extensibility and that the ossification should be standardized in the
protocol specification.

Tom