Re: [wg-c] modified proposal

[dwmaher@ibm.net]

I support this statement
David Maher

At 11:40 PM 10/10/99 -0700, Kent Crispin wrote:
>
>[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