[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[wg-c] another supporter added
[Nothing has changed in the paper itself. I hate to keep sending the
full text to the list, but no simpler procedure has been suggested
for these kind of updates, and of course, I don't want them to get
lost.]
Position Paper on New gTLDs
Kent Crispin
Oct 18, 1999
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, 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
common sense, as the entity that runs the back end database for a
TLD, and does not 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. This model also 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.]
The following people have indicated support for this proposal. Such
support does not mean that they necessarily agree with every detail,
but rather that the proposal is something they could live with and
work from. All are members of wg-c.
Eric Brunner
Kent Crispin
Dave Crocker
Joseph Friedman
Jim Glanz
Javier Sola
--
Kent Crispin "Do good, and you'll be
kent@songbird.com lonesome." -- Mark Twain