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

[Tom Herbert <[e-mail]>]

On Tue, Jul 9, 2019 at 3:35 PM Colin Perkins <[e-mail]> wrote:
>
> On 9 Jul 2019, at 05:35, Joe Touch <[e-mail]> wrote:
>
> On Jul 8, 2019, at 8:05 AM, Tom Herbert <[e-mail]> wrote:
>
> "A reliance on the presence and semantics of specific header
> information  leads to ossification…"
>
>
> Relying on the semantics of a protocol header is also called a standard.
>
> “...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.
>
>
> Ossification and stability are two sides of exactly the same coin.
>
> It’s called ossification when the variation of a standard is no longer supported, e.g., because of middleboxes assumptions beyond that defined by the standard.
>
> It’s called stability when we can rely on a set of definitions that constrain arbitrary variation in controlled ways.
>
>
> Exactly.
>
> We might choose to declare certain properties of a protocol as invariant, because we want a stable substrate on which others can build, including middlebox vendors. That is, we might choose to intentionally accept and encourage ossification, because we believe the benefits of stability for those features outweigh the benefits of flexibility.

Colin,

Who is "we" in this description? Is this is IETF or an open community
that has diligently evaluated the effects of ossification of some
feature and has achieved consensus that too much flexibility in a
protocol was a mistake; or is it random vendors or network operators
that decide what they support per their convenience or that of their
marketing department with the side effect that the Internet is driven
to support only the least common denominator of protocols and protocol
functionality?

>
> The problem is not ossification as such. It’s ossification of things that we intended to be changeable.
>
Not sure I see the difference. In any case, the irony of this
discussion is that ossification of the transport layer by middleboxes
is precisley a major motivation driving encryption the transport
layer. E.g. a principle of QUIC protocol design is "Beyond the obvious
privacy benefits, encryption prevents ossification of the protocol by
middleboxes, which can't make routing decisions based on information
they can't understand." I doubt that a one-off statement that
ossification could be a good thing will much effect on those building
new transport protocols for widescale deployment. For that matter, I'm
still doubtful that any of the purported benefits listed in the draft
are sufficient rationale to convince any transport layer and
application developers not to encrypt the transport layer.

Tom

>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>