[wg-c] modified proposal

[Kent Crispin <kent@songbird.com>]

[I have revised this paper in light of public and private comments
received.  Eric Brunner indicated that he would like to be listed as
a co-signer of the first document; he has seen the revisions, and,
though he has some reservations, he is willing to support this
revised version.  Javier Sola asked for some clarification of
motivation, and other things.  I have also addressed some issues
raised by Dave Crocker, Tony Rutkowski, and others.]


                  Position Paper on New gTLDs

Motivation

Concerns such as human freedom, individual rights, intellectual
property rights, increased competition, avoidance of monopolies, and
so on, are of course very important.  But, because they have been
addressed at great length elsewhere, they are not emphasized in this
proposal.  Instead, this proposal concentrates on another area,
largely ignored in the debate so far -- the area of Internet
stability. 

The basic question of stability, as far as DNS registration services
are concerned, is "what happens if the registry becomes unavailable"?
In concrete terms, for example, what happens if Network Solutions
registry is taken out of commission for an extended period of time
through physical, political, or economic disaster? Who would take
over? How would the data be recovered?

Of course, in the short term the correct functioning of the Internet
does not depend on being able to register domain names, so short term
outages of a registry are not significant.  But a long term breakdown
in the registration process would have serious impact, and loss of
the registration data could lead to chaos, as there would be no way
to establish "ownership" of a domain. 

Just to emphasize the point, in the view taken in this proposal the
fundamental problem with the current state of affairs is not that NSI
is a monopoly, or that there is lack of competition in the
registration business (though these may indeed be problems). 
Instead, it concentrates on the fact that there is a single point of
failure for a critical service, and proposes a model to alleviate 
that problem.

The basic model is of multiple registries, each capable of managing
registrations for multiple TLDs.  The registry data for each TLD is
transportable, and replicated or escrowed.  The destruction or
unavailability of any particular registry can be remedied by another
registry taking over its functions, within a time frame consistent
with stability.  Note that from the point of view of registry
operation, a ccTLD registry is no different from a gTLD registry, and
indeed, the same entity could run registries for several gTLDs, in
addition to its ccTLD.  [The term "registry" is used in the
now-conventional sense, as the entity that runs the back end database
for a TLD, that supports multiple registrars, and does not itself
include registrar functions.]

Within this model, there is a need for multiple new gTLDs, not for
competitive reasons per se, but instead to support the multiple
registries needed for stability.  The model argues against
"proprietary" TLDs, because of the potential legal difficulties in
moving the registry data from one registry to another.  It also
argues against any form of monopoly by a registry operator --
this may be controlled by requiring non-profit status, but other
mechanisms may be used (NSI is under price controls).  Finally,
this model makes no presumption about the ultimate desirable number
of TLDs, except in that it seems necessary to add more TLDs in the
near (1 to 3 year) time frame to develop the infrastructure needed
for stability. 


Proposal

1) Five to nine new TLD names be approved forthwith with the intent
that they be run as totally open gTLDs.  No further open gTLD names
should be approved until a process for approval of "chartered" or
"sponsored" TLDs is in place, and at least as many "chartered" or
"sponsored" TLDs are approved. 

These initial names should be selected completely independent of any
consideration of registries to run them. 

2) ICANN should publish a request for proposal for registry
operators.  The goal of this RFP would be the selection of five
independent registry operators, one from each ICANN geographical
region.  Some of these operators would operate more than one TLD, 
and the RFP should include plans for orderly transfer of TLDs from 
one operator to another.

3) The proposals generated by the RFP should for the operation of a
registry in general, and should not be tied to any particular TLD
name or names.  ICANN should select these registries on the following
grounds: 1) on regional affiliation; 2) plans to implement the
"public service" model, described below; 3) technical competence.

4) Allocation of TLD names to registries should not happen until
after the registry operators are selected, and should be done through
a completely independent process -- perhaps random selection. 
Registries with more than one TLD assigned should be prepared to move
the TLD operations to another registry, as designated by ICANN, and 
ICANN should, on perhaps a random basis, exercise such moves on a 
regular basis.

5) ICANN should expeditiously publish an RFP for "sponsored" or
"chartered" TLDs, to give entities that feel such TLDs should exist
the opportunity to propose them.  Such proposals would need to go
through an approval process to be developed by ICANN/DNSO.  Since no
further TLDs can be approved until this approval process is in place,
the highest priority should be placed on developing it.

A "sponsor" for a TLD is an agency granted a certain degree of policy
authority over a TLD.  The idea has been around for some time, though
the term has not.  The relationship between ICANN and the sponsor
would need to be carefully delineated; ICANN may, for example,
require the sponsor to indemnify ICANN.  The characteristics of a
sponsor, and the conditions under which a sponsorship could be
revoked must be very carefully explored as well. 

6) ICANN should support the standardization effort in the IETF for a shared
registry protocol, and that the new registries commit to using and
developing this protocol. 

7) All new registries should operate according to the public resource
model described below:

  The registry data is is not owned by the registry, it is subject to
  privacy limitations, and escrowed in favor of ICANN in case the TLD
  must be moved, for failure, mismanagement on the part of the
  registry operator, or similar reasons.  The data in the registry
  should be escrowed under different control from the registry
  operator, and in multiple widely dispersed jurisdictions and
  locations.  Backups at another registry would be highly desirable. 

  The registry is operated as a shared registry on a not-for-profit
  cost-recovery basis.  The registry operator, however, may be a
  for-profit company, operating the registry under contract to ICANN,
  or to an ICANN-approved registry sponsor.  The registry operator
  may be removed for cause, and the contract must be rebid on a
  periodic basis. 

  A TLD may be run under the aegis of a registry sponsor, which may
  enforce restrictions on registration in the TLD.  Such restrictions
  must be approved by ICANN, and must be fairly enforced. 

  There should be several registry operators, any one of which could,
  within a few days, assume operation of a gTLD registry from
  escrowed data.  These registry operators should be distributed
  worldwide.  Presumably each registry operator would operate several
  TLD registries at the same facility. 

  The transfer of registries from one registry operator to another
  must be a straightforward technical operation. 

  [Registry operators can fail; physical disasters can strike a
  particular installation.  Having multiple dispersed registry sites
  with multiple operators gives a great deal of robustness to the
  whole DNS.  A single monolithic site, no matter how secure, can
  fail, but distributing registries like this, with escrowed copies
  of the registry data available for quick switch-overs would be a far
  more robust and resilient system. 

  A requirement of easy transferability of registry data is that the
  underlying software and protocols be standardized.]



  Eric Brunner
  Kent Crispin