On Jun 1, 2013, at 2:52 PM, John C Klensin <john-ietf@xxxxxxx> 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.