[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[wg-c] Re: [wg-c-3] Notes on new gTLD registries
This is a belated reaction to a note Kent posted to wg-c-3 last week. He
urges that we should have new gTLDs, but that the *only* ones to be added
for now should come from the CORE set, and should be operated by
not-for-profit shared-registry operators. Why? Because only that
decision, he explains, has sufficient consensus support to be adopted in a
reasonable time frame. I'm at a loss to understand this. I think there
would be little objection to including CORE gTLDs in the first dozen or so
rolled out. But the idea that we should include *only* the CORE gTLDs in
the ICANN root now, while rejecting any inclusion of proprietary gTLDs
until after the attainment of an unattainable consensus, strikes me as at
least as controversial as any other proposed approach. If we're to adopt
Kent's position, it will have to be on some basis other than its asserted
consensus support.
I'm also puzzled by Kent's assertion that the White Paper mandated that
new gTLD registries be shared. The White Paper took no position on this
issue, but, if anything, its discussion favors a system of "competitive
and/or for-profit" registry operators. Here's the key White Paper language:
>>>>>Both sides of this argument [whether new gTLD registry operations
should be run on a "competitive and/or for-profit" basis] have considerable
merit. It is possible that additional discussion and information will shed
light on this issue, and therefore . . . the U.S. Government has concluded
that the issue should be left for further consideration and final action by
the new corporation. The U.S. Government is of the view, however, that
competitive systems generally result in greater innovation, consumer
choice, and satisfaction in the long run. Moreover, the pressure of
competition is likely to be the most effective means of discouraging
registries from acting monopolistically.
Jon
Jon Weinberg
Professor of Law, Wayne State University
weinberg@msen.com
>
> Notes on New gTLD Registries
> July 7, 1999
>
>
>Terminology
>-----------
>
>It's probably impossible to get everybody to agree on terminology,
>but at least I want to be sure that people understand what I am using:
>
>database: (abstract) a formally structured collection of data;
>(concrete) a system of computer software/hardware that implements a
>database.
>
>TLD: One of the entries in the IANA-approved root zone.
>
>gTLD: a TLD that has no enforced criteria for the entities that may
>register in it. This departs from the rfc1591 definition.
>
>Registry: a database associating DNS information with some person,
>legal entity, operational entity, or other referrent. Note that we
>can speak of a registry in the abstract or in the concrete, as per
>the definition of "database" above. To emphasize the abstract
>meaning we may use the terms "registry database", or possibly
>"registry data".
>
>gTLD registry: a registry for a particular gTLD ("the .com registry").
>
>Registry operator: the organization or business that operates a
>registry. This distinction is very important: NSI is the operator
>of the .com registry; Emergent was the operator of the prototype
>CORE registry.
>
>Registry administrator: registry operator.
>
>Registrar: an entity with a direct contractual relationship with, and
>special access to, a registry, that inserts records on behalf of
>others.
>
>Registration agent: Registrar
>
>Shared Registry: a registry that allows access from multiple
>distinct registrars.
>
>
>Premises
>--------
>
>While it is possible to argue these in other contexts, I consider
>them to be part of the ground rules of this discussion:
>
>1) New gTLD registries will be shared registries (mandate from
>white paper)
>
>2) ICANN will accredit all gTLD registrars (white paper; ICANN/USG
>MoU)
>
>3) We are only interested in the IANA root zone.
>
>4) The dns system is part of the public service infrastructure -- it
> includes governments, schools, museums, and long-term data
> archives as its users. With the deployment of the vastly large IPV6
> address space, individual traffic lights could be have domain
> names, and be synchronized over the internet. Consequently,
> stability of operation of the dns is the *primary* requirement.
>
>
>
>Profit, non-profit, cost-recovery, public trust/resource
>--------------------------------------------------------------
>
>A substantial body of opinion exists that *all* gTLD registries
>should be public resources; there is another body of opinion that
>states that some gTLD registries could be privately controlled; but
>there is no significant body of opinion that states that *all*
>registries must be privately controlled. That is, no one has a
>significant problem with there being some "public resource" oriented
>gTLDs.
>
>The controversy, therefore, has been over whether there should be
>privately controlled gTLDs. Feelings run very deep on both sides of
>this issue, and it seems clear that the controversy will not reach
>a consensus.
>
>Therefore, the only prospect for getting new gTLDs in the root in any
>reasonable time frame is for them to be admitted under the "public
>resource" model.
>
>The characteristics of the "public resource" model are as follows:
>
> The registry data is considered a public resource, subject to
> privacy limitations, held in trust for the public by ICANN.
>
> 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. The registry operator may be removed for cause, and the
> contract would be rebid on a periodic basis.
>
> Since the data in the registry is considered a public resource, it
> should be escrowed under different control from the registry
> operator, and in widely dispersed jurisdictions and locations.
>
> Ideally, there would 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
> gTLD registries at the same facility.
>
> Even more ideal, the transfer of registries from one registry
> operator to another would be completely routine -- for example, a
> small company in a location with lesser internet access could run
> several very small registries, but transfer a gTLD to another,
> better connected registry operator if the load got to high. This
> would enable developing countries to develop registries.
>
> 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 switchovers would
> be a far more bombproof and resilient system.
>
> A requirement of easy transferability of registry data is that the
> underlying software and protocols be standardized.
>
>
>Concrete Proposal
>-----------------
>
>With the above model in mind, I propose the following:
>
> 1) Six new gTLDs be approved immediately. I would propose that
> they be chosen from the IAHC gTLD set; and that CORE relinquish any
> intellectual property rights they may have acquired in these names
> to ICANN.
>
> 2) That a request for proposal for registry operators be tendered
> quickly. The goal of this rfp would be for three independent
> registry operators from three different regions of the world to
> operate six gTLD registries, two per operator.
>
> 3) That ICANN support the standardization effort in the IETF for a
> shared registry protocol, and that the six new registries all use
> this protocol.
>
> 4) That the new registries operate according to the public
> resource model described above.
>
>
>
>
>--
>Kent Crispin "Do good, and you'll be
>kent@songbird.com lonesome." -- Mark Twain
>
>