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

From: Eliot Lear <[email-masked]>
Date: Thu, 5 Jan 2017 08:17:08 +0100

Hi Dave and the rest of the IAB,

First, I have to say that I very much appreciate Dave in particular
keeping focus on this area.  It's good advice not just for the IETF, but
for those who are following.  Still, I'd suggest you take another swing.

In general I would suggest that there needs to be more meat.  The
abstract states that this memo summarizes various things.  Ok.  The
question for me is this: what is it that the board would like to convey
to the IETF or to others by way of advice on how to do things better the
next time?  Now maybe it is because I've been around this block a few
times, but I must admit I am left wanting more.  And to be sure, there
is more to want.  See below regarding that.  The extreme example of this
is Section 4.5.  Why does one need a contingency plan?  What should an
analysis look like in terms of deriving it?

On organization, you seem to be hiding lessons learned in the appendix. 
I advise against it.  Figure out what you really want to convey and then
use the information in the Appendix or from elsewhere to support your
discussion.

Perhaps one of the most successful transitions we have seen is HDTV in
America.  It might be worth including that in your appendix.  How is it
that hundreds of millions of broadcast sets eventually all got converted
over in a fixed time period?  Obsolescence played a role, regulation
played a role, industry alignment played a HUGE role: frequency demand
and the ability to sell a much better product with (perhaps) a higher
margin for a time made a big difference, I think.  HDTV might make a
good comparison against, say, IPv6.

HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218.  Because HTTP1.1
has "enjoyed" wild success, there is an opportunity to revisit that. 
For instance, is it still enjoying wild success or is it simply now just
wild?  That is, has H2 taken its primary use case, leaving everything
other than what it was designed to do?  And maybe that's okay.  One
could argue that the other use cases look a lot like CoAP, and yet CoAP
may only cover a fraction.

I'd suggest that there is an entire topic that you could plumb and is
worth hitting head on: has the world become more 2-sided?  One thing we
might stand to learn from HTTP/1.1 and HTTP2 is how much code was needed
where to get bank for the buck?  The Alexa 12, for instance, would argue
that hitting just a handful of browsers made a massive difference re
what we see on the Internet, and the value is sufficient to just those
sites, and a few content networks like Akamai to sustain the new
protocol.  It doesn't really say, however, how to turn off the old
stuff, or even whether it is necessary to do so.

In the context of IoT, there are right now (plus or minus) a gazillion
frameworks floating about that are all about code and not about
protocol.  It is a foregone conclusion that there will be some
consolidation to a number that looks closer 5-10 so that network effects
can be enjoyed.  Well if that's the case, one question, and maybe this
is one for Laura Denardis, is whether this consolidation is a good thing
for protocol development.  On the one hand it offers tremendous scaling
ability to effect transitions.  On the other hand, it may concentrate
power into a very small group of people regarding that transition.

Nits

Section 1, Bottom of Page 3, Point 3:

> *Don't* *under*estimate the cost of things *other* than the hardware/software itself.

This phrase is nearly a triple-negative.  How about restating it along
the following lines:

It's important to consider costs that go beyond hardware and software,
such as...

All the best,

Eliot

On 1/5/17 2:17 AM, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on 
> draft-iab-protocol-transitions-05.
>
> The document is being considered for publication as an Informational RFC 
> within the IAB stream, and is available for inspection at:
> https://datatracker.ietf.org/doc/draft-iab-protocol-transitions/
>
> The Call for Comment will last until 2017-02-01. Please send comments to
> [email-masked] and [email-masked].
>
> Abstract
>
>    Over the many years since the introduction of the Internet Protocol,
>    we have seen a number of transitions from one protocol or technology
>    to another, throughout the protocol stack.  Many protocols and
>    technologies were not designed to enable smooth transition to
>    alternatives or to easily deploy extensions, and thus some
>    transitions, such as the introduction of IPv6, have been difficult.
>    This document attempts to summarize some basic principles to enable
>    future transitions, and also summarizes what makes for a good
>    transition plan.
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jan 2017 13:51:06 +1300

I think this is now in pretty good shape.

