On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote: >> From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> > >> What doesn't work well is to have everyone decide for himself how to >> change the architecture. > > The reason we have/had a free-for-all on the architectural front is that the > IETF's choice for architectural direction (15 years ago) was non-viable (i.e. > wrong); it wasn't economically feasible (in terms of providing economic > benefits to early adopters, or otherwise having an economically viable > deployment plan), and it didn't offer any interesting/desirable new > capabilities (which was a big factor in the former). In hindsight, I suspect IETF could have made a better choice for IPv6. Or even accepting the basic IPv6 approach that we ended up with, slight changes to some of the details might have made a big difference. And it's worthwhile to try to learn lessons from that choice and the consequences. However, I don't see how it's constructive to say that the choice was "wrong". There is today an increasingly widespread realization that "the worldwide deployment of IPv6" is a better path forward than any of the likely alternatives. That doesn't mean it's the best possible path forward, of course. But as we're both painfully aware, having a better idea isn't sufficient. A necessary condition for success is to get widespread buyin to the idea. For better or worse, IPv6 is still the only semi-viable long-term strategy that has anything like widespread buyin. > With an 'approved direction' that didn't work, having people go off in their > own directions instead was an inevitable corollary. Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. The problem was that the 'approved direction' was wrong, it was that in many important spaces for both IPv4 and IPv6, there was no approved direction - only a hodgepodge of half-baked hacks that didn't fit together well. > Which is why I am urging the IETF to be _realistic_ now, and accept the world > as it actually is, and set direction from here on out based on that, and not > on what we wish would happen. Sigh. Anytime someone makes an appeal to accept "reality" I wish a (small) brick would fall on his head. That's exactly the same kind of argument that was made in the late 1990s within IESG as to why IETF could not do anything to make NATs predictable to applications. But for what it's worth, I do share your assumption that we don't have the luxury of working from a clean sheet design. And I agree that at least in the near term it's going to be ugly. But I think the goal should be to facilitate a transition to a world that's less ugly, or at least more functional. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf