OK.. I'm going to cite chapter and verse:

Summary

To remain a global network, the Internet requires the existence of a globally unique public name space. The DNS name space is a hierarchical name space derived from a single, globally unique root.

The author started out by referring to the public name space - good, I like that. But he forgot the word "zone" at the end of the second sentence. Public name space is implemented using DNS via the root zone.

This is a technical constraint inherent in the design of the DNS. Therefore it is not technically feasible for there to be more than one root in the public DNS.

Keep adding the word "zone" after the word root.... bear with me.

That one root must be supported by a set ^zone of coordinated root servers administered by a unique naming authority.

Here is where I disagree.

Put simply, deploying multiple public DNS roots would raise a very strong possibility that users of different ISPs who click on the same link on a web page could end up at different destinations, against the will of the web page designers.

This is a problem that can be solved. The author of this document wants you to believe that it cannot be solved. That is his agenda, and it drives his foregone conclusion to exactly the place he wants it to go. The deck is stacked, I tell you! No argument for why it is unsolveable is even presented. The author takes it for granted that everyone agrees with him. You are just expected to know that it can't be solved!

RFC2826 SAYS YOU HAVE TO CHOOSE FOR YOURSELF.

Now, what non-technical value judgment did you say that RFC2826 was making for you? It's not a "value judgment" that using multiple roots with DNS results in inconsistencies, it's *the way DNS works*.

Yes it is a value judgement. He has determined that the problem is insoluble. It isn't. And we don't have to abandon DNS as the nameservice protocol for the public name space. All that needs to be changed is how each recursing DNS client cache gets its glue for the root. Are we incapable of coming up with an out-of-band method for distributing a 60K text file that scales well? I think not.

And sometime in May, we'll have the complaints that IP addresses are political because they only allow 256 values per octet, and a class-action lawsuit is planned for the number 257, 258, -3, and all the fractions.

This is a matter of mathematics, not politics. How to get root glue to all clients that need it is a technical topic. Who should be the distributor of that glue is a political topic. This is the crux of the matter.

Now - I'll *readily* agree that "ICANN versus new.net" is political, and probably worth discussing. However, I'm going to have to start putting Bozo Flags on people who *still* claim that RFC2826 is political just because it points out that Things Will Provably Break if you have conflicting roots.

Well DUH! I totally agree that conflicting roots break things. But I don't think that conflicting roots is an inevitable consequence of having multiple roots, or even multiple root zones. I still say it's a self-serving statement with political motivations, and I hope I have adequately explained why I think that. I don't expect you to agree with me, but I hope I'm not as Bozotic as you thought at first. --- "The avalanche has already begun. It is too late for the pebbles to vote" - Kosh

Well DUH! I totally agree that conflicting roots break things. But I don't think that conflicting roots is an inevitable consequence of having multiple roots, or even multiple root zones.

