================================================================
Private Ownership of gTLDs and Enforcement of gTLD Policies
Kent Crispin, Songbird
July 22, 1998
This short document explores private ownership of TLD and its impact
on the regulation of TLDs. I use the word "regulation" in this
document in a very generic sense: a "regulation" is an enforceable
policy; "to regulate" is to apply such regulations. I also
deliberately use the more general phrase "regulation of TLDs" instead
of the phrase "regulation of TLD registries", because registries are
not the only point at which regulation may be applied, though they are
the most discussed. In addition, the focus of the paper is on gTLD
policy enforcement, and not the general case.
Examples of such regulations are "gTLD registries will allow equal
access to all qualified registrars"; "gTLDs must allow registrations
from all comers on a non-discriminatory, fair basis"; "TLD registries
will pay $0.01/year/domain to nIANA to support the root nameservers".
If or when "chartered" TLDs are developed, some of the policies in a
TLD charter would be regulations.
There is wide agreement that the "New Organization" / "non-profit
corporation" / etc (which I will henceforth refer to as "nIANA" [1])
must establish policies that govern TLDs, though there is wide
disagreement about what those policies should be, or how extensive
they should be. This paper makes no presumption about the content of
those policies, how broad they are, the structure of nIANA, how
stakeholders are represented, what makes nIANA "legitimate", or how
power is given to nIANA. The paper only addresses the issue of how
policies can be enforced, not how policies are developed.
The important conclusion reached is that nIANA must be sure that there
are no intellectual property entanglements as far as the TLD names are
concerned, and must also have clear title to the contact databases for
the TLDs, if there is to be any realistic hope of regulating TLDs.
In the international context ownership of the TLDs ultimately will
determine who is in charge. If those running the registries are also
owners of the TLDs, then ultimately the registries will be in charge.
If nIANA "owns" the TLDs, in trust for the DNS stakeholders, then the
DNS stakeholders will be in charge.
I suspect that many will find the conclusions and arguments in this
paper almost trivially obvious, while others will find them an
anathema. However, I haven't yet seen a detailed exposition of these
obvious points, and frequently it is the obvious assumptions that
obscure communication.
I. The need for regulation
A basic tenant of this paper is that at least some regulation is
needed. An extreme libertarian view is that there is no need for any
regulation whatsoever -- that market forces are completely sufficient.
However, from a practical standpoint, the White Paper calls for fair
access by registrars, and this clearly requires some regulatory
function. Moreover, as the examples above indicate, there are other
areas where some kind of enforceable policies must be established.
Further, there are ongoing concerns about the monopoly power of
registries that must be considered, and there needs to be at least a
regulatory framework in place to deal with such abuses, should they
occur.
Another important reason for the need of regulation is the
infrastructural nature of the Internet. Government, educational
institutions, medical institutions, utilities -- all these are using
the Internet more and more every day. The Internet is like the phone
service, only potentially even more pervasive. If the Internet is to
fulfill its full potential as a deep part of the infrastructure of
civilization, it must be accountable to society at large. Such
infrastructural regulation usually comes through government.
Indeed, the ultimate source of regulatory authority always comes from
Governments, and their monopoly on force. One approach to TLD
regulation, therefore, is to make it a DIRECT Government function,
either by centralizing all TLD operations in a single country, or by
establishing an international treaty that defines the regulatory
framework. Other approaches use the power of government INDIRECTLY,
in its enforcement of contracts and property rights.
I believe it is possible to entirely avoid direct governmental
involvement in support of TLD regulation, which means that no special
edicts, treaties, or laws regarding nIANA should be necessary, in any
country. [1]
It is not just aesthetically or philosophically desirable to minimize
government involvement. There are at least two serious problems with
direct laws that support nIANA: 1) centralizing TLD administration to
one jurisdiction would seriously undermine any claims of international
neutrality; and 2) enactment of laws is a slow process, and
establishing treaties, as far as the Internet is concerned, operates
at speeds commensurate with continental drift.
But more to the point, perhaps, is that government control is almost
uniformly unpopular.
II. The State of Nature [2]
To start, here is a very simple conceptual model of the policy control
relationships between domains. Everybody is already familiar with
what I am about to describe; I just want to characterize it so we can
refer to it by name. I call it:
The DNS "State of Nature" Theory of Regulation
Control over a domain means you have control over the contents of
that domain -- the "zone file", in concrete terms. That is, the
immediate subdomains of a domain exist at the whim of the domain
owner, because they can be added or deleted from the zone file at
any time. If you are the owner of a zone file, you can sell or rent
entries in your zone file and you are free to set contractual
relationships with the individuals to whom you sell or rent the
subdomains.
You can define policies for these subdomains that your customers are
obligated to follow, on pain of removal from the zone. You can even
define policies that carry through to subdomains of subdomains,
recursively. To a first approximation, it's your zone file, and you
can do what you want with it.
In turn, however, if your domain is a subdomain of some higher level
domain, your domain name exists in that higher-level zone file at
the whim of the owner of that zone. In addition, that entity gets
to set policies that you must follow, on pain of deletion from the
zone. In fact, that entity can set policies for you, and require
you to maintain those policies recursively for all your subdomains,
on pain of being removed from its zone.
In general, however, for policies to have any meaning there must be
some policing mechanism -- unenforced policies don't really count.
Every substantive policy, therefore, imposes an enforcement cost.
All other things being equal, a recursive policy imposes higher
enforcement costs -- frequently much higher enforcement cost. This
additional enforcement cost is a natural incentive to limit
recursive policies.
At the raw state of nature level, enforcement of policies is through
the threat of removal of a domain from a zone. However, contracts
("registration agreements") may be involved that define the terms
and conditions of membership in a zone, and they can have any
conceivable clause that 1) the two parties are willing to agree to,
and 2) that fit into the general legal constraints on contracts.
However, these contracts always have as an ultimate sanction removal
from the zone, and thus modulate the "State of Nature" model, rather
than entirely replacing it. Of course, registration agreements draw
a legal system into the process, and therefore the notion of
jurisdiction.
A highest level zone is called a root zone (little "r"), and, in the
"State of Nature" model, the owner of a root zone has total freedom
to set any policies whatsoever on its subdomains, charge any prices
it likes, require any business model it likes -- anything. The
simple model of control inherent in DNS grants full power to the
owner of the root zone.
Of course, there is nothing to prevent multiple root zones, and,
while it would be a pointless philosophical exercise, a case could
probably be made that multiple root zones are the "natural"
consequence of a system based only on the "State of Nature" model.
This follows from the fact that while the owner of a zone is free to
eliminate entries in their own zone, they are also free to seek
arrangements with other root zones.
I have fancifully called this the "State of Nature" theory. Its
fundamental control mechanism is the ability to add or delete
subdomains. In the real world all sorts of other considerations enter
in, especial at high levels, but this fundamental control mechanism
remains of great importance, and it is one of the fundamental
conceptual building blocks of DNS management. Note again that, by
itself, it has no jurisdictional limits, though the entanglement in a
legal system implied by the use of "registration agreements" will
inevitably involve the notion of jurisdiction.
III. The Single Root Zone
The goal of the Root zone (capital R) is a single unified name space
for the Internet. To be more explicit, the goal is to be sure that
every IP address reachable through the Internet backbone can also be
uniquely named. By extension, one of the primary goals of the nIANA
exercise is to provide a (capital "R") Root zone.
This is an asymptotic goal, at best, and it is not a part of the
"State of Nature" model. DNS is a general mechanism, and nowhere is
it written in stone that a single connected name space must exist. As
noted, the nature of DNS is such that an organization that wishes to
set up a competing Root zone can do so. Moreover, "little r" local
roots, with no pretensions of universality, are commonplace.
On the other hand, the existence of a single Root zone is of
fundamental importance. Much of the economic power in the Internet is
a function of convenient universal connectivity, and a universal name
space is a necessary component of that convenience.
The "single unified name space" goal has certain implications for the
Root zone. It must be extremely reliable; it must be "trustworthy";
it must abide by widely accepted operational practices; and it must be
cost-effective. Any Root zone that substantially fails to meet these
goals will be changed, or will be replaced.
Thinking this far leads one to a particularly simple-minded theory of
Root Zone management: The Root is a zone like any other zone -- the
TLD "owners" rent or otherwise acquire an entry in the Root zone, and
manage their own zone files autocratically, modulated only by
recursive policies established by the Root. These recursive policies,
and any other policies, are enforced through Root level "registration
agreements" -- contracts between the Root zone operator (nIANA, or an
appropriate surrogate) and the owners of the TLD zones.
Alternatively, they are managed through the simple threat of removal
from the Root. This is a "State of Nature" model for the Root Zone.
[3]
IV. The Root Zone Social Contract
I have characterized the above model as "simple-minded". While many
are seduced by the simplicity of the State of Nature model, it is in
fact completely inadequate to describe the nature of the Root Zone.
The Root Zone has, in practice, many more unique characteristics than
just sitting at the top of the tree. For example:
1) It has a historical fiduciary character.
2) Stability must emanate from the Root. Clearly, if the Root is
unstable, then no subdomain can be stable, and thus the requirements
for stability are much greater on the Root Zone than on other zones.
It must be noted again that this requirement of stability is not a
surface requirement, although the rush to commercialize the Internet
tends to mask its depth. As time goes on the Internet will be an
indispensable part of the infrastructure of the civilized world, and
many completely automated functions will operate through it. Now,
thousands of hospitals losing access to remote medical knowledge
because the ".org" registry didn't meet certain policy constraints
would not, be a socially acceptable result. Fifteen years in the
failure of a national power grid could come from such an event.
3) The Root zone contains the top of the special .arpa zone, and
thus is entwined in the technical functioning of lower level
protocols in the Internet.
4) Currently the majority of the domains in the root zone are there
for their political significance (the ccTLDs).
5) In addition to the public service role alluded to in bullet 2,
above, the Root zone also provides essential service to government
and international organizations.
6) IANA has essentially no discretionary authority to remove any of
the current TLDs. The ccTLDs are controlled by ISO and political
concerns; .com, .org, and .net cannot be removed for practical
reasons; .gov and .mil cannot be removed for political reasons; .edu
can't be removed for historical reasons; .int can't be removed for
political reasons; and the .arpa domain cannot be removed for
practical and technical reasons.
These characteristics and more create an expectation concerning the
nature of the root zone, an expectation I will call the "Root Zone
Covenant". [4] It is an implied social contract with all the users of
the Internet:
The Root Zone Covenant
A Root zone operator that takes its task seriously, and likewise
wishes to be taken seriously, must assume a responsibility to those
end users, even though the end users have no direct contact with the
Root zone operator.
More succinctly, the Root Zone Operator cannot disenfranchise
end-users of the DNS: the Root Zone Operator will not willfully
cause users to lose connectivity to the global name space.
For our purposes the most profound implication of the Root Zone
Covenant is that the Root Zone cannot use the threat of removal of a
TLD from the Root Zone as a means of enforcing policy. [5]
Besides this argument from social contract, there are other arguments
that TLDs cannot be unilaterally removed by nIANA:
1) the practical legal argument -- if nIANA removed .com (for
example) from the root it is clear that it would be opening itself
to a lush garden of potential legal actions. This would be true for
smaller zones, as well -- the legal basis is the same, though the
war chest might not be as big.
2) the White Paper Priority argument -- the number one priority of
the White Paper is stability. Removing zones as a means of policy
enforcement is not conducive to stability; and
3) the alternate root argument -- if nIANA removes the .com zone,
NSI could simply start its own root zone and advertise it. This
would not be conducive to stability, either.
V. Inadequacy of the "State of Nature" Model
In the "State of Nature" model, TLDs are, by definition, the only
domains over which the Root zone has direct policy control. [6]
However, the fundamental "State of Nature" enforcement mechanism
(deletion from the zone) is unavailable to nIANA, because of the Root
Zone Covenant. The only remaining means of control available in the
State of Nature model are "registration agreement" contracts.
But again, these contracts would need to be drawn in a particular
legal jurisdiction. For example, nIANA might require that all TLD
"owners" must sign a contract, under US law, with nIANA. This would
effectively place all TLD policy under US jurisdiction. Many people
would be offended by such a development, and, in fact, it would
present a giant political problem.
Besides this political problem, regulating TLD registries through such
contractual means suffers from another, far more serious problem: it
is ineffective.
This can be illustrated through an example:
Imagine a gTLD ".tld", "owned" by a company in, let's say, Japan.
The owner of .tld signs a hypothetical US "Root zone registration
agreement", which includes the usual "equal access" clause for
registrars. [7]
The owner of .tld, let's further imagine, manages to get a trademark
for ".tld". Things go on for a couple of years, the .tld registry
does a good business, and makes a fair amount of money. Now,
suppose the owner decides that it doesn't want to honor the equal
access clause. That is, after a couple years operation it decides
that it wishes to be its own registrar, and to deny access to other
registrars.
What does nIANA do? If the company is intransigent a lawsuit is the
only option -- a painful, expensive, slow option, but the only one
available to nIANA, under the circumstances. Assume that nIANA
wins.
The company ignores the judgement, and continues registering names.
What does nIANA do next? The company has the contact database with
the billing information -- nIANA doesn't. The company owns
intellectual property rights in the ".tld" name -- nIANA doesn't.
The company is located in a jurisdiction foreign to the contract
jurisdiction, and is very difficult to pursue legally. By the Root
Zone Covenant, nIANA cannot remove the name "tld" from the Root --
to do so might actually open nIANA up to a lawsuit from SLD holders
in the .tld domain...
I have cast this example as a case concerning registrar-registry
policies. But nIANA has little real leverage for *any* kind of
enforcement through contracts. For example, a registry could refuse
to pay fees to nIANA, or a registry could charge higher prices for
"special" names, or it could collude with Domain Name pirates. In
all these cases, the only sanction ultimately available to nIANA
would be to go to court.
International lawsuits are an extremely inefficient and expensive way
to enforce policies. [8]
We needn't look far to find a real life example of how the problem of
unclear title to the TLDs and the associated database can be exploited
to considerable advantage:
In theory, NSI is simply a contractor, and the upcoming termination of
the contract with NSF should be no big deal. In practice, however, it
enjoys luxurious negotiating room. Part of that luxury stems from the
fact it has physical possession of a live billing database that must
continue to operate. All open questions concerning legal ownership of
that database add greatly to NSI's negotiating position. [9]
Additionally, NSI has made some light-hearted efforts to "brand" .com:
e.g. "Network Solutions: the people who brought you .com".
Imagine how much stronger NSI's position would be if it had clear
intellectual property title to ".com".
Then further imagine that NSI was headquartered in Japan; DOC/DOJ
would be negotiating with a Japanese company.
Then, finally, imagine that, instead of DOC/DOJ, the regulatory
authority doing the negotiation was a small non-profit corporation...
VI. nIANA Ownership of gTLD names and Databases
It should be clear from the above discussion that the key to the
problem is private possession of the gTLD name and database. There is
an old saying that "possession is nine tenths of the law"; when the
law is fragmented and complex, as the case in the international arena,
possession is even more important. We need an alternate model of
regulation, one that does not involve private possession of these
things.
In this alternate model, nIANA must have unencumbered control over the
gTLD name and database, in permanent trust for DNS stakeholders [10].
That is, instead of "selling" or "renting" space in the Root zone, all
the entries in the Root zone BELONG TO THE PUBLIC, through nIANA.
nIANA may enter contracts with registry operator companies to run
registries for TLDs on nIANA's behalf, but in those contracts nIANA
retains control or ownership, as a trustee for the public.
Note that the above paragraph speaks only of gTLDs. Essentially all
the current TLDs are already under some form of public control: The
ISO3166 TLDs explicitly belong to sovereign entities; .gov, .mil,
.edu, .int, and .arpa all belong to the public infrastructure. Most
people, I believe, would argue that .com, .net, and .org also belong
to the public. Thus, the question of private ownership only comes up
with new gTLDs. [11]
There are various means by which private ownership of TLD names may be
avoided. For example, ownership may be vested in a recognized public
body, like a government, or a standards body. (In fact, one of the
models for nIANA is as a public standards body). Another mechanism
might be for by nIANA to assert ownership of the name, and granting
public use in a manner similar to the Gnu Public License. Or rights
to a privately owned name might be given to nIANA (though such a gift
would have to be examined very carefully for attached strings). It is
not necessary that there be a single mechanism: the basic requirement
is that nIANA has control over the use of the name as a TLD.
There are also various means by which nIANA can maintain possession of
the TLD database -- the most obvious being that registry operators
would be required by contract to escrow the data in a place where
nIANA can always get it. [12]
To make this work most efficiently nIANA should have contracts
(directly or indirectly) with several registry operators, presumably
located around the globe. In the best case each operator should run a
registry for several TLDs, registry operations should be standardized,
and the various registries should act as backups for each other. It
would be straightforward to move a TLD from one registry operator to
another -- the transfer of the registry data and the TLD zone file
could be done with no interruption in service.
Note that such an arrangement gives nIANA a very flexible and
well modulated management regime. gTLDs can be moved for load
balancing; they can be moved as proactive policy enforcement.
International contracts will still be involved. But they are
straightforward work-for-hire contracts that are well understood and
common in an international context. They are not contracts that try
to implement a regulatory role.
This is a stark contrast to the "state of nature" example described
above. nIANA owns the TLD name, has a current copy of the billing
database available [13], and has a set of other contractors already
managing TLDs, perhaps with the data in question already on site. If
there is a problem with a contractor nIANA simply hands the data to
one of the other contractors (the contracts would already be written
to cover such cases), does a zone transfer, and changes the pointers
in the root zone. Later, if capacity demands warrant it, nIANA will
put out a bid for a new registry development contract. [13]
These actions are enabled by the establishment of clear title to the
TLD name and to the database, before a contractor is ever hired.
Without that clear title, nIANA's ability to regulate the TLD space is
hamstrung.
VII. Conclusion
The problem of policy enforcement is real, and it is an extremely
important problem for nIANA to solve. For several reasons, regulatory
contracts between a TLD-owner and nIANA are not a good way to solve
it.
Instead, nIANA must assert and maintain public ownership of all TLDs
in the Root zone, from the beginning. This ownership would involve a
trust relationship with DNS stakeholders. nIANA must never delegate
ownership of TLDs; it only delegates operation of registries.
Likewise, nIANA must also assert original ownership of the customer
databases for the TLDs.
================================================================
Notes:
[1] Some have complained about the name "nIANA". The new organization
will have the following responsibilities: coordination of IP address
allocation; assignment of TLDs and management of the Root Zone;
protocol number registration. The current IANA, by strange
coincidence, has precisely those same functions. Hence my use of the
term "nIANA", meaning "New IANA".
[1] Karl Auerbach has made a case that special laws will be necessary
for the initial transfer of the database from NSI to nIANA -- the
transfer of title to the .com/.org/.net registry database. I don't
agree that special legislation would be needed, but such one-time
special purpose legislation would not impact the ongoing regulatory
model in any case. On the other hand, laws that granted special
anti-trust exemptions to nIANA *would* impact the regulatory model,
and would have the effect of binding nIANA to the US.
[2] "State of Nature" arguments are an old philosophical standard,
revived in my memory by Robert Nozick's book "Anarchy, State, and
Utopia"...
[3] I believe that the philosophical background to the "Root Server
Confederation" groups is essentially that of "State of Nature TLD
Management".
[4] I called this the "Root Zone Condition" in a previous version.
[5] Jay Fenello has argued that a TLD can be removed from the root
zone in exactly the same way that "hotmail.com" could be removed from
the .com registry. That is, if NSI didn't pay their dues to nIANA,
nIANA would simply remove .com from the root. I contend that this is,
to put it mildly, unrealistic.
Paul Svenson has also argued that the Root zone is only different in
the number of subdomains that it holds. I argue that the Root Zone
special in quite a few ways, as indicated in the examples in the main
text. In fact, many more examples could be added. It is clear that
the Root Zone is special in many ways, and that this specialness is a
factor in the Root Zone Covenant.
[6] It can, of course, impose recursive policies on TLDs. But even
non-recursive policies will greatly affect the character of the entire
DNS structure under the Root zone.
[7] The "equal access clause" refers to a requirement that all
registries grant fair access to all registrars.
[8] Some may argue that international contracts are not so bad as a
regulatory mechanism, because businesses do business across
international boundaries on a daily basis. But the relationship
between nIANA and registries or TLD owners is not a just a business
relationship -- one of nIANA's fundamental roles is to be a way for
stakeholders to influence TLD policy through non-economic means, and
some of that policy may not be in the best business interest of either
party.
[9] This may sound like I am engaging in "NSI bashing". That is not
the case. NSI, as a for-profit company, now public, has an
affirmative duty to pursue these negotiations as aggressively as it
can, as would any company.
[10] While I don't really discuss nIANA's structure here, the phrase
"in trust for DNS stakeholders" is a necessary component. Private
ownership of the TLDs by nIANA is of course not intended.
[11] A further advantage: by eliminating private ownership of TLDs,
the Root Zone retains a management mode it has had from the beginning.
Given the emphasis on stability in the White Paper and elsewhere, this
continuity is highly desirable.
[12] Another example: a contractual requirement that updates to the
contact data be transmitted to nIANA on a daily basis. Failure to
transmit the data would be grounds to give the TLD to another
registry. But data escrow should be a requirement for data safety, in
any case. As mentioned, an attractive alternative would be that the
data be backed up to another registry operator on a daily basis. This
would serve two purposes -- redundancy in case of any failure, and as
a policy enforcement lever.
[13] I note that my position on multiple registry operators is not
exactly the PAB/POC/CORE position. Designing an international
distributed TLD registry (which is what we are actually discussing) is
a non-trivial task, though the CORE work covers most of the bases,
complete development of a multiple registry system still needs some
work.
-- Kent Crispin, PAB Chair "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html