Re: [arch-d] [IAB] Call for Comment: <draft-iab-protocol-transitions> (Out With the Old and In With the New: Planning for Protocol Transitions)

[Martin Thomson <[e-mail]>]

On 11 January 2017 at 13:02, Eliot Lear <[e-mail]> wrote:
> You may find that an analysis such as what I described informs this
> work, because there are two questions that leads to: [1] when is “just
> wild” aspect a bad thing?  [2] When it is bad, what if any guidance does
> the board have to eliminate it?  If it's not a bad thing, then how much
> managing of the tail is really necessary when use cases differ?  And
> that brings me back to the example I mentioned: HDTV.  In that case
> managing the tail was deemed very important because one key incentive
> was being able to redeploy the old frequencies.  When do we care about
> that on the Internet and what incentives do we have to leverage?

Ahh, so the question is how you address the protocol that *is* rather
than the protocol that *was* or maybe just the protocol that you
wished there is.  That's a question we spent inordinate amounts of
time on in h2.  And there I agree with you that the question of
whether those deviant uses (in the nicest sense) need to be considered
with a new version.

My view would be that a lot of the value that a (wildly successful)
protocol gets is from those deviant uses.  Consequently, failing to
consider the protocol that *is* when designing for replacement is a
good way to fail at the replacement.  I think Section 4.1 does address
this point, though more concisely than you might prefer.

In my opinion, the question of whether you intend for the old version
to eventually disappear is usually a moot question for protocols.  The
HDTV example might not apply here.  I can't imagine we'd be looking to
reassign the meaning of version 4 in the IP header any time soon.

Protocols either die or they don't and we only care to the extent that
we have to support them.  They usually just die by degrees.  For
instance, while we might want SSLv2 to disappear completely, that's
not something we worry about as long as we ourselves aren't exposed to
it (we still carry the code for SSLv3, but it's been given notice).

To take an example familiar to me, web sites spend considerable effort
on browser compatibility, though few sites today spend any time at all
on IE6.  That doesn't mean that IE6 is no longer used anywhere, it's
just that the incentive to support it is so greatly diminished it
might as well be gone.

I'll leave it to others whether there needs to be text on this point.
I'm of the view that this is a document about the introduction of a
protocol and less about the decommissioning of a protocol.  We could
probably write a great deal on decommissioning, but it might be better
as a separate document.