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

[Eliot Lear <[e-mail]>]

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
> [e-mail] and [e-mail].
>
> 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.
>
>