Hey Dave,
I admire your desire for "clarity" on this subject, but fear you will be
disappointed.
ISTM that the success of changes to the infrastructure depends on the value
those changes deliver to participants in the Internet economy -- i.e., the pain
of the problem they solve. Your two examples are actually very appropriate
here: IPv6 and DNSSEC both moved very slowly until (1) people started to not
have enough numbers to grow their networks, and (2) Dan Kaminsky put the fear
of God in people.
So the question is rather how many problems there are in the current
infrastructure that cause people enough pain to do something. I think there
are at least a couple (improving BGP security, for example), and the number
will probably slowly shrink over time, but in the long run, I expect there will
ultimately always be a few big things that need to be done that can't be done
in end systems.
--Richard
On Dec 31, 2010, at 9:56 AM, Dave CROCKER wrote:
Folks,
Feliz Año Nuevo!
One of the lessons of efforts such as IPv6 and DNSSEC should be that making
changes to the global infrastructure of the Internet is extremely difficult.
The technical details are difficult -- especially if the change seeks to work
with an existing base of functionality -- and the administration and
operation details are difficult. And the time it takes to achieve critical
mass is quite long.
However we continue to hear claims and see design efforts that are based on
the view that changing the infrastructure is easier than changing
end-systems.[1] The fact that the infrastructure is controlled by far fewer
actors and organizations makes it natural to assume that this preference is
well-founded and correct.
But does the Internet's track record substantiate this view?
So I would like to ask for folks to help the community develop some concrete
information about this, by adding entries and comments to the IETF's Outcomes
Wiki:
<http://trac.tools.ietf.org/misc/outcomes/>[2]
If there is a piece of work that was targeting change to the infrastructure
or the creation of new infrastructure, please add an entry for it to the
wiki. This will provide an explicit statement about the history and degree of
success of that effort.
Congestion control, mobility, multipath, multicasting, new transport, MIME,
etc. Anything that enables higher-level capabilities.
Some infrastructure changes are designed for the router level of things and
some are designed for host-level. But they provide underlying services that
can then be used for better performance, reliability, or control or to make
new applications viable.
My expectation is that we are going to find that such efforts are difficult,
no matter where they are put, but I suspect we will find that the ones
destined for the router level of things are the hardest.
Prove me wrong by adding entries to the Outcomes wiki that show otherwise...
Or prove me correct.
Having clarity about this topic could make for a pretty good start of the new
year...
d/
[1] Serious pursuit of this topic requires some agreement about the
definition of "infrastructure" and quite possibly agreement on "end-system".
For now, let's just say that infrastructure is anything that provides
services to a layer above. That makes TCP a kind of infrastructure service.
But, then, the environment for controlling it is quite different, since it
sits in hosts, not routers. So perhaps we need some additional constructs
for the "venue" of infrastructure service?.
[2] We might discover that it will help to add a column to the wiki's
tables. That's fine to explore on the wiki's mailing list:
<https://www.ietf.org/mailman/listinfo/ietf-outcomes>
Given footnote [1], an example of a change might be a column that notes where
the service resides in terms of Internet architecture. Granularity that
distinguishes more than just host-vs-router might be helpful, since the
Internet's range of "tussle" boundaries has grown more complex, given the
operational reality of PCs, servers, organizational nets, local ISPs and
transit nets...
In the absence of agreements to make changes, use the Comments column in the
wiki, for recording information that might warrant a new column in the table.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf