Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

[Kyle Rose <[e-mail]>]

On Fri, Jul 29, 2016 at 8:18 AM, Eliot Lear <[e-mail]> wrote:

> Hi Tom,
>
> Something that did not get brought up at the BOF is nagging at me...
>
>
> On 7/28/16 8:17 PM, Tom Herbert wrote:
> > The abstraction is only useful up to the point that networks preserve
> > the model. If the network breaks the model in ad hoc ways that forces
> > the application to try to compensate with more ad hoc mechanisms or
> > just stop innovating altogether as we see happened with protocol
> > ossification.
>
> You write that as if it's a bad thing ;-)
>
> Some amount of protocol ossification is a GOOD thing.  In particular,
> the calling interface for transports needs to be stable or source code
> will have no shelf life.  The fact that TCP's calling interface has been
> SO stable for SO long has meant that a large code base did not require
> substantial maintenance just to keep doing the same thing it was
> doing.   I see this as an exercise to determine what needs ossification
> and what does not, and there are extreme positions at both ends.
>

I think this conflates two issues. I think of "ossification" as unintended
structure that precludes development within the protocol stack, something I
think is broadly accepted as a problem by people who are trying to improve
the experience of users. What you are talking about here seems to be
stability of the API for a specific protocol. Frankly, if we apply
"ossification" to that then the term becomes overly broad and therefore
meaningless. I don't think anyone is suggesting that all APIs should be
randomly perturbed over time just to see what happens.

No one is going to break the sockets API anytime soon, but having to
develop a new API for modern protocols would be a nice problem to have.
First, though, we need to figure out how to route those protocols through
the boxes that right now assume the entire internet runs over a snapshot of
TCP from 20 years ago.

Kyle