[ih] vm vs. memory
Dave Crocker
dhc2 at dcrocker.net
Wed Oct 25 07:19:12 PDT 2017
On 10/24/2017 6:31 PM, Bernie Cosell wrote:
> We quickly learned that something had to change, it was in three steps:
> 1) put in code that handled the old way AND the new way [and of course,
> figured out which was which]. 2) distribute code to switch over to the
> new way [could be done a few systems at a time to limit the damage if
> something went wrong], 3) take out the old-way code. I can't imagine how
> you'd do something like that in today's internet,
Adoption in general, and transition in particular, are usually treated
as an afterthought in designing Internet technical standards. This is
probably why the major infrastructure upgrades take so long or just
plain fail.
Incentives, effort, and the pure physics of scale dominate the reality
of adoption and typically seem to be far more difficult to deal with
than the task of designing whatever basic capability is the actual goal.
Neither after-though nor idealism are appropriate for overcoming this
barrier.
However...
One exception to 'after-thought' that I've noticed as a pattern is to
specify the hybrid capabilities in the same spec as the new spec. That
is, there is an explicit effort to pay quite a bit of attention to
simultaneous support of the old functionality with the new. That's
goodness, of course. However this approach makes for excessive
specification complexity and, usually, bogs the effort down. It also
means that there is no specification for the 'pure', desired and
enhanced activity.
So my current view is that enhancement efforts need to specify the
enhancement effort in its pure form, that can be characterized as a
clean-slate, 'assume everyone is doing it' form of specification. The
same as if there were no history. Then, separately, specify the hybrid
operation. For one thing, this seems to move more towards a model of
gatewaying between the two worlds, rather than requiring everyone,
everywhere, to support old and new forever.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
More information about the Internet-history
mailing list