Please outlines what advantages multiple root 'zones' have over a single root 'zone' if they are not conflicting? To me the only reason to have multiple roots can be so that each can make different decisions of what TLDs are to be included or excluded in it, or where a certain TLD is delegated to. But that constitutes conflicting which you yourself above stipulated as bad. Multiple 'coordinated' roots effectively are a single root with added overhead (generating agreement on what to include etc). A single master with replication (as currently exists in the public root will do the same with less engineering overhead and headaches. Several 'independent' root systems have in the past claimed that they would 'coordinate' with each other. Apart from the fact that that would again create a single root again, this leaves the following questions: - will all 'independent' root systems be accorded equal voice, opportunity in the efforts for 'coordination' - who guarantees that 'coordination' wil not break down once disagreement ensues between some of the players - will newcomers (independent roots that start up later) be accorded the same 'rights' in the coordination efforts as incumbents? If yes, how can that be guaranteed w/o excessive regulation and overhead. If no, how different would that situation then be from the existing one? Will there be roots that rebel and become 'independent' from the 'idependent roots'? (and so on ad nauseam)? Technically, any coordination effort among 'independent roots' simply create a single root, and thus would be no different from the current ICANN/IANA root (one body of whatever composition deciding the contents of the root). The question simply is how that body is organized. I don't see the RFC2826 going into that at all. If there are no guarantees or even attempts to coordinate the roots, they are bound to end up conflicting (unless they remain static), which would break things. And BTW: The problem is *not* distributing the glue for the root-servers (hints!) to the end-users, there are different ways to do outside the DNS itself that already (including ftp). The 'problem' is the actual content of that root zone. Mathias

It's hardly a stretch to figure out. Multiple root zones (in the true sense, not the pretend sense you suggest below) will arguably yield conflicting information over time, for reasons -- social, capitalistic, and otherwise -- I (or the author) shouldn't have to go into. If each root zone is unique (and they would have to be, else they would be coordinated and therefore not "multiple root zones"), there is nothing to stop one root zone from adding a {TLD,SLD} which already exists in another.

There's a strong incentive not to do that. It diminishes the value of both versions of that TLD. To do so would be to shoot yourself and the other guy in the foot. Darwinism in action.

This is what I'm referring to above about pretend multiple root zones. Even if you put different pieces of the root zone on different servers, operated by different entities, the only way to ensure there are not conflicts is by coordinating the information contained in each. And if you're doing that, it's still a singular root zone, just distributed. And even if the coordination is done by those different people who operate their different servers in different organizations, those people make up a "unique naming authority". Who/where/what is the "trusted" source of the glue? (And not in a political sense, in a technical sense. Where do I point my client cache to get said glue?) No matter how much you want to distribute elements of the root zone, if conflicts must be avoided (as they must in this case) then there has to be a final word from somewhere to eliminate them.

I think people should not use colliders, until the colliding parties work it out. This is Pacificroot's philosophy, and ORSC's as well. You could also delegate the responsibilty to make these judgement calls to your preferred root operator, or you can make the call yourself and build your own root zone. People will gravitate towards root operators with a track record of reliable service.

So, since 2826 never states who should be the distributor, it's not engaging the political topic in question...

Except that the one-root-to-rule-them-all crowd - ICANN boosters - cite 2826 to support their position. It is political because it is being used by both sides in a political debate.

-c

...

coordinated and therefore not "multiple root zones"), there is nothing to stop one root zone from adding a {TLD,SLD} which already exists in another.

There's a strong incentive not to do that. It diminishes the value of both versions of that TLD. To do so would be to shoot yourself and the other guy in the foot. Darwinism in action.

Sexton says the same thing, and yet it still happens (some of the new.net TLDs conflict with some of the other pirate-radio TLDs, and this was hardly the first such event). This is why it's more than just a bad idea, it has proven to happen, resulting in confusion and non-atomic lookups for everybody on all sides. It just doesn't work, despite all of the so-called good intentions. I'm also annoyed by the "freedom" pitch when I know damn well that the real issue for most of the pirate TLD operators is money. Maybe setting up alternate TLDs in order to spite ICANN was the original objective but they always seem to up as lawsuits (or threats of lawsuits) regarding lost revenues and ownership rights whenever somebody else "pirates" one of the pirate TLDs from the first pirate. The "moral" packaging is a canard in almost all cases, with the final issue being the very points that most of the pirates scream at ICANN over: money and arrogance. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

On Tue, 13 Mar 2001 Valdis.Kletnieks@vt.edu wrote:

I suppose the*next* thing we'll see is people complaining that the concept of CIDR is an evil value judgement, because you need to decide what aggregation to do in order to keep the routing table a manageable size.

And sometime in May, we'll have the complaints that IP addresses are political because they only allow 256 values per octet, and a class-action lawsuit is planned for the number 257, 258, -3, and all the fractions.

The same way you can get a custome license plate or order an easily remembered phone number - I am sure someone will soon sue to get an IP address of 1.1.1.1. Give it up, Valdis, you ain't gonna convince the people who see $ signs in all this. -Hank