On Jun 1, 2013, at 2:52 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
On the technical side, I believe that there was a general belief
in 1993 that we would be able to map out a unified, clear, transition
strategy for IPv6 and give simple advice about it.
John is correct in terms of belief (but perhaps a bit early on date), as
the IPng decision was specifically predicated upon us being able to explain
shortly thereafter "what mechanisms will be employed in the transition, how
the transition will work, the assumptions about infrastructure deployment
inherent in the operation of these mechanisms, and the types of functionality
that applications developers will be able to assume as the protocol mix
changes over time." (RFC 1752 "The Recommendation for the IP Next Generation
Protocol", January 1995)
The fact that the fundamental architecture of IPng could be selected before
the transition strategy was settled is clear proof of the very point Randy
was making with respect to the IETF not listening to the operations customer,
as no one running production Internet service could have agreed to proceed
with a new _incompatible_ version of the Internet protocol absent a well-
documented transition/interoperability strategy. This disconnect is not
solely the fault of the IETF, it is definitely shared with the operator
community who have more pressing and immediate demands on their time than
trying to cover IETF activities as risk mitigation against new developments
which aren't likely to impact their business for years to come. (In fact,
it should probably be more surprising that there are any service providers
who attempt to stay informed about IETF efforts, given the difficulty of
covering the range of IETF activities and the very long-term timeline for
any potential benefit from the investment.)
The reality is that there are not a lot of places where _one_ architecture
is needed; i.e. in general, it's fine to "let a hundred flowers blossom"
with a myriad of alternative working groups with vendors promoting various
competing drafts to solve a given problem. However, we can't lose sight of
the fact that there are also areas that are fundamentally architectural in
nature, with far-reaching and long-lasting impact on the Internet (e.g. the
IP protocol itself, TCP, DNS, etc.) where there truly needs to be just one
solution for any given problem space. When dealing with such cases of the
fundamental architecture of the Internet, the IETF needs to go above and
beyond in making sure its reaching out to the actual operator community
and dealing with the actual problems that they face with these protocols.
I'd suggest seeking out operators with significant "skin in the game" and
interest in joining the effort before spinning up new working groups for
protocols in these key architectural areas. If you can't find a service
provider interested enough to participate, then that is likely sign that
the work may not actually be needed...
It would also help if there was a general acceptance that the IETF should
be far more rigorous when dealing with these core protocols, and set very
high standards before deciding to making any changes. In the case of IPng,
we jumped on a solution that was neither fully defined nor focused on what
operational networks actually needed; the result has been quite painful
but hopefully will not prove fatal for the Internet in the coming years.
FYI,
/John
Disclaimers: My views alone. As a member of the IPng directorate at the
time, I do share in responsibility for the recommendation of IPng as the
new Internet Protocol despite its lack of focus on actual service provider
functionality and the transition/interoperability mechanism left as an open
work item. I believe that critical examination of the past is essential to
improvement, and in this particular case the pain involved in reflection
is well worth it if the IETF gains as a result.