From the abstract on, the draft contains ample speculations on the
insular motives alternative root advocates are suspected to
have - but little evidence for this allegation.
Lynn then claims that alternative roots' decisions to include
particular top level domains have not been subjected to
the same tests of community support and conformance with the public
trust - as what? As the TLDs which will be included with the
He concludes that ICANN should give no preference to those who
choose to work outside of (ICANN's) processes, and outside of
the policies engendered by this public trust.
In the first section of the actual text, Lynn talks about technical
needs for a single authoritative root. Among his various arguments,
point 2 is particularly interesting:
typing in a web site address at two different computers configured
to reference different roots can result in reaching different web
sites - a particularly disturbing possibility if, for exampple,
money is to change hands or privacy or security concerns are violated.
Of course, this argument is quite weak - after all, establishing the
identity of your correspondent is a problem which is created by
the very fact that DNS adds a layer of indirection between "I want
to talk to ABC bank", and "I'm contacting abc-bank.de". (This is an
actual case - there were two regional ABC banks established in the
late 19th century, indepedently of each other. They clashed in the
late 20th century over domain name questions. Ups.) If the use
of the wrong root server directs your money the wrong way you
certainly have other problems than the alternative roots.
Also quite interesting is argument number 5, cache poisoning. In
particular, Lynn writes:
Because the DNS assumes a single-root system, resource records are
not marked to distinguish them according to the root from which they
Keep this in mind: RRs don't carry information on the root from
which they come. Says Lynn, in this section.
Section two of Lynn's draft is titled The Public Trust in
Coordinated Assignment Functions. This section talks about the
need for a central ICANN, and about the process which finally lead
to the creation of the incarnation we are dealing with. What's not
mentioned is more interesting: On the one hand, the fact that even
ICANN depends on the consensus of users and system administrators
who decide not to use an alternative root - or just don't decide and
go with their software's default configuration. On the other hand
the strong network effects which will occur quite naturally in the
domain name market, and may indeed make ICANN's monopoly a natural
As a consequence of this, the White Paper and much of the process
which should be used with ICANN, seems to be used as a justification
for a single root - which is actually a circular argument. After
all, we probably wouldn't need this entire process in a world in
which reasonable competition to ICANN would be possible. Market
forces could be relied upon instead.
Section three of the draft finally talks about the new TLDs.
We find more references to the white paper, and about ICANN's
accountability. Note, in particular, the following sentence from
the White Paper which Lynn quotes:
As Internet names increasingly have commercial value, the decision
to add new top-level domains cannot be made on an ad hoc basis by
entities or individuals that are not formally accountable to the
That part about formal accountability to the community is, I
suppose, open for debate.
The usual proof of concept argument follows: Completely ignoring
existing - say - pseudo-gTLDs such as .TV, the first round of new TLDs is
described as a
proof of concept of the technical and business feasibility of
introducing more TLDs into the DNS.
Of course, no experience was gathered about adding more TLDs over
the past years, right?
The section concludes with praise for the SOs - which
represent the consensus views of the technical and the
user/business/other institutional communities, respectivel
(where's that individuals' constituency again?) - and to those who
participated in the TLD lottery in Marina del Rey:
They chose to work within the community-based ICANN process, even
though they knew that only a "limited number" of TLDs would be
selected - at least in the first round
After the white knights have been identified, the black ones can be
dealt with in section four, Outside the Process:
There are those who are choosing or have chosen not to work within
the ICANN process and within the ICANN policy framework. For their
own insular motives, they have launched various "alternative" root
Mr Lynn: There's something between black and white. How about .WEB
who are in the alternative roots and have applied for a place in the
Section five finally talks about experimentation. After
identifying a number of reasonable requirements for experimental
services, the use of the RR class tag is suggested in order to
distinguish alternative roots from the canonical root.
Then, Lynn claims this:
For resource records within the standard root-server
system, this class tag is set to "IN". [...] Those that have
deployed alternative roots have not used a different class
designation, however, choosing instead to have their resource
records masquerade as emanating from the standard root, and creating
the potential for disruption of other's (sic!) operations.
First, note that the interpretation of the IN class as "masquerading
as emanating from the standard root" contradicts Lynn's argument
from section two of the draft which we quoted above:
resource records are not marked to distinguish them
according to the root from which they emanate
Second, this interpretation contradicts the normal - and generally
accepted - use of class IN records within internal networks. Third,
using different classes just doesn't make any sense if you want to
try different name spaces: Among other things, the IN class is
hardcoded into some resolver libraries (I checked the OpenBSD libc source which
just skips over any non-IN entries when asked for an IP address -
I'm sure they aren't the only ones with this kind of behaviour).
Thus, using RR classes in order to distinguish roots would basically
mean that you may have to change a lot of software (not just
configuration files) just if you want to use a different root
server. This is, of course, not practical.
Let me summarize. The discussion draft tries to argue against
alternative roots. Bad enough, we find circular arguments, blantant
misinterpretations, and actually obvious contradictions within the
draft itself, apparently added for the sake of polemics and empty
rhetoric. Serious analysis is mostly missing, despite the
announcements made in the introductory note.
There are indeed arguments why alternative, uncoordinated roots may
be a bad idea, or may just not have a chance to take off due to
network effects. There are arguments why ICANN can be considered as
a natural monoply which is kind of controlled by the white paper
process. And there are arguments why certain "alternative root
TLDs" should be included with ICANN's root. All these arguments
should be put onto the table.
Instead, all we are getting is this draft, with the URL threatening
that it'll be presented in Stockholm. What a pity.