Hi Ed;-)... what you say might be true in general, but the ORSC
policy is that the composite root should be free of TLD collisions,
just as lower levels must be free of collisions.
The mechanism for avoiding collisions should be one of coordination
and not one of dictation by single points of control which are at
best very controversial and arbitrary, and which summarily create
collisions when they know that they are doing so.
ORSC simply provides a root of greater value just because the ORSC
root inclusively contains all the known public accessible TLDs, while
the ICANN root exclusively only contains those TLDs which ICANN has
given sanction.
And, at this point there is one extant collision which ORSC is not
able to resolve for the simple reason that ICANN refuses to even
acknowledge the fact of the collision that ICANN has knowingly
created.
If anyone here has any good ideas for ho anyone outside ICANN might
successfully negotiate a resolution with ICANN, please provide your
advice, and ORSC will give it due consideration, but if your
suggestion is to take ICANN to court, please understand that you will
be asked to help by sending money for legal fees.
At $1.5+ million per year for its legal expenses, ICANN clearly has
an advantage over ORSC which relies on voluntary support, while we
all contribute our domain name taxes to ICANN for our ICANNIC DNS
names;-)...
Best...\Stef
At 3:14 PM -0700 7/29/02, Ed Gerck wrote:
All:
The DNS is indeed defined as a hierarchical tree and thus must
have only one root. It will not work with more than one root.
What Richard and Stef are saying, in short, is in agreeement with
that in the sense that they recognized you would need an *additional*
control structure in order to use multiple roots AND the DNS.
But, adding multiple roots will NOT do away with the single root --
as Brian noted. That additional control structure for the "multiple
roots" must still be controlled by someone -- and here is where we
go back in a circle, Brian notes.
However, what Richard is saying would create a delegation mechanism
to the root, for those who want to use it. Those who do not want to use
it, would still see only the DNS root. Richard is not solving the DNS
control problem, he is just proposing a way to create a delegation
mechanism that is entirely optional for the user to see.
That said, this logic implies that operators of root A cannot complain if
operators of root B define a TLD that conflicts with a TLD in root A.
Thus, operators of an alternate root cannot complain if the DNS operators
add .BIZ to the DNS TLDs and control it. An alternate root operator could
also add .COM to their namespace and control it. Operators of intranets
do it all the time.
Cheers,
Ed Gerck