Executive Summary
ICANN has recently announced plans to significantly expand the universe of generic top-level domains (gTLDs). Starting in 2009, ICANN plans to allow parties to register virtually any alphanumeric string as a gTLD. This expansion of the domain name space presents significant challenges and opportunities for our clients.
ICANN has published a draft Handbook outlining its initial proposal for managing the new gTLD application process.This Summary is intended to provide an overview of and comments on the proposed application process.
Overview of the Application
Process
The Handbook is organized into six modules, which are arranged in order of the steps of the application process. Module 1 provides an overview of the application process and the materials required of applicants. Module 2 outlines the Initial Evaluation process, during which ICANN evaluates the applicant's financial and technical ability to operate a gTLD registry, assesses whether the gTLD would adversely affect the domain name system (DNS), and determines whether the proposed gTLD is likely to cause string confusion with an existing or applied-for gTLD. Module 3 covers dispute resolution, including who has standing to object and who will adjudicate disputes. Module 4 explains the process of evaluating proposed gTLDs for string confusion and resolving string confusion conflicts. Module 5 outlines the process for delegating the gTLD to the applicant so that it may register second level domain names within the gTLD. Module 6 is an appendix with draft terms and conditions for new gTLD applications.
Thus, the timeline for a new gTLD application is as follows:
1. Filing and Administrative Completeness Check2. Initial Evaluation
3. Third-Party Objection and Dispute Resolution
4. String Contention (separate assessment by ICANN as to whether a proposed gTLD is too similar to an existing or concurrently-applied for gTLD)
5. Delegation
Summaries of Each
Module
Module 1
Summary
Module 1 sets forth the basic application requirements and timeline. Applicants for a new gTLD will be required to answer a series of questions concerning their financial and technical capability for operating a domain name registry.
Applicants will also be required to specify whether the proposed gTLD will be open (i.e. usable for any purpose) or community-based (operated for the benefit of a defined community with a restricted population). If the latter, the applicant will be required to: (a) demonstrate a relationship with the community; (2) establish that the proposed domain name "strongly and specifically" relates to that community; (3) propose dedicated registration and use policies for second level domain name registrants; and (4) show that the application has been endorsed in writing by an established institution representing the community.
Applicants for new gTLDs are also required to pay an evaluation fee of $185,000 and demonstrate financial ability to fund registry operations for a period of three to five years so that domain name registrants are not adversely affected by registry failure or the need to appoint a successor registry.
Comments
The timeline set forth in Module 1 procedure is that the string contention
resolution takes place after
resolution of third party disputes, rather than before. This requires third parties (like trademark
owners) to expend resources to challenge a proposed gTLD that may not even
survive ICANN's string contention review.
Conducting the string contention resolution before the third party dispute process
allows those third parties who may have an interest in preventing registration
of a proposed gTLD, but no desire to become a registry in their own right, to
identify the names that ICANN has deemed to be entitled to registration. An analogy can be drawn to trademark
registration practice in the
The high fees and solvency requirements will likely be a significant
deterrent to speculation/ cybersquatting in new gTLDs, but will also present
issues for clients that may wish to defensively register gTLDs. ICANN has not outlined any process for
defensive registrations of gTLDs. We
believe that ICANN should consider either creating a reserved name list of
globally famous marks that could not be registered as gTLDs, creating a
Module 2
Summary
Module 2 fleshes out the elements of the Initial Evaluation, which consists of two parts: the string review and the applicant review.
The string review focuses on whether the applied-for gTLD is so similar to another as to cause string confusion, or would otherwise disrupt DNS security or stability. String confusion is deemed to exist when a proposed gTLD so resembles another visually that it is likely to deceive or cause confusion. The existence of string confusion is determined by a panel of ICANN examiners, who may rely on the results of a comparison using a publicly-available algorithm. For string confusion to exist, confusion must be "probable, not merely possible", and the mere fact that one string brings another to mind does not give rise to string confusion. If string confusion exists, ICANN creates a string contention set and initiates the procedure for resolving string contention set forth in Module 4, unless the confusion is with one of a series of names that ICANN has reserved, in which case, the application is simply refused. Domains that consist of characters other than letters, digits or hyphens, or which may be confused with IP addresses, will also be refused because such names are viewed as disrupting DNS stability.
For geographic names, a special Geographic Names Panel (GNP) within ICANN will determine both whether the name has geographic significance and whether the applicant has provided sufficient evidence that the relevant governmental authority supports or has no objection to registration of the gTLD.
The applicant review determines whether the applicant is financially and technically capable of operating a gTLD registry, and whether the applicant's services might adversely affect DNS security or stability. As discussed above, this evaluation includes an evaluation of the applicant's ability to fund registry operations for three to five years.
ICANN evaluators may request additional information from the applicant during the Initial Evaluation. Only one exchange of information is permitted during the Initial Evaluation Period.
If an applicant does not pass the Initial Evaluation because of issues raised in the applicant review or because of concerns relating to the impact of the proposed gTLD on the stability of the DNS system, it may request an Extended Evaluation on submission of an appropriate notice and filing fee.
Comments
We believe that the standard for assessing string confusion is too narrow because it focuses only on visual similarity. Two gTLD strings that are phonetically or conceptually similar would not give rise to string confusion under ICANN's framework. While we recognize that the Initial Evaluation, including the string review, is conducted ex parte and that interested parties with standing have an opportunity during the Initial Evaluation process to object to a proposed gTLD (see Module 3), we nonetheless believe that focusing only on visual similarity does not advance the goal of preventing concurrent registration of gTLDs that are likely to cause confusion, mistake or deception.
Module 3
Summary
Module 3 of the gTLD Guidebook provides the procedures for objection and dispute resolution and contains the grounds for formal objection by third parties concerning gTLD applications submitted. The dispute resolution procedure is triggered by an objection. Under Module 3, third parties who want to challenge the registration of a new gTLD have four grounds upon which to base their objection(s):
1. String confusion objection;
2. Legal rights objection (based on trademark rights or other legal rights of objector);
3. Morality and public order objection (this section is under construction but is intended to be based upon "international legal principles"); and
4. Community objection (granting application will cause detriment to community on which gTLD is focused).
Each ground of objection will have a separate designated Dispute Resolution Service Provider (DRSP). A party that files with the wrong DRSP may have their complaint rejected and be given only ten days to re-file it with the correct DRSP. There does not appear to be a procedure for objections arising under multiple grounds.
Cases will be heard by single panelists in all cases except morality and public order objections. A panel decision by a DRSP is deemed "a final decision." No appeal process is outlined.
Panels are discouraged from permitting discovery, and are given discretion, "where practicable," to disallow it entirely. The panel is also empowered to appoint experts at the parties' request even in the absence of a request from the parties.
Comments
General Comments
We believe that there should be a single organization or agency with which all objections should be filed, with said agency then reviewing the objection to determine which DRSP should resolve it. We believe that this would be a more efficient and timely process, and would resolve the current ambiguity concerning where objections under multiple grounds should be filed. Even with this amendment, we believe ICANN should provide more guidance on how to resolve disputes arising on multiple grounds. In the absence of further clarification on this issue, it will be difficult for legal rights holders to conduct a cost benefit analysis of pursuing or challenging a gTLD application.
We also believe that the option to have three panelists hear a dispute should be available for all types of disputes and not be limited to morality and public order objections.
We also recommend that there be clearer guidelines about the availability of discovery and the procedure for requesting discovery be provided. It seems that in certain cases, discovery will be necessary, if not imperative, to evaluate certain disputes.
We also believe that the rule allowing panels to appoint experts sua sponte should be rethought, especially as there are no provisions requiring advance notice to the parties of an expert's appointment or guidelines regarding the costs of such experts. A party with notice might decide that the expense of an expert outweighs the value of obtaining a domain name and drop its case. For these reasons, we believe that panelists should not have the authority to appoint experts unless requested by at least one party, with notice to the opposing party, before that party becomes responsible for the associated expense of the expert. Panels should not be permitted to appoint experts on their own initiative without, at a minimum, prior notice to the parties (including an estimate of costs) and a period during which either party can opt out of the proceeding without being responsible for the expert costs. If ICANN is going to appoint experts, it should establish a schedule of fees so that parties can make a cost-benefit analysis prior to filing objections.
Finally, we believe that some type of review/appellate process will be necessary to ensure rights to gTLDs are properly determined, particularly if the parties are not permitted to retain three panelists for string confusion, legal rights, and community objections.
Comments on Specific Grounds for
Objection
Our views on string confusion are summarized in our comments to Module 2.
With respect to legal rights objections, it is not clear what happens if an objector with prior rights prevails in a dispute resolution proceeding, but either does not want or is not able to operate the gTLD registry. ICANN should establish a list of such gTLDs for which future third party applications to register will not be accepted. ICANN should also create procedures to determine what happens when two parties with legitimate rights in a name attempt to reserve the same gTLD at the same time.
The rules on morality and public order objections have
not been drafted. ICANN proposes to
establish "generally accepted legal norms of morality and public order that are
recognized under international principles of law." This will be extremely challenging. In addition, it is not clear who would have
standing to bring this type of challenge.
For community objections, the Handbook states that it is a complete defense if the applicant is a member of the community to which the domain name refers or relates. This could create a land rush for generic names.
The Handbook is also very vague on the subject of what constitutes a "community." We recommend that ICANN provide more specific instructions regarding how to determine what constitutes a community, examples of groups that would merit classification as a community and groups that would not, or both. Without such guidance, businesses otherwise interested in acquiring a gTLD will be dissuaded from making the substantial investment in application fees and other costs because of uncertainty regarding who might be able raise a community based challenge.
Module 4
Summary
Module 4 outlines the process for identifying and resolving contention sets, which are collections of two or more proposed gTLDs that have been identified as creating string confusion, as defined in Module 2. The determination of whether a contention sit exists and the configuration of configuration sets is performed after the Initial Evaluation, any Extended Evaluation, and Dispute Resolution involving third parties (see Module 3).
Module 4 identifies two types of contention: (1) direct contention, where two proposed gTLDs are identical or so similar as to create a probability of user confusion; and (2) indirect confusion, where two proposed gTLDs are each in direct contention with a third contention string, but not with each other. A contention set consists of all proposed gTLDs that are linked by string contention to one another, whether directly or indirectly. Thus, if there is string confusion between A and B, and B and C, but not between A and C, all three are included in the contention set.
The contention resolution procedure may be different depending on whether the proposed gTLDs are open or community-based (see Module 1). For community-based contentions, a comparative evaluation provider (to be appointed by ICANN) will determine whether one or more of the applications would "clearly and demonstrably" add more value to the domain name system. Section 4.2.2 sets up a scoring system to be used in comparative evaluation, which awards points based on: (1) the nexus between the proposed gTLD and the community in question; (2) the extent to which the applicant's registration policies limit registration in the gTLD to the community; (3) the community's size, organization, longevity, and ease of identification; and (4) the extent to which the relevant community has endorsed a particular applicant. Up to three points are available for each factor, and only applicants receiving scores of 11 or more points will be considered eligible. If only one applicant in a comparative evaluation receives a score of 11 or more, it is declared the winner and permitted to register the gTLD. If there are multiple applicants scoring 11 or more, the comparative evaluation panel will consider what portion of the community is represented by each application. If no applicant scores 11 or more, then a further unspecified contention resolution procedure will be used to determine the winner.
Module 4 does not outline a procedure for resolving string contentions among open names. Section 4.3 states ICANN's expectation that most string contentions will be decided by negotiated settlement, but leaves open the possibility of auctions to resolve string contentions.
Comments
Our thoughts concerning the standards for assessing string confusion and the timing of the string contention review in the application process are set forth above. In addition, we are concerned that the process for resolving string contention in open domain names is completely undeveloped. For contending community applications, there is at least a scoring system. At a minimum, some guidelines as to what factors (other than the financial wherewithal to win an auction) should be considered in resolving string contention issues should be outlined so that applicants have some idea of what they may be expected to prove.
Modules 5 and 6
Summary
Module 5 outlines the final steps for delegating the
proposed gTLD to the applicant, i.e. activating the domain name. Module 6 is a list of acknowledgments,
warranties, and indemnities that applicants must provide as part of their
applications. Among other things,
applicants must:
(1) warrant that statements and representations made in the application are true;
(2) indemnify ICANN from any damage resulting from ICANN's reliance on information provided by the applicant; and
(3) waive any legal challenges to any ICANN decisions. sets forth the application terms and conditions to which applicants must agree in order to have their applications reviewed.
Comments
We have no comments on Module 5.
We believe that Module 6 should include a statement from the applicant representing and warranting that it is not seeking to register a gTLD that infringes another party's rights, or for the purpose of trading on another's goodwill. It may be anticipated that such a representation will appear in the application form itself (which has not been created), and would therefore be swept in with the applicant's representation that the statements made in the application are true. However, this is an oversight that should be corrected somewhere
My thanks to my colleagues Sanjiv Sarwate, Alexis Payne, Jake Linford, Scott :Lonardo, Daniel Hwang, Colin O'Brien for help in preparing this.