There is one aspect of the IPv6 case study that might, or might not,
be useful to mention. I refer to a tendency for overstated claims,
some of which were just exaggerated and some of which were simply
untrue. This didn't come from IETF sources. In fact some of us
ran around after the perpetrators giving talks about "IPv6 myths".
For example, there was a persistent myth that IPv6 was more secure
than IPv4. (There was also a myth that IPv6 was less secure than IPv4.)

This was highly unhelpful, especially when it infected the government
mandates.

Regards
   Brian

---

From: Lee Howard <[email-masked]>
Date: Mon, 09 Jan 2017 20:07:36 -0500

Change advocates diluted their credibility, which may have affected
perception of the new protocol. I agree with your point, and need to think
about whether it¹s important for the audience of this document.

Lee

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jan 2017 10:15:12 +0000

A really good example of a transition mechanism that is not called out 
in this draft is the RIB.

In routing we have for years used the RIB as a clearing house to allow 
the routing protocols
which run ships in the night and are incompatible with each other to 
exchange connectivity
information between each other.  We can thus introduce new local routing 
protocols at will.
The (unsolved) routing equivalent of a problem of IPv6 proportions is BGP.

An example from ancient history outside the IETF was the DECnet Phase 4 
to Phase 5
transition. This was required to have a transition method indeed a as 
recall a hands-off
transition method. It was designed about the same time as IPv6. The word 
at the time
was that migration design too 80% or so of the design effort. It is 
likely that if IPv6
which presumably would have been fundamentally different, had stated 
this as a day one
goal we would be in a better place now.

Where this document appears to stop short is to recommend, maybe even 
require that all
revisions to Internet scale protocols MUST include a documented seamless 
migration
technical design, and that all new protocols that are expected to be 
deployed at that scale
MUST include the capability of being seamlessly replaced.

Best Regards

Stewart

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jan 2017 12:04:54 +1300

Hi Eliot,

I'm going to speak for myself and pick on a few points you make, and
let others comment on the things that I am less knowledgeable about.

You ask for more meat on the document in a couple of ways.  I think
that you do raise some relevant questions, and it's probably the case
that the IAB needs to consider the effect of market consolidation.  I
do think that we should avoid burdening this document with a
requirement to address all of those concerns though.

We're learning, particularly as feedback on this document comes in,
that there are lots of great examples of how transitions can be wildly
different.  Based on that, I'm not sure that this document can never
be comprehensive enough to address all possible considerations.  In
fact, I don't see that to be its purpose.  A document that highlights
the importance of considering transition factors is of more benefit
now than a detailed manual that we may never publish (not suggesting
that was your intent, just drawing on the extremes).

On 5 January 2017 at 20:17, Eliot Lear <[email-masked]> wrote:
> HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218.  Because HTTP1.1 has
> "enjoyed" wild success, there is an opportunity to revisit that.  For
> instance, is it still enjoying wild success or is it simply now just wild?
> That is, has H2 taken its primary use case, leaving everything other than
> what it was designed to do?  And maybe that's okay.  One could argue that
> the other use cases look a lot like CoAP, and yet CoAP may only cover a
> fraction.

I don't agree with the implied characterization of h2.  It is true
that h2 provides optimizations that are primarily aimed at certain
styles of deployment. Consequently, those deployments are more likely
to spend the effort to analyze the performance trade-offs and deploy
the new code.  You are also (probably) talking about deployments that
tend to move a lot faster.

But h2 is functionally complete as a replacement for HTTP/1.1.  To
suggest that only really big sites, CDNs and major browsers are the
ones that are using h2 is just wrong.  Use of h2 in things like APIs
is pretty widespread now, it's just not as obvious.  Multiplexing
there is a huge win for throughput and efficiency.

We've also seen cogent arguments that insist that h2 is almost
perfectly suited to IoT deployments because of those same
optimizations. Though we're seeing the effect of some of the choices
we made to package changes together: IoT devices generally prefer to
use use weaker crypto than h2 permits.

(Not sure what you are getting at with the "just wild" statement.)

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jan 2017 16:02:06 -0800

Hi Martin,

Thanks for your response.  Pelase see below.

> requirement to address all of those concerns though.

It's your document.  Decide what you want with it.

> that was your intent, just drawing on the extremes).

