Having a group to make unpopular but right decisions always seems a great idea in hindsight. But there is a real practical difficulty distinguishing such groups form similar groups whose ideas are both unpopular and wrong.
The reason the IAB has no authority is that the selection mechanism is designed to ensure that it has no accountability. No accountability means no authority.
What you seem to be saying is that the IETF should have made deployment a much higher priority in the design of IPv6. Which is what I have been saying for years.
I treat deployment as an engineering problem. I have been constructing models and running simulations to test various approaches to deployment since 1992.
I can construct a plausible deployment model for IPv6 based on NAT boxes. But I can't see a plausible model which does not involve NAT44, NAT46 and NAT66 during the transition period and since I am anticipating that lasting around thirty years, I can't see much point in modeling what comes after.
On Thu, Oct 7, 2010 at 10:58 AM, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
No, they were not inevitable, at least not in the long term. Two cases:
On Oct 7, 2010, at 10:20 AM, Noel Chiappa wrote:
>> From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
>
>> The problem is that the creation of disjoint addressing realms (due to
>> NAT and to IPv4/IPv6 coexistence) has made distributed application
>> design almost impossible without kludges.
>
> See, this is the kind of thing I was talking about in my early post in the
> recent incarnation of this thread. Complaining about the existence of
> disjoint naming realms, and how it has complicated our lives, is like a
> rocket scientist complaining about gravity, and how hard it makes their job.
> (OK, it's not quite a perfect analogy, since gravity is fundamental, but I
> think my point is clear.)
>
> They were inevitable, end of story.
1. There were IPng proposals that would have made IPng an extension of IPv4 space, and allowed (at least in the interim) all IPng traffic to be tunneled over IPv4 networks. This understandably made routing people and network operators uneasy as nobody wanted to live with the Class C swamp forever. But in hindsight there were probably other ways of dealing with that problem. And being able to leverage the existing IPv4 network in a general way would have made IPng easier to deploy. (Admittedly, what looked deployable in the early 1990s when these tradeoffs were being discussed is very different from what looks deployable now. In 1991, say, it was much easier to imagine the whole Internet migrating to a new protocol than it was even a couple of years later.)
2. In the late 1990s when it became apparent that NATs were causing problems, IETF had an opportunity to put a stake in the ground. It could have tried to find a way to integrate NATs into an explicit Internet architecture; it could have explained why NATs presented difficult problems for which there were no good solutions; it could have tried to define NAT in such a way as to permit a more graceful migration to IPv6. It failed at all three of these, not because of insurmountable technical difficulties, but because (a) too many people were afraid of alienating NAT vendors, and (b) IAB, the only part of IETF that had any responsibility for architectural direction, had been stripped of its power in the wake of Kobe.
In fact, as we should realize by now, IAB's concerns that dictated the Kobe decision were extremely well founded, even if a lot of us (myself included) didn't like the specific choice they made. But as it turned out, we didn't really have enough time to use our normal "rough consensus" process to specify IPng.
All of this is water that has already flowed under the bridge, of course. But I think there is at least one thing that we need to learn from this going forward, and that is that there really is a need for a small group of wise and widely-trusted people to be able to set architectural direction for the internet. And occasionally, they're going to make unpopular decisions. But those are the sort of issues for which a rough consensus process demonstrably does not work.
Keith
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf