Page History

Module 4
String Contention Procedures
This module describes situations in which contention over applied-for gTLD strings occurs, and the methods available to applicants for resolving such contention cases.
4.1 String Contention
String contention occurs when either:

...

ICANN will not approve applications for proposed gTLD strings that are identical or that would result in user confusion, called contending strings. If either situation 1 or 2 above occurs, such applications will proceed to contention resolution through either community priority evaluation, in certain cases, or through an auction. Both processes are described in this module. A group of applications for contending strings is referred to as a contention set.
(In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.)
4.1.1Identification of Contention Sets
Contention sets are groups of applications containing identical or similar applied-for gTLD strings. Contention sets are identified during Initial Evaluation following review of all applied-for gTLD strings. ICANN will publish preliminary contention sets once the String Similarity review is completed, and will update the contention sets as necessary during the evaluation and dispute resolution stages.
Applications for identical gTLD strings will be automatically assigned to a contention set. For example, if Applicant A and Applicant B both apply for .TLDSTRING, they will be identified as being in a contention set. Such testing for identical strings also takes into consideration the code point variants listed in any relevant IDN table. That is, two or more applicants whose applied-for strings or designated variants are variant strings according to an IDN table submitted to ICANN would be considered in direct contention with one another. For example, if one applicant applies for string A and another applies for string B, and strings A and B are variant TLD strings as defined in Module 1, then the two applications are in direct contention.
The String Similarity Panel will also review the entire pool of applied-for strings to determine whether the strings proposed in any two or more applications are so similar that they would create a probability of user confusion if allowed to coexist in the DNS. The panel will make such a determination for each pair of applied-for gTLD strings. The outcome of the String Similarity review described in Module 2 is the identification of contention sets among applications that have direct or indirect contention relationships with one another.
Two strings are in direct contention if they are identical or similar to one another. More than two applicants might be represented in a direct contention situation: if four different applicants applied for the same gTLD string, they would all be in direct contention with one another.
Two strings are in indirect contention if they are both in direct contention with a third string, but not with one another. The example that follows explains direct and indirect contention in greater detail.
In Figure 4-1, Strings A and B are an example of direct contention. Strings C and G are an example of indirect contention. C and G both contend with B, but not with one another. The figure as a whole is one contention set. A contention set consists of all applications that are linked by string contention to one another, directly or indirectly.

Figure 4-1 – This diagram represents one contention set, featuring both directly and indirectly contending strings.
While preliminary contention sets are determined during Initial Evaluation, the final configuration of the contention sets can only be established once the evaluation and dispute resolution process stages have concluded. This is because any application excluded through those processes might modify a contention set identified earlier.
A contention set may be augmented, split into two sets, or eliminated altogether as a result of an Extended Evaluation or dispute resolution proceeding. The composition of a contention set may also be modified as some applications may be voluntarily withdrawn throughout the process.
Refer to Figure 4-2: In contention set 1, applications D and G are eliminated. Application A is the only remaining application, so there is no contention left to resolve.
In contention set 2, all applications successfully complete Extended Evaluation and Dispute Resolution, so the original contention set remains to be resolved.
In contention set 3, application F is eliminated. Since application F was in direct contention with E and J, but E and J are not in contention with one other, the original contention set splits into two sets: one containing E and K in direct contention, and one containing I and J.
Figure 4-2 – Resolution of string contention cannot begin until all applicants within a contention set havecompleted all applicable previous stages.
The remaining contention cases must then be resolved through community priority evaluation or by other means, depending on the circumstances. In the string contention resolution stage, ICANN addresses each contention set to achieve an unambiguous resolution.
As described elsewhere in this guidebook, cases of contention might be resolved by community priority evaluation or an agreement among the parties. Absent that, the last-resort contention resolution mechanism will be an auction.
4.1.2 Impact of String Confusion Dispute Resolution Proceedings on Contention Sets
If an applicant files a string confusion objection against another application (refer to Module 3), and the panel finds that user confusion is probable (that is, finds in favor of the objector), the two applications will be placed in direct contention with each other. Thus, the outcome of a dispute resolution proceeding based on a string confusion objection would be a new contention set structure for the relevant applications, augmenting the original contention set.
If an applicant files a string confusion objection against another application, and the panel finds that string confusion does not exist (that is, finds in favor of the responding applicant), the two applications will not be considered in direct contention with one another.
A dispute resolution outcome in the case of a string confusion objection filed by another applicant will not result in removal of an application from a previously established contention set.
4.1.3Self-Resolution of String Contention
Applicants that are identified as being in contention are encouraged to reach a settlement or agreement among themselves that resolves the contention. This may occur at any stage of the process, once ICANN publicly posts the applications received and the preliminary contention sets on its website.
Applicants may resolve string contention in a manner whereby one or more applicants withdraw their applications. An applicant may not resolve string contention by selecting a new string or by replacing itself with a joint venture. It is understood that applicants may seek to establish joint ventures in their efforts to resolve string contention. However, material changes in applications (for example, combinations of applicants to resolve contention) will require re-evaluation. This might require additional fees or evaluation in a subsequent application round. Applicants are encouraged to resolve contention by combining in a way that does not materially affect the remaining application. Accordingly, new joint ventures must take place in a manner that does not materially change the application, to avoid being subject to re-evaluation.
4.1.4 Possible Contention Resolution Outcomes
An application that has successfully completed all previous stages and is no longer part of a contention set due to changes in the composition of the contention set (as described in subsection 4.1.1) or self-resolution by applicants in the contention set (as described in subsection 4.1.3) may proceed to the next stage.
An application that prevails in a contention resolution procedure, either community priority evaluation or auction, may proceed to the next stage.
In some cases, an applicant who is not the outright winner of a string contention resolution process can still proceed. This situation is explained in the following paragraphs.
If the strings within a given contention set are all identical, the applications are in direct contention with each other and there can only be one winner that proceeds to the next step.
However, where there are both direct and indirect contention situations within a set, more than one string may survive the resolution.
For example, consider a case where string A is in contention with B, and B is in contention with C, but C is not in contention with A. If A wins the contention resolution procedure, B is eliminated but C can proceed since C is not in direct contention with the winner and both strings can coexist in the DNS without risk for confusion.
4.2Community Priority Evaluation
Community priority evaluation will only occur if a community-based applicant selects this option. Community priority evaluation can begin once all applications in the contention set have completed all previous stages of the process.
The community priority evaluation is an independent analysis. Scores received in the applicant reviews are not carried forward to the community priority evaluation. Each application participating in the community priority evaluation begins with a score of zero.
4.2.1Eligibility for Community Priority Evaluation
As described in subsection 1.2.3 of Module 1, all applicants are required to identify whether their application type is:

...

Applicants designating their applications as community-based are also asked to respond to a set of questions in the application form to provide relevant information if a community priority evaluation occurs.
Only community-based applicants are eligible to participate in a community priority evaluation.
At the start of the contention resolution stage, all community-based applicants within remaining contention sets will be notified of the opportunity to opt for a community priority evaluation via submission of a deposit by a specified date. Only those applications for which a deposit has been received by the deadline will be scored in the community priority evaluation. Following the evaluation, the deposit will be refunded to applicants that score 14 or higher.
Before the community priority evaluation begins, the applicants who have elected to participate may be asked to provide additional information relevant to the community priority evaluation.
4.2.2Community Priority Evaluation Procedure
Community priority evaluations for each eligible contention set will be performed by a community priority panel appointed by ICANN to review these applications. The panel's role is to determine whether any of the community-based applications fulfills the community priority criteria. Standard applicants within the contention set, if any, will not participate in the community priority evaluation.

...

If none of the community-based applications are found to meet the criteria, then all of the parties in the contention set (both standard and community-based applicants) will proceed to an auction.
Results of each community priority evaluation will be posted when completed.
Applicants who are eliminated as a result of a community priority evaluation are eligible for a partial refund of the gTLD evaluation fee (see Module 1).
4.2.3Community Priority Evaluation Criteria
The Community Priority Panel will review and score the one or more community-based applications having elected the community priority evaluation against four criteria as listed below.
The scoring process is conceived to identify qualified community-based applications, while preventing both "false positives" (awarding undue priority to an application that refers to a "community" construed merely to get a sought-after generic word as a gTLD string) and "false negatives" (not awarding priority to a qualified community application). This calls for a holistic approach, taking multiple criteria into account, as reflected in the process. The scoring will be performed by a panel and be based on information provided in the application plus other relevant information available (such as public information regarding the community represented). The panel may also perform independent research, if deemed necessary to reach informed scoring decisions.
It should be noted that a qualified community application eliminates all directly contending standard applications, regardless of how well qualified the latter may be. This is a fundamental reason for very stringent requirements for qualification of a community-based application, as embodied in the criteria below.
The sequence of the criteria reflects the order in which they will be assessed by the panel. The utmost care has been taken to avoid any "double-counting" - any negative aspect found in assessing an application for one criterion should only be counted there and should not affect the assessment for other criteria.
An application must score at least 14 points to prevail in a community priority evaluation. The outcome will be determined according to the procedure described in subsection 4.2.2.
Criterion #1: Community Establishment (0-4 points)
A maximum of 4 points is possible on the Community Establishment criterion:

...

Criterion 4 Guidelines
With respect to "Support," it follows that documented support from, for example, the only national association relevant to a particular community on a national level would score a 2 if the string is clearly oriented to that national level, but only a 1 if the string implicitly addresses similar communities in other nations.
Also with respect to "Support," the plurals in brackets for a score of 2, relate to cases of multiple institutions/organizations. In such cases there must be documented support from institutions/organizations representing a majority of the overall community addressed in order to score 2.
The applicant will score a 1 for "Support" if it does not have support from the majority of the recognized community institutions/member organizations, or does not provide full documentation that it has authority to represent the community with its application. A 0 will be scored on "Support" if the applicant fails to provide documentation showing support from recognized community institutions/community member organizations, or does not provide documentation showing that it has the authority to represent the community. It should be noted, however, that documented support from groups or communities that may be seen as implicitly addressed but have completely different orientations compared to the applicant community will not be required for a score of 2 regarding support.
When scoring "Opposition," previous objections to the application as well as public comments during the same application round will be taken into account and assessed in this context. There will be no presumption that such objections or comments would prevent a score of 2 or lead to any particular score for "Opposition." To be taken into account as relevant opposition, such objections or comments must be of a reasoned nature. Sources of opposition that are clearly spurious, unsubstantiated, or filed for the purpose of obstruction will not be considered relevant.
4.3Auction: Mechanism of Last Resort
It is expected that most cases of contention will be resolved by the community priority evaluation, or through voluntary agreement among the involved applicants. Auction is a tie-breaker method for resolving string contention among the applications within a contention set, if the contention has not been resolved by other means.
An auction will not take place to resolve contention in the case where the contending applications are for geographic names (as defined in Module 2). In this case, the applications will be suspended pending resolution by the applicants.
An auction will take place, where contention has not already been resolved, in the case where an application for a geographic name is in a contention set with applications for similar strings that have not been identified as geographic names.
In practice, ICANN expects that most contention cases will be resolved through other means before reaching the auction stage. There is a possibility that significant funding will accrue to ICANN as a result of one or more auctions. The purpose of an auction is to resolve contention in a clear, objective manner. Proceeds from auctions will be reserved and earmarked until the uses of the proceeds are determined. It is planned that costs of the new gTLD program will offset by fees, so any funds coming from a last resort contention resolution mechanism such as auctions would result (after paying for the auction process) in additional funding. Therefore, consideration of a last resort contention mechanism should include the uses of funds. Funds must be earmarked separately and used in a manner that supports directly ICANN's Mission and Core Values and also maintains its not for profit status.
Possible uses include formation of a foundation with a clear mission and a transparent way to allocate funds to projects that are of interest to the greater Internet community, such as grants to support new gTLD applications or registry operators from communities in subsequent gTLD rounds, the creation of an ICANN-administered/community-based fund for specific projects for the benefit of the Internet community, the creation of a registry continuity fund for the protection of registrants (ensuring that funds would be in place to support the operation of a gTLD registry until a successor could be found), or establishment of a security fund to expand use of secure protocols, conduct research, and support standards development organizations in accordance with ICANN's security and stability mission.
Further detail on the potential uses of funds will be provided with updated Applicant Guidebook materials.
4.3.1 Auction Procedures
An auction of two or more applications within a contention set is conducted as follows. The auctioneer successively increases the prices associated with applications within the contention set, and the respective applicants indicate their willingness to pay these prices. As the prices rise, applicants will successively choose to exit from the auction. When a sufficient number of applications have been eliminated so that no direct contentions remain (i.e., the remaining applications are no longer in contention with one another and all the relevant strings can be delegated as TLDs), the auction will be deemed to conclude. At the auction's conclusion, the applicants with remaining applications will pay the resulting prices and proceed toward delegation. This procedure is referred to as an "ascending-clock auction."
This section provides applicants an informal introduction to the practicalities of participation in an ascending-clock auction. It is intended only as a general introduction and is only preliminary. The detailed set of Auction Rules will be available prior to the commencement of any auction proceedings. If any conflict arises between this module and the auction rules, the auction rules will prevail.
For simplicity, this section will describe the situation where a contention set consists of two or more applications for identical strings.
All auctions will be conducted over the Internet, with participants placing their bids remotely using a web-based software system designed especially for auction. The auction software system will be compatible with current versions of most prevalent browsers, and will not require the local installation of any additional software.
Auction participants ("bidders") will receive instructions for access to the online auction site. Access to the site will be password-protected and bids will be encrypted through SSL. If a bidder temporarily loses connection to the Internet, that bidder may be permitted to submit its bids in a given auction round by fax, according to procedures described in the auction rules. The auctions will generally be conducted to conclude quickly, ideally in a single day.
The auction will be carried out in a series of auction rounds, as illustrated in Figure 4-3. The sequence of events is as follows:
1.For each auction round, the auctioneer will announce in advance: (1) the start-of-round price, (2) the end-of-round price, and (3) the starting and ending times of the auction round. In the first auction round, the start-of-round price for all bidders in the auction will be USD 0. In later auction rounds, the start-of-round price will be its end-of-round price from the previous auction round.
Figure 4-3 – Sequence of events during an ascending-clock auction.
2. During each auction round, bidders will be required to submit a bid or bids representing their willingness to pay within the range of intermediate prices between the start-of-round and end-of-round prices. In this way a bidder indicates its willingness to stay in the auction at all prices through and including the end-of-auction round price, or its wish to exit the auction at a price less than the end-of-auction round price, called the exit bid.

