|
Part I of this article explored some of the current thinking and direction that key policy-makers seem to be headed with the creation of new gTLDS. This part focuses on a new alternative plan for the ongoing deployment of new gTLDs.
ICANN is likely to see many proposals over the coming weeks that attempt to deal with the thorny issue of how to rollout new gTLDs. Any plan that deals with the rollout of new generic top-level domain names must ensure that the expansion of the namespace does not disrupt the existing infrastructure and services.
In other words, do what you will, but please, don’t break the Internet.
Not breaking the Internet requires an understanding of what “the Internet” is. The Internet is a place where communications are fostered, where open standards promote innovation and competition, where the importance of technology exceeds that of time or place. The Internet is a place where good ideas win and bad ideas vanish in a Darwinian cloud of “wonder what happened to them” smoke. It is a technology, a thing, and a place. Something that demands care and attention, but only in a minimalist sense. The Internet is like the lilac bush that demands favorable environmental conditions like sun and water, but also an occasional interventionist pruning.
Minimal intervention is a fundamental component of “please don’t break the Internet”. Strict regulation, heavy policy and overly prescriptive guidelines will all lead to harm—stifled innovation, defeated competitive principles and increased transaction costs.
Any plan we decide upon must be sustainable over the long term. The community does not want another stop gap solution, does not need more time to analyze the available data and should not tolerate anything else but a completely thought-out plan that finally allows us to proceed with confidence or to finally put the question to rest.
We need to establish a doctrine—a collection of principles that guides how and why we make decisions about the ongoing introduction of new gTLDs.
The Doctrine:
We need to agree on a final plan of action that addresses the concerns of all involved. The following proposal is not intended to be the final word. It is a starting point that attempts to move the discussion forward.
The ICANN Accredited Registry and TLD Sponsorship Program
The current gTLD roll-out program is defined by three operational models; i) Sponsored/Chartered, ii) Unsponsored/Chartered and iii) Unsponsored/Unchartered. (Theoretically, there is also a Sponsored/Unchartered category as well, but no one has come up with a compelling plan for an operation that fits into that category). As discussed in the previous installment of this article, there are many problems with the selection process that leads to these types of determinations. Principally, the effort that it takes to put bids into these different categories is entirely too subjective.
We need a different way to look at this problem.
There are two parties that are critical to the successful launch and operation of any gTLD—the party that receives the delegation and the party that operates the delegation. Sometimes these are the same entity (as with .COM) and sometimes they are not (as with .ORG). These two parties need a more visible role in the process. Their function needs to be evolved so that it is more meaningful and more sustainable.
For the sake of simplicity, let’s call these two roles “the Delegant” and “the Operator”—and try to avoid confusing them with the existing terms, “TLD Sponsor” and “Registry Operator”. Remember, our goal is to evolve these rudimentary roles, not preserve them.
Each of these roles has a central function in the process—prospective delegants need to apply to ICANN to receive a delegation for a gTLD string that has not been previously delegated by ICANN. Applications by prospective delegants will be dealt with by ICANN on a first-come, first-served basis. Existing applicants should receive similar first-come, first-served priority. Operators are accredited by ICANN. Successful Delegants will contract with, or become, Operators. This pairing forms the basis for the ongoing management of new gTLDs.
The Operator is a technical coordinator that ensures that the gTLD works from day to day. The Operator develops and implements new standards, manages the registration and publication function of the registry and upholds a minimum standard of transactional and technical integrity. Operators must be accredited by ICANN in much the same fashion as registrars are. They must receive their accreditation before they will be allowed to technically manage a gTLD under contract with a Delegant. The criteria for accreditation is simple—it is the sum of minimum standards that it takes to technically operate a registry—database capability, protocol interoperability, zone file publication, capability to escrow and so on. There should be no policy limitations to the number of gTLDs that an Operator can contract with a Delegant to manage.
The Delegant is the policy coordinator for the gTLD that ensures that the registry operates in a manner that benefits its target community. A Delegant should be expected to behave as outlined in RFC 1591 if they wish to be approved to receive a delegation. Delegants will be approved based on simple and straightforward criteria.
1. The desired gTLD string must not be confusingly similar to an existing gTLD string. For example, an application for .C0M (c zero m) should not be approved, nor should .NETWORK. This does not however imply that a TLD must be uniquely distinct within the namespace. The opportunity to operate .PER in competition with .NAME or .BIZ in competition with .COM must not be precluded by any criteria as it represents one of the more compelling reasons why expansion is desirable in the first place—competition at all levels of the DNS is something that we should strive for. gTLDs are no different.
2. The Sponsor must present a balanced and reasonable plan for the operation of the TLD that includes any significant policies that affect the operation of the gTLD. For instance, any limiting charters must be noted up front. This is desirable because it provides the community with important disclosure and allows for community perceptions to be managed from a very early date.
3. The Sponsor must demonstrate that an accredited Operator is willing to manage the technical function of the TLD for a minimum specified period of time.
4. The Sponsor must indicate their willingness to forgo all rights and interest in the specific string as it relates to the use of the string as a TLD. This is especially important as it relates to ICANN’s capability to transition a string to a new Sponsor.
It is not important that there be an identifiable link between the target community for a particular gTLD and the actual gTLD string (i.e. .NAME is for individuals, but .NET is not for network operators). A Sponsor is not accredited so much as they are approved. A Sponsor can seek approval by filing an application to receive a delegation for a string and paying an application fee. The commercial relationship between a Delegant and an Operator are a private matter but the relationship must at least permit redelegation or technical transition in the case of a business failure.
In order for this proposal to be successful, ICANN needs to be willing to accredit as many Operators as is necessary to manage the operations of the Delegants that they approve. ICANN will also need to ensure that the processes and criteria used to accredit the Operators and approve the Delegants be as standardized as possible. Lastly, some consideration of historical precedent needs to be undertaken to ensure that this proposal remains consistent with the practice and goals of the community.
The next and final piece in this series will focus on the relative merits of this plan in comparison to others that have come forward.
—-
This article is reproduced with special permission from Tucows Inc. Copyright 2003, Tucows Inc. All rights reserved. URL. Author expresses special thanks to Bret Fausett, Joanna Becket and Thomas Roessler for their assistance and input.
This work is licensed under a CreativeCommons License.
Sponsored byVerisign
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byCSC
Sponsored byWhoisXML API