It is important to state why those factors are important.  It is not
necessary to list every possible one.  Choose wisely so that your points
are illustrated.  Don't hide that information in an Appendix.

> use use weaker crypto than h2 permits.

The jury is still out on how well H2 will succeed.[1]  We can say it has
been very well adopted in a particular use case.  Because IoT is a broad
term, I have no doubt but that H2 will be appropriate in some cases. 
Just because the code is in APIs does not mean it will be used.  It is
unlikely to be appropriate in many cases for numerous reasons, not the
least of which is its code complexity as compared to http/1.1 and CoAP,
and the other being that there is more crypto work needed in closed
systems (maybe ANIMA BrSKI will help with that).

However, none of this was really my point.  My point was really more
about how demand and use of http/1.1 has evolved.  5218 makes the point
that http/1.1 was wildly successful.  See the figure in section 1.2.1. 
That means that it has been broadly adopted well beyond its intended
design space.  But now we see peeling away of some of those uses to
other protocols, such as h2 and CoAP.  How then do we evaluate what is
left?  Are all uses left beyond the design space?  That is what I meant
by “just wild”.   My point is that a careful analysis of that would be
good follow-on work from 5218.  One question is simply this: how does
wild success evolve over time?  Showing a certain amount of continuity
in the board's work seems to me a good thing, and it seems to me that
the document starts down that path, but is somewhat unfocused with its
examples.  Again, that they are in the appendix is indicative of that.

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?

Regards,
[1] https://w3techs.com/technologies/details/ce-http2/all/all

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jan 2017 14:27:05 +1300

> 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.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Jan 2017 21:35:50 -0800

Hi Martin, Eliot,
>it (we still carry the code for SSLv3, but it's been given notice).

I didn't catch Eliot's point about HDTV at first.  In the field of 
software, the developers sometimes drop support for an old version of 
a protocol [1].  From a SSO perspective, the IETF is said to have an 
open maintenance process for its standards.  Does that maintenance 
process apply to the obsolete version of the protocol?  Does that 
maintenance process only apply to bug fixing or does it also comprise 
adding new features to the obsolete protocol?

An observation about Bitcoin is included in Section 1 of the 
draft.  Bitcoin is not an IETF technical specification or 
protocol.  Bitcoin was described as "a peer-to-peer electronic cash 
system" [2].  The closest analogy, based on the arguments of an ITAT 
paper, is IPv6 as it comes with a built-in payment system.  The 
Early-Adopters incentive(s) did not work for IPv6.  How could the 
IETF provide a long-term advantage in its protocols?

Did having the policy-making organizations mentioned by example in 
the draft make a significant difference [3] in turning the IPv6 
transition into an example of a successful protocol transition?

Is the IAB responsible for planning for transition for an IETF protocol?

Regards,
S. Moonesamy

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807107
2. https://bitcoin.org/bitcoin.pdf
3. I am not sure about the meaning of "enabled" or "facilitated".

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Jan 2017 03:57:21 -0800

Hi Martin,

On 1/10/17 5:27 PM, Martin Thomson wrote:
> we have to support them.

That might be a point worth capturing, but your use of version 4 is well
chosen, because we are quite a lot about the resources associated to it
versus version 6 ;-)

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Jan 2017 08:52:55 -0800

> Is the IAB responsible for planning for transition for an IETF protocol?
The charter of the IAB puts long-range planning in the IAB's set of
responsibilities when that is done as part of its architectural oversight
(see section 2.1 of RFC 2850).  In practice that means that some
transitions are completely outside of the IAB's remit, some the IAB
contributes to (by reviewing charters for proposed work, proposing
workshops on the relevant space, etc.), and some it advocates (the
transition to default-confidential operation for the Internet being the
most recent).  Once the community accepts the advocacy, though, the work
goes on in the IETF.

regards,

Ted

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 14 Jan 2017 15:48:31 -0800

> draft-iab-protocol-transitions-05.

I have read this version of the draft and think it will be a useful RFC. 
Kudos for having the document also cover transitions outside the IETF 
standards process; this document can be useful to developers who have 
created proprietary standards as well as organizations transitioning 
from one type of communications system to another. Having case studies 
that run the gamut from "this worked well" to "this was painful" is also 
valuable.

--Paul Hoffman