...

To the extent possible, auctions to resolve multiple string contention situations will be conducted simultaneously.
4.3.1.1Currency
For bids to be comparable, all bids in the auction will be submitted in any integer (whole) number of US dollars.
4.3.1.2Fees
A bidding deposit will be required of applicants participating in the auction, in an amount to be determined. The bidding deposit must be transmitted by wire transfer to a specified bank account specified by ICANN or its auction provider at a major international bank, to be received in advance of the auction date. The amount of the deposit will determine a bidding limit for each bidder: the bidding deposit will equal 10% of the bidding limit; and the bidder will not be permitted to submit any bid in excess of its bidding limit.
In order to avoid the need for bidders to pre-commit to a particular bidding limit, bidders may be given the option of making a specified deposit that will provide them with unlimited bidding authority for a given application. The amount of the deposit required for unlimited bidding authority will depend on the particular contention set and will be based on an assessment of the possible final prices within the auction.
All deposits from nondefaulting losing bidders will be returned following the close of the auction.
4.3.2Winning Bid Payments
Any applicant that participates in an auction will be required to sign a bidder agreement that acknowledges its rights and responsibilities in the auction, including that its bids are legally binding commitments to pay the amount bid if it wins (i.e., if its application is approved), and to enter into the prescribed registry agreement with ICANN—together with a specified penalty for defaulting on payment of its winning bid or failing to enter into the required registry agreement.
The winning bidder in any auction will be required to pay the full amount of the final price within 20 business days of the end of the auction. Payment is to be made by wire transfer to the same international bank account as the bidding deposit, and the applicant's bidding deposit will be credited toward the final price.
In the event that a bidder anticipates that it would require a longer payment period than 20 business days due to verifiable government-imposed currency restrictions, the bidder may advise ICANN well in advance of the auction and ICANN will consider applying a longer payment period to all bidders within the same contention set.
Any winning bidder for whom the full amount of the final price is not received within 20 business days of the end of an auction is subject to being declared in default. At their sole discretion, ICANN and its auction provider may delay the declaration of default for a brief period, but only if they are convinced that receipt of full payment is imminent.
Any winning bidder for whom the full amount of the final price is received within 20 business days of the end of an auction retains the obligation to execute the required registry agreement within 90 days of the end of auction. Such winning bidder who does not execute the agreement within 90 days of the end of the auction is subject to being declared in default. At their sole discretion, ICANN and its auction provider may delay the declaration of default for a brief period, but only if they are convinced that execution of the registry agreement is imminent.
4.3.3Post-Default Procedures
Once declared in default, any winning bidder is subject to immediate forfeiture of its position in the auction and assessment of default penalties. After a winning bidder is declared in default, the remaining bidders will receive an offer to have their applications accepted, one at a time, in descending order of their exit bids. In this way, the next bidder would be declared the winner subject to payment of its last bid price. The same default procedures and penalties are in place for any runner-up bidder receiving such an offer.
Each bidder that is offered the relevant gTLD will be given a specified period—typically, four business days—to respond as to whether it wants the gTLD. A bidder who responds in the affirmative will have 20 business days to submit its full payment. A bidder who declines such an offer cannot revert on that statement, has no further obligations in this context and will not be considered in default.
The penalty for defaulting on a winning bid will equal 10% of the defaulting bid. If bidders were given the option of making a specified deposit that provided them with unlimited bidding authority for a given application and if the winning bidder utilized this option, then the penalty for defaulting on a winning bid will be the lesser of the following: (1) 10% of the defaulting bid, or (2) the specified deposit amount that provided the bidder with unlimited bidding authority.
Default penalties will be charged against any defaulting applicant's bidding deposit before the associated bidding deposit is returned.
4.4 Contention Resolution and Contract Execution
An applicant that has been declared the winner of a contention resolution process will proceed by entering into the contract execution step. (Refer to section 5.1 of Module 5.)
If a winner of the contention resolution procedure has not executed a contract within 90 days of the decision, ICANN has the right to deny that application and extend an offer to the runner-up applicant, if any, to proceed with its application. For example, in an auction, another applicant who would be considered the runner-up applicant might proceed toward delegation. This offer is at ICANN's option only. The runner-up applicant in a contention resolution process has no automatic right to an applied-for gTLD string if the first place winner does not execute a contract within a specified time.