From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
Sent: Tuesday, March 13, 2001 12:03 PM
I fail to see how RFC2826 is in any way "political". Upon
careful re-reading
it boils down to:If you use one root, everybody agrees what things look like.
If you use multiple roots, what people will see depends on
which root they ask.How is this political?
By the sheer fact that they included a non-technical value-judgment.
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.
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. That one root must be supported by a set
of coordinated root servers administered by a unique naming
authority.
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 does not preclude private networks from operating their own
private name spaces, but if they wish to make use of names uniquely
defined for the global Internet, they have to fetch that information
from the global DNS naming hierarchy, and in particular from the
coordinated root servers of the global DNS naming hierarchy.
OK? Read that. Read it again. Read it a third time. *ALL* that
says is "If you want to agree what the DNS tree looks like, you have
to share a root. If you want your own view, use your own root.
That's the way DNS is. You're stuck with the fact that DNS works
that way. You have to make your own choice which root to use".
This is *NOT* rocket science. Geez. Now, given that they *SAY* right there
in that third paragraph that you're *TOTALLY* free to use your own root,
but if you want to agree with the rest of the world you have to share
a root, what value judgment are THEY making?
OK? Let me repeat that *AGAIN* for the clue-challenged:
RFC2826 SAYS YOU HAVE TO CHOOSE FOR YOURSELF. Which is more important
to *YOU*? 100% consistency with the rest of the world, or access to
your private name space? *YOU* evaluate, *YOU* choose, and RFC2826 is
nice enough to point out the problems you'll encounter.
Let me repeat that *ONE MORE* time.
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*.
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.
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.
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.
> 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.
...
I still say it's a self-serving statement with political motivations, and I
hope I have adequately explained why I think that.
One could argue that "single naming authority" does not necessarily imply that a single body is making the decisions of what is or is not in the root zone. The use of a single body is (arguably) the _easiest_ solution to the root zone edit control problem, not necessarily the best solution. Clearly, a model in which multiple cooperative bodies manage the editing of the root zone is workable -- there are several empirical proofs of such. However, it can be argued that in such a model, the cooperative is the "unique naming authority".
The issue isn't really about this however. New.Net is not a part of a cooperative. They are a commercial company deciding on their own what is or is not a good top level domain -- they are asserting (with the help of @Home, Earthlink, mp3.com, etc.) that they are the unique naming authority. I, for one, do not believe that this is appropriate or desirable.
Rgds,
-drc
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
> 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!
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.
> 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.
Hmm. A "60K text file that scales well" seems oxymoronic to me. It either
scales, or it's 60K. 
Forgive the cheap shot there, but there's a point to it: If client caches
have to get glue from/for as many different sources as feel like creating
TLDs, that text file won't be 60K for long. There's no reason it couldn't
end up being 60M eventually. Of course, a hierarchical glue system could
be established -- oh wait, that would be coordinated.
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.
> 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.
So, since 2826 never states who should be the distributor, it's not
engaging the political topic in question...
-c
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
and also
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.
So which is it? If conflicting roots break things, then the problem
*is* insoluble.
Remember that RFC2826 only discusses the issue of conflicting roots - there's
no technical reason not to hand-wave and aggregate all identical roots
under one "naming authority" (totally unspecified - it's *WHATEVER METHOD*
got all the identical roots to *be* identical, even if it was 5 kegs of
beer at a trade show 
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
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
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.
> 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.
Not if you don't offer your own foot to shoot. Domain squatters have
partially taught us this. All it takes is for someone to have a beef
with someone else. The most obvious example is .xxx. It would seem to
me that it would just be a matter of time before some organization
decided to create their own .xxx simply for the purpose of disrupting
the 'main' one.
> 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.
In the above example, this would likely not solve the problem. There
would be no reason for either side to back down, and each side would
want to choose the root operator they felt was most likely to decide
in their favor.
> 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.
The fact that there is a political debate surrounding it does not make
the document itself political. Whether the timing of its release, the
position of the author, etc are political in nature or not, the document
in and of itself stands as a technical one.
-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.