[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wg-c] Final version of proposal
Please add my name to the list of supporters
David Maher
At 08:35 PM 10/18/99 -0700, Kent Crispin wrote:
>
> 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.
>
> Eric Brunner
> Kent Crispin
> Dave Crocker
> Javier Sola
>
>--
>Kent Crispin "Do good, and you'll be
>kent@songbird.com lonesome." -- Mark Twain