[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: names and suing people
- To: DOMAIN-POLICY@LISTS.INTERNIC.NET, discussion-draft@giaw.org, domain-policy@open-rsc.org, List@giaw.org
- Subject: Re: names and suing people
- From: Kent Crispin <kent@songbird.com>
- Date: Thu, 16 Jul 1998 17:56:21 -0700
- In-Reply-To: <3.0.2.32.19980707221946.006e848c@mindspring.com>; from Jay Fenello on Tue, Jul 07, 1998 at 10:19:46PM -0400
- References: <3.0.2.32.19980707103348.006cf874@mindspring.com> <3.0.2.32.19980707011602.02f10204@mindspring.com> <01ef01bda93f$282a0c40$d7fd3b9d@tentacle.dns.microsoft.com> <01ef01bda93f$282a0c40$d7fd3b9d@tentacle.dns.microsoft.com> <19980706182859.32675@songbird.com> <3.0.2.32.19980707011602.02f10204@mindspring.com> <19980706235847.50505@songbird.com> <3.0.2.32.19980707103348.006cf874@mindspring.com> <19980707084252.38576@songbird.com> <3.0.2.32.19980707221946.006e848c@mindspring.com>
On Tue, Jul 07, 1998 at 10:19:46PM -0400, Jay Fenello wrote:
> At 08:42 AM 7/7/98 -0700, Kent Crispin wrote:
> >On Tue, Jul 07, 1998 at 10:33:48AM -0400, Jay Fenello wrote:
> >> - The name space should be expanded.
> >> - The new IANA should supervise the name space.
> >> - The new IANA should use fair, open and transparent
> >> processes.
> >>
> >> Do you agree with these points?
> >
> >Yes.
>
> I feel better already :-)
>
> >Let's try something a little more controversial:
> >
> > In order to supervise the name space, nIANA will need effective
> > leverage over the registries, so they don't just thumb their nose
> > at nIANA.
> >
> >Then we can talk about what kind of cross-jurisdictional leverage
> >there might be.
>
> I think this is a good idea. Cross-jurisdictional issues
> are a very important topic to Internet Governance. How do
> you suggest the nIANA exert leverage over the registries, and
> how do you suggest we address questions of jurisdiction?
This is a long post, which partly explains why it took so long to
respond. It covers more than just the jurisdiction question:
Regulation of TLDs
I believe it is possible to entirely avoid special governmental
involvement to support TLD regulation, which means that no special
edicts, treaties, or laws regarding nIANA should be necessary, in any
country. More than that, I believe that eliminating government
involvement is a positive good.
Karl Auerbach has expressed the view that we should design the
organization as we would like it to be, then somehow get laws passed
in the US that will implement the organization. My approach is
diametrically opposed -- I believe we should take it as a fundamental
requirement that the new organization *not* depend on any special
laws, and design the organization accordingly. This is for two
reasons: 1) special US legal status for nIANA would be a very hard
sell in other countries; and 2) special legal status raises a number of
serious complications, such as congressional cooperation and the quid
pro quo that would result.
And, when it get's right down to it, I am convinced that special legal
status is simply not necessary to get the desired results.
To start, here is a very simple conceptual model of the control
relationships between domains. Everybody knows this stuff, I just
want to be able to 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 your domain exist at your whim, because you
can add them to or delete them from your domain (zone file) whenever
you want. Also, in addition to entries of your own, you can sell or
rent entries in your zone file, and you are free to set contractual
relationships with the individuals you sell or rent the subdomains
to. [Note that this is a theory of regulatory control, not a theory
of technical control.]
You can define policies for these subdomains that your customers are
obligated by contract to follow. You can even define policies that
carry through to subdomains of subdomains, recursively. To a first
approximation, it's your zone file, 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. And that entity gets to set
policies for you that you must follow. 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, for policies to have any meaning there must be some
policing mechanism -- controls that are not enforced don't really
count. Every substantive policy, therefore, imposes an enforcement
cost. All other things being equal, a recursive policy imposes
higher enforcement costs -- potentially *much* higher enforcement
cost.
At the simplest 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.
But these contracts always have as an ultimate sanction removal from
the zone, and thus modulate the "State of Nature" model, and don't
entirely replace it.
A highest level zone is called a root zone (little "r"), and, in
this "State of Nature" model, the owner of the 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.
I have fancifully called this the "State of Nature" theory. It's
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 we need in thinking about how
to manage things. Note 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.
There is another fundamental conceptual building block to consider:
The Single Root Zone, and the "Root Zone Condition"
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, the goal 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.
Even more, the nature of DNS is such that an organization that
wishes to set up a competing Root zone can do so. And "little r"
local roots, with no pretentions of universality, are commonplace.
On the other hand, the existence of a single Root zone is of
fundamental importance to the Internet as a whole. 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, such as: 1) It must be extremely reliable; 2) must be
"trustworthy"; 3) must abide by widely accepted operational
practices; 4) must be cost-effective. Any Root zone that
substantially fails these goals will change to meet them, or be
replaced.
But the most interesting and far-reaching implication of that goal is
a bit subtle: a unified name space applies to the leaf nodes of the
DNS tree, and there are many more of them than there are intervening
nodes. Therefore, a promise of a unified name space is an implied
contract with all the end-users of the DNS.
That is, 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. I call this
the "Root Zone Condition".
In certain circumstances, the operator of the Root zone (nIANA)
might even be subject to legal action brought by those end users.
We can imagine, for example, a "class action" lawsuit brought by
unhappy end users. [This is one thing that incorporation in the US
gives us.]
TLDs are, by definition, the only domains over which the Root zone
has direct policy control, through the "State of Nature" model. It
can, of course, impose recursive policies. But even non-recursive
policies will greatly affect the character of the entire DNS
structure under the Root zone. [One could argue, therefore, that
the best way to decide these policies is to first decide what kind
of domain name system you want to have, then decide the Root zone
policies that implement that. Unfortunately, that reverse mapping
is cryptographically secure...]
Combining these two notions gives what I will call the "State of
Nature theory of TLD management": The Root is a zone like any other
zone; the TLD "owners" rent or otherwise aquire 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.(**)
However, the "State of Nature" enforcement mechanism (deletion from
the zone) is simply unavailable to nIANA, because of the "Root Zone
Condition". Concretely, nIANA cannot use the threat of removing a TLD
from the Root Zone as a means of enforcing policy, because once a TLD
is in the Root Zone, nIANA has a responsibility to the SLD owners in
that TLD to maintain the connectivity of their name space to the
Internet, regardless of what the TLD operator may do.
So therefore, the only means of control available will be through the
"registration agreement" contracts. But of course, these must
relative to some particular legal jurisdiction.
As an example, this might require that all TLD "owners" must sign a
contract, under US law, with nIANA. This would have the net effect of
placing all TLDs under US jurisdiction. Of course, many people will
be offended by such a development -- in fact it would present a giant
political problem. But contracts must be written in *some*
jurisdiction, and that jurisdiction *must* be convenient to nIANA.
But regulating TLD registries through such contractual means has
another problem -- in many ways a far more serious problem: as a regulatory
mechanism it is terribly flawed.
This can be illustrated through an example: imagine a TLD ".per",
"owned" by a company in, let's say, Japan. The owner of .per signs
the hypothetical US Root zone registration agreement, which
includes the usual "equal access" clause for registrars.
The owner of .per, let's further imagine, manages to get a trademark
for ".per". Things go on for a couple of years, .per 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 -- 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? A lawsuit in US court is the only option -- a
painful, expensive, ugly process, but nIANA, pushed to the wall by the
companies continued refusal to follow the registration agreement,
finally sues.
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 ".per" name -- nIANA doesn't. The company is
located in a jurisdiction foreign to the contract jurisdiction, and is
very difficult to pursue legally...
I have cast this as a case concerning registrar-registry policies.
But nIANA has little real leverage for any kind of enforcement through
registration agreements, under this "State of Nature" TLD model. For
example, a registry could refuse to pay fees to nIANA, or a registry
could refuse to follow technical standards. In general, international
lawsuits are an *extremely* inefficient and expensive way to enforce
policies.
This is a stark contrast to the case where nIANA owns the TLD name,
has a current copy of the billing database in its possession(***), and
has a set of *other* contractors already managing TLDs. In that case,
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. At some later time, if capacity demands warrant it, nIANA
will put out a bid for a new registry development contract.
These actions are enabled by nIANA having clear title to the TLD name
and to the database. Without that clear title nIANA's ability to
regulate the TLD space is hamstrung.
[Astute observers may note that the model I have presented here is not
exactly the MoU model -- the MoU model parcels out functions
differently, but IANA still remains the ultimate source of authority.]
The example I gave is *not* an extreme case, something that couldn't
possibly happen in practice. We need look no further than to NSI to
see 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
should be no big deal. In practice, it has physical possession of the
billing database, with open questions of legal ownership of that
database. This gives it enormous, luxurious negotiating room.
Imagine how much stronger NSI's position would be if it had a clear
intellectual property claim to ".com".
Then further imagine that NSI was headquartered in Japan; DOC/DOJ would be
negotiating with a Japanese company.
Then imagine that instead of DOC/DOJ the regulatory authority was a
small non-profit corporation.
This gives some idea of the difficulty nIANA would have in enforcing
policy. These difficulties can be *greatly* diminished if nIANA has
original ownership of the TLDs and the database.
To summarize:
The problem of policy enforcement is real, and it is an extremely
important problem for nIANA to solve. Partially because of the
jurisdiction problem, contracts between a TLD-owner an nIANA are not a
good way to solve it.
Instead, nIANA must assert and retain original ownership of all TLDs
in its zone, from the beginning. It must never delegate ownership of
TLDs; it must only delegate operation of registries. Likewise, nIANA
must also assert original ownership of the customer databases for the
TLDs.
Finally, I note that 1) these conclusions could well be moderated
after the development of a robust method of "chartering"
special-purpose TLDs; and 2) the ccTLDs are a large special case.
================================================================
(*)"State of Nature" arguments are an old philosophical standard, most
recently used (to my knowledge) in Robert Nozick's book "Anarch,
State, and Utopia"...
(**) I believe that the philosophical background to the "Root Server
Confederation" groups is essentially that of "State of Nature TLD
Management".
(***) Through, for 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.
--
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
Privacy Policy | Terms of Service | Cookies Policy