Module 5 Contention Set Resolution

String contention occurs when one or more applied-for strings are identical or a variant to another string applied for by a different applicant, or are found to be similar visually, aurally, or in meaning.¹ These contending strings form a contention set.

This module describes contention, how and when it occurs, and the methods available to avoid or resolve it.

Figure 5-1: Contention Set Resolution Process

Contention sets composed of identical applied-for primary strings and/or their variant strings will be identified and published by ICANN on Reveal Day. These contention sets may be further identified or modified depending on the outcome of the applicable processes and evaluations described in Section 5.2.4 Contention Set Formation. ICANN will publish updated lists of contention sets at defined points in the application process (see Section 5.2 String Contention and Contention Resolution Procedures).

An application that has successfully completed all previous stages and is no longer in contention due to changes in the composition of the contention set may proceed to the next stage of the evaluation process.

A contention set is finalized once changes are no longer possible to its composition, other than when an applicant withdraws its application. The contention set will then proceed to contention resolution procedures, as described in Section 5.2.2 String Contention Resolution.

5.1 Replacement Strings

To potentially reduce the instances of contention, applicants are encouraged to designate a replacement string alongside their original choice of string. Applicants may designate only one replacement string per application. Using a replacement string is not considered a string change. String changes, which would occur after String Confirmation Day, are only available to .Brand TLD applicants, subject to the details in Section 5.3 .Brand String Change Request.

Designating a replacement string may provide applicants with the option to avoid contention before the list of applied-for strings is finalized (see Section 5.1.5 Replacement Period). An applicant can avoid contention in such cases by replacing its original applied-for string with its designated replacement string, subject to the conditions and criteria detailed in this section.

Applicants choosing to replace an applied-for string does not preclude the replacement string from being placed in contention at a later stage of the application process as a result of Singular/Plural Notification, String Similarity Evaluation, or String Confusion Objection. For example, if an applicant applies for .SNEEZE and elects to use its replacement string .AHCHOO, the applicant could later find itself in contention following a String Similarity Evaluation if another applied-for string, .ACHOO, is deemed Visually Similar. In such a case the applicant could not switch back to .SNEEZE and must remain in contention with .AHCHOO.

Following the publication of the list of applications on Reveal Day,² an applicant will be given 14 days (known as the Replacement Period) to review the published application information and notify ICANN if it elects to replace its original string with its replacement string in the application system, subject to certain conditions defined below.

Applications in which the original string is replaced will then proceed through the remaining application process stages using the replacement string. An applicant that opts for its replacement string will be unable to revert to its original applied-for string. An applicant that does not indicate its intention to use its replacement string during the Replacement Period forfeits this option and will proceed with its original applied-for string.

Applicants should be aware of the following:

• Due to the risk of creating new or adding to existing instances of contention, an applicant will not be allowed to use its replacement string if it is identical to the original applied-for string or replacement string of another applicant. This means that if an applicant’s replacement string matches that of one or more other applicants, it will not be able to opt for its replacement string under any circumstance, even if those other applicants decide not to use them.

• Additionally, if an applicant designates a replacement string that is identical to another applicant’s applied-for string, the applicant will also be unable to use it, regardless of whether the other applicant decides to switch to its replacement string.

5.1.2 Replacement String Eligibility

Any applicant, regardless of its applied-for string type (see Section 3.1.6 Application and String Types), can designate a replacement string as part of its application.³

While designating a replacement string is not compulsory, an applicant will be unable to retroactively designate a replacement string after submitting its application.

Applicants should also be aware that once an applied-for string is replaced, it cannot be reinstated, even if it would otherwise remain undelegated in that application round. Applicants should therefore be willing to operate a gTLD on the basis of the string that is finalized by ICANN at the end of the Replacement Period, whether it is their original applied-for or replacement string.

5.1.3 Designating a Replacement String

Applicants will have the option to designate a replacement string, including any applicable variant strings, when completing an application in the application system. The eligibility rules for replacement strings are the same as those that apply to all applied-for strings.

An applicant may have to supply additional information for its designated replacement string when completing the application, including answers to any string-specific application questions. This ensures alignment with its chosen replacement string and business model.

5.1.4 Additional Considerations for Designating a Replacement String

An applicant should be mindful when designating its replacement string, as the applicant will be prohibited from using a replacement string that is identical to another designated replacement string or original applied-for string. The purpose of designating a replacement string is to provide applicants with the opportunity to avoid contention and the associated resolution procedures; therefore, it should be chosen with this goal in mind.

Specifically, an applied-for string may enter contention if ICANN confirms, following a notification, that two strings are the singular or plural forms of the same word in the same language and are used in another application within the same application round (see Section 5.2.4.3 Contention Due to Singular/Plural Notification). To minimize this risk, applicants should choose a replacement string that is not simply the plural or singular version of the original applied-for string.

For example, if an applicant’s original applied-for string is .EXAMPLE, designating .EXAMPLES as a replacement string may entail a risk of it being identified as a plural and placed in contention.

Failure to give careful consideration to the choice of replacement string may increase the risk of a string ending up in contention at a later stage of the application process.

5.1.5 Replacement Period

After the application submission window has closed, ICANN will perform an administrative check on all submitted applications. After this process has been completed, ICANN will publish non-confidential details of all applications for new gTLD strings on Reveal Day, including but not limited to:

• The list of applied-for strings

• The identity of the applicants

• The list of designated replacement strings

• A list of contention sets containing applications for identical strings

An applicant that designated a replacement string that is not identical to another applied-for or replacement string will have 14 days to review the published application information and notify ICANN if it elects to replace the original applied-for string with its replacement string. An applicant can do this by accessing its application on the application system and selecting the appropriate option. If an applicant does not take this action, its replacement string will not be utilized. The applicant will then continue through the remaining stages of the application process based on the original applied-for string.

If all applicants for a given string opt for their respective replacement strings, there may be no remaining active application for the original applied-for string.

For example, if Applicants A and B both apply for .EXAMPLE and decide to use their replacement strings to avoid contention, and no other applicant has applied for .EXAMPLE, there will be no remaining active application for .EXAMPLE.

The Replacement Period is subject to the general prohibition on private resolution and applicant collusion discussed in Section 5.2.3 Prohibition of the Private Resolution of String Contention by Applicants. Applicants may not discuss, directly or indirectly, their decisions regarding their replacement strings with each other, or propose or entertain proposals for any sort of compensation, financial or otherwise, to any applicant or related party in exchange for opting or not opting to switch to a replacement string.

5.1.6 String Confirmation Day

Once the Replacement Period has ended, ICANN will publish the finalized list of applied-for strings on String Confirmation Day (subject to any accepted .Brand String Change Requests). As no further string replacement is possible, any remaining instances of contention will be resolved using one or more of the alternative procedures described in Section 5.2.2 String Contention Resolution.

5.2 String Contention and Contention Resolution Procedures

Contention occurs when one or more applied-for strings are:

• Identical to another applied-for string

• A variant of another applied-for string

• Notified as a singular or plural form in the same language

• Found to be similar visually, aurally or in meaning to another applied-for string

Contention may be identified during various stages of the application process from Reveal Day through the conclusion of the string evaluation and potential subsequent challenges, objections, appeals, and Singular/Plural Notifications processes.

Lists of new and updated contention sets will be published at the following points in the application process:

• Reveal Day

• String Confirmation Day

• Following the publication of Singular/Plural Notification results

• Following the publication of String Similarity Evaluation results

• Following the resolution of Objection/Appeal proceedings, as applicable

• Following a successful .Brand String Change Request, as applicable

5.2.1 Contention Types

5.2.1.1 Direct Contention

Two strings are in direct contention if they are identical to, a variant of, or similar visually, aurally, or in meaning to one another.

A direct contention situation can involve more than two applicants. For example, if four different applicants applied for the same gTLD string, they would all be in direct contention with one another, meaning only one can proceed to the applicant and application evaluation phases and potential contracting.

5.2.1.2 Indirect Contention

Two strings are in indirect contention if they are both in direct contention with at least one other string, but not with each other. It is also possible for multiple contention sets to overlap and be in contention with one another indirectly.

Figure 5-2: Direct and Indirect Contention Set Overview

Figure 5-2 provides a simple example of direct and indirect contention. In Figure 5-2, Strings A and B are in direct contention and Strings B and C are in direct contention, whereas Strings C and A are in indirect contention. That is, strings C and A both contend with String B, but not with one another. In the same figure, while Strings B and C are in direct contention, String C is also in contention with String D. Strings A and D are therefore also in indirect contention as are Strings B and D.

In some cases, an applicant that is in indirect contention and that is not the outright winner of a contention resolution process may still continue to the Application and Applicant Evaluation phase. This means that more than one application in the contention set could potentially proceed towards contracting.

For example, in the scenario pictured in Figure 5-2, if String B wins the contention resolution process, Strings A and C are eliminated but String D can proceed, as String D is not in direct contention with the winner and both strings can coexist in the DNS without risk of user confusion. These results are depicted in Figure 5-3.

Figure 5-3: Example of Indirect Contention Set Resolution

5.2.2 String Contention Resolution

Determining which applications in a contention set will proceed to the Application and Applicant Evaluation phase and potential contracting for the contested string is known as contention resolution.

Contention sets can be formed, changed, and resolved during the application process as a result of the processes described in Section 5.2.4 Contention Set Formation. For qualifying .Brand TLD applicants only, the option to submit a .Brand String Change to avoid contention (and therefore avoid resolution procedures) is also available (see Section 5.3 .Brand String Change Request).

Once contention sets are finalized, ICANN will administer two methods of contention resolution:

• Community Priority Evaluation (CPE)⁴

• An ICANN New gTLD Auction

Applicants prevailing in a contention resolution procedure, after completing applicable Application and Applicant Evaluations (see Module 6 Applicant Evaluation and Module 7 Application Evaluation), will proceed toward contracting of the applied-for gTLD. Alternative procedures apply to strings designated as high risk for Name Collision.⁵ The time required for contention resolution will vary because some contention sets may be resolved by more than one process. For example, in the case of two applicants for the same string prevailing in CPE, an auction between these applicants may be necessary to resolve contention. The outcomes of CPE and auction processes will be published on the New gTLD Program website.

5.2.3 Prohibition of the Private Resolution of String Contention by Applicants

The New gTLD Program processes leading up to and including, where applicable, a New gTLD Auction (including any CPE that may occur prior to, and which could eliminate the need for, a New gTLD Auction) provide the only permissible path to contention resolution. Any other resolution methods, such as private auctions or joint ventures, or any other arrangement designed to resolve contention privately, are strictly prohibited. The contention resolution processes and restrictions are also in support of the bona fide (good faith) requirement (see Section 1.1.5 Good Faith Intent) to operate an applied-for gTLD and support the Program’s goals of fostering diversity, encouraging competition, and enhancing the utility of the DNS.

5.2.3.1 Prohibited Communications and Activities

To prevent applicants from using methods not permitted in the Applicant Guidebook to resolve contention, the New gTLD Program includes rules prohibiting certain communications and activities as outlined in this section. ICANN intends that these rules setting forth prohibitions on certain communications and activities be interpreted broadly to cover all forms of impermissible conduct.

The New gTLD Program includes various points in time when contention sets are identified and updated as new information is available, namely: Reveal Day, String Confirmation Day, publication of Singular/Plural Notification results, publication of String Similarity Evaluation results, and resolution of Objection proceedings. See Section 5.2 String Contention and Contention Resolution Procedures for more information.

Applicants (including their agents and affiliates) for strings in the same contention set are strictly prohibited from communicating, either directly or indirectly, with other applicants in that same contention set regarding their respective applications in contention, any strategies related to the in-contention string(s), or strategies to resolve contention.

Communications are prohibited from Reveal Day until the earlier of (1) the date a prevailing applicant signs a Registry Agreement for a specific contending gTLD string, or (2) the applicant withdraws the relevant application. ​​The prohibition on “communicating directly or indirectly” includes public disclosures as well as private communications.

Examples of prohibited communications and conduct by applicants include, but are not limited to:

1. Discussing, offering, or accepting of money or other things of value (such as monetary gain or operational control provisions) for withdrawing an application.

2. Discussing or negotiating settlement agreements or post-auction transfer arrangements in any manner with another applicant in contention for the same string with respect to any contending strings.

The Applicant Guidebook restricts methods for resolving contention. However, applicants may communicate in the specific cases listed below. In such cases, they must take all commercially reasonable steps to prevent third parties from becoming intermediaries that could disclose information about their application or application portfolio to other applicants. These specific cases are as follows:

• Communications to third-party professional advisors, including counsel, consultants, financial advisors, or lenders.

• Communications during the course of obtaining consent or non-objection from a governmental authority for an application of a geographic name as described in Section 7.5 Geographic Names.

• Communications during the course of engaging with a governmental authority as a result of an application receiving a GAC Member Early Warning or GAC Consensus Advice.

ICANN recognizes that applicants may also be existing participants in the DNS ecosystem, such as existing gTLD registries, back-end registry service providers, or registrars.

Applicants may enter into various business arrangements with one another or affiliated entities that are not directly related to contending strings in the New gTLD Program. These arrangements can include, but are not limited to, registry-registrar agreements, registry service provider agreements, as well as data escrow agreements.

Routine business communications do not violate the rule prohibiting private resolution of contention sets if they do not convey information related to applications or application strategies. These communication rules are designed to minimally disrupt routine business practices in the DNS ecosystem.

5.2.3.2 Exceptions

The New gTLD Program does not prohibit applicants from communicating directly or indirectly any information related to applications or application strategies:

• For strings that are not in contention.

• Occurring outside of the defined periods where communication is prohibited.

The New gTLD Program specifically permits applicants for strings in contention to communicate with one another during established periods as part of mediation or settlement discussions to resolve an Objection, provided that no settlement shall discuss or include as part of its terms exchange of money or other things of value, including any post-auction transfer arrangements for strings that were formerly in contention.

In the event that an applicant believes that a particular disclosure required by law or regulation will result in a potential violation of these rules, applicants are encouraged to consult with ICANN before making the disclosure.

5.2.3.3 Violation of the Rules Prohibiting Private Resolution of Contention Strings

Prior to signing a Registry Agreement or withdrawing an application, all applicants must certify compliance with the Guidebook, including these rules prohibiting private resolution of contention. An applicant is required to disclose to ICANN any potential violation on its part of these rules, and such disclosure must be promptly made after the applicant becomes aware of the violation. Also, applicants will be required to cooperate with any ICANN inquiry or investigation concerning a possible breach of these rules.

ICANN expressly reserves the right to take appropriate action against applicants for violation of the rules prohibiting private resolution of contention strings. Actions taken by ICANN in response to an applicant’s violation of these rules could include:

• Disqualification from current and future New gTLD Program rounds

• Forfeiture of all evaluation and conditional evaluation fees

• Denial of refunds identified in the Guidebook

• Financial penalties for interfering with auction outcomes

• Legal action

ICANN may also report violations to the relevant authorities and address false claims of rule breaches.

5.2.4 Contention Set Formation

Contention sets can be formed under certain conditions during the application process as a result of the following:

• Applications for identical gTLD strings

• The outcome of the String Similarity Evaluation

• A successful Singular/Plural Notification

• A successful String Confusion Objection

An application can only be deemed not to be in contention once the string evaluation, dispute resolution, and appeal processes have concluded, and the outcomes of any .Brand String Change Requests are known, as described in Section 5.3 .Brand String Change Request. This is because any application that is altered or unable to proceed as a result of these processes might modify a previously identified contention set.

5.2.4.1 Contention as a Result of Applications for Identical gTLD Strings

On Reveal Day, all applications for identical strings or identical variants will be placed in contention with each other, forming a contention set. For example, if Applicant A and Applicant B both apply for .NEWGTLDSTRING, their strings would be contending strings, with only one application allowed to proceed to the Application and Applicant Evaluation phase and potential contracting.

Additionally, two or more applications with applied-for strings or variant strings identified by ICANN as variant strings of one another, as defined in Section 5.2.1 Contention Types, would also be considered in direct contention and placed in a contention set. For instance, if one applicant applies for String A and another applies for String B, and Strings A and B are variant TLD strings of one another (such as an IDN gTLD in simplified Han Chinese script and its variant IDN gTLD in traditional Han Chinese script, as specified in the Root Zone Label Generation Rules) then the two applications will be in contention.

Contention sets will begin to be published once the String Similarity Evaluation has been completed. Applicants should check the New gTLD website for details on contention sets.⁶

5.2.4.2 Contention as an Outcome of the String Similarity Evaluation

The String Similarity Evaluation Panel will review the entire set of applied-for strings and their applied-for variant strings to determine whether the strings proposed in any two or more applications are so Visually 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 the entire set of applied-for strings and their applied-for variant strings. One of the outcomes of the String Similarity Evaluation will be to place applications into a contention set once the panel has identified contention relationships, based on the confusability of the applied-for strings (see Section 7.10 String Similarity Evaluation).

5.2.4.3 Contention Due to Singular/Plural Notification

If ICANN confirms, following a notification, that an applied-for gTLD string represents a word that is either the singular or plural version of another applied-for gTLD string in the same language, both strings will be put in contention to prevent end-user confusion (see Section 4.4 Singular/Plural Notifications).

5.2.4.4 Contention Arising From a Successful String Confusion Objection

If an applicant files a String Confusion Objection⁷ against another application⁸ and the panel finds in favor of the objector, determining that user confusion is probable, both applications will be placed in direct contention and referred to a contention resolution procedure.

5.3 .Brand String Change Requests

If an application for a .Brand TLD is found in contention, the applicant will have the option to change the applied-for string to try to avoid further contention by submitting a .Brand String Change Request, subject to the requirements set out in this section.

5.3.1 Submitting a .Brand String Change Request

A .Brand String Change Request can only be submitted by an applicant for a .Brand TLD that is in contention with another application. If ICANN has not done so already, it will evaluate an application's eligibility for .Brand TLD designation upon receiving a .Brand String Change Request.⁹ ICANN will not consider a .Brand String Change Request before the associated application has been successfully evaluated as qualifying for .Brand designation based on the applied-for string.¹⁰ A .Brand String Change Request for an application that is found ineligible for the .Brand TLD designation will be rejected. See Section 7.3 .Brand TLD Eligibility Evaluation.

A .Brand String Change can only be submitted up to 30 days following:

• The formation of contention sets after String Similarity Evaluation; or

• The publication of a String Confusion Objection Panel Determination; or

• Appellate Panel Determination involving the application subject to the .Brand String Change Request.

If an applicant does not submit a .Brand String Change Request within the applicable 30-day period, the relevant application will proceed on the basis of the original applied-for .Brand string.

5.3.2 .Brand String Change Request Requirements

A .Brand String Change Request must satisfy the following requirements to be accepted by ICANN:

1. The proposed change must add one or more words to the applied-for string, subject to the following conditions:

   • The additional word or words must be added to the original string.

   • The additional word or words must appear in the description of goods and services of the applicant’s Trademark Registration or equivalent document in the applicant’s jurisdiction, submitted by the applicant in support of its application for a .Brand TLD.¹¹ Another Trademark Registration or equivalent document in the applicant’s possession (or that of any of its Affiliates) may also be submitted in support of the .Brand String Change Request, if accompanied by legal confirmation that the submitted trademark is owned by the entity with the application and respective brand. ICANN reserves the right to verify any additional documentation submitted for this purpose. Additionally, should .Brand TLD Eligibility Evaluation (see Section 7.3 .Brand TLD Eligibility Evaluation) or re-evaluation¹² be required, any associated costs¹³ will be borne by the applicant.

   • No translations of words contained in the Trademark Registration will be accepted.

2. The new string with the added word or words must not create or expand a contention set.

If the new .Brand TLD qualifies for .Brand TLD designation and meets the requirements above, the .Brand String Change Request will be accepted for further processing as described in Sections 5.3.3 and 5.3.4 and will be posted publicly.

5.3.3 .Brand String Change Requests and Input from the Community

A .Brand String Change Request will be subject to the community input and objection processes, as described in Module 4 Community Input, Objections, and Appeals.

The potential outcomes for the new .Brand TLD mirror those described in Module 4, with the exception of a new .Brand TLD that does not prevail in a String Confusion Objection or is subject to a confirmed Singular/Plural issue. In such cases, ICANN will revert the applicant to its original applied-for .Brand TLD, and the applicant will proceed to contention resolution, as described in Section 5.1 Replacement Strings.

5.3.4 .Brand String Change Requests and String Evaluation

A .Brand String Change Request will be subject to String Evaluation, as described in Module 7 String and Application Evaluation Procedures. The potential outcomes for the new .Brand TLD mirror those described in Module 7, with the exception of a new .Brand TLD that is found to be Visually Similar as per the procedures described in Section 7.10 String Similarity Evaluation. This is because the new string with the added word or words must not create or expand a contention set. In such a case, ICANN will revert the applicant to its original applied-for .Brand TLD, and the applicant will proceed to contention resolution, as described in Section 5.1 Replacement Strings.

5.3.5 Impact on .Brand TLD Variants

Variants of applied-for .Brand TLDs must satisfy the same eligibility requirements as the primary applied-for .Brand TLD. The same requirements apply to any allocatable variants of the new .Brand TLD. The applicant must use the RZ-LGR to identify a new set of allocatable variant strings based on its new .Brand TLD string.

5.4 Community Priority Evaluation

Community Priority Evaluation (CPE) is a method to resolve contention and is an option only available to Community Applications (see Section 7.1.2.1 Applications for Community gTLDs), a specialized application¹⁴ type. It will only occur if a Community Application is in contention and the applicant elects to pursue CPE. The evaluation is an analysis conducted by independent experts. Applications that successfully complete CPE will automatically prevail in contention, unless more than one application in a contention set passes the evaluation. In such cases, Community Applications successful in CPE will proceed to an ICANN New gTLD Auction.¹⁵

In the 2007 GNSO Final Report on the Introduction of New Generic Top-Level Domains, Implementation Guidance F states that “[i]f there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe[;] ii) if there is no mutual agreement, a claim to support a community by one party will be a reason to award priority to that application.”¹⁶ In the Final Report on the new gTLD Subsequent Procedures Policy Development Process (SubPro PDP Final Report), the SubPro PDP Working Group affirmed “the continued prioritization of applications in contention sets that have passed Community Priority Evaluation (CPE).”¹⁷

CPE is an independent analysis conducted by a third-party expert panel. The panel’s role is to determine whether a Community Application fulfills the CPE criteria and should receive priority in the contention set. The scoring process looks at a set of criteria related to community establishment, the nexus between the community and applied-for string, registration policies, and community support. It is designed to identify qualified Community Applications while preventing false positives (awarding priority to unqualified applications for a coveted generic string) and false negatives (overlooking qualified Community Applications).

5.4.1 Eligibility for Community Priority Evaluation

As described in subsection Section 3.1.6 Application and String Types, an applicant will have the opportunity to designate its application as a Community Application¹⁸ at its sole discretion. An applicant designating its application as a Community Application¹⁹ is required to respond to a set of questions in the application form to provide relevant information about the community (see Appendix 1 Application Questions). The information provided by the applicant in response to the application questions will be used in CPE (and evaluated against the criteria described in Section 5.4.8 CPE Criteria).

In general, an applicant for a Community gTLD is expected to:

• Demonstrate a relationship with an organized community, as well as show how that identified community (see Section 5.4.2 Definition of Community and Identified Community) engages with its members; awareness of the identified community between members; the established presence and external awareness of the identified community, and show that the identified community has longevity.

• Have applied for a gTLD string strongly and specifically related to the identified community.

• Have proposed dedicated registration policies for registrants in its proposed gTLD, commensurate with the purpose of the identified community.

• Have its application endorsed in writing by one or more established institutions representing the identified community.

CPE will only occur if a Community Application is in contention (see Section 5.2 String Contention and Contention Resolution Procedures) and the Community Applicant opts to participate.²⁰ Applicants submitting Community Applications will be given the opportunity to opt into CPE once all applications in a contention set meet the following eligibility criteria:

• Completed string evaluation and all related processes (see Module 7 String and Application Evaluation Procedures)

• All applicable objections and appeals are resolved (see Section 4.5 Objections and Appeals)

• All evaluation challenges, if applicable, are completed²¹

• Have no open, relevant application change requests (see Section 3.8 Application Change Requests)

• Have no pending accountability mechanisms (see Section 2.7 Accountability Mechanisms)

5.4.2 Definition of Community and Identified Community

ICANN notes that the term “community” has evolved considerably from its Latin origin (“communitas” meaning “fellowship”), now emphasizing cohesion over mere commonality of interest. Although the SubPro PDP Final Report does not define community for purposes of CPE, it does note, in the context of community objections, that “a community should be interpreted broadly and will include, for example, an economic sector, a cultural community, or a linguistic community.”²²

As there is no singular definition of community provided by the SubPro PDP Final Report nor a defined list of “eligible communities,” the CPE criteria employ measures that balance objectivity with flexibility, ensuring the criteria can accommodate the broad spectrum of ways that a community might be structured, managed, and viewed or supported by its members and outsiders.

The term “identified community,” used throughout this section, refers to the community that an applicant, in its Community Application, claims to represent or on whose behalf it claims to be applying for a Community gTLD.

Any applicant can claim a relationship to a community in its application and designate it as a Community Application, committing to operate the gTLD according to a set of Registry Agreement Community Registration Policies (Community Registration Policies) that will be enshrined in the respective Registry Agreement. However, in cases where a Community Application is in contention with other applications (whether community or another type), a third-party panel is used to verify the community claim by the applicant.²³

Accordingly, the panel will verify, based on evidence from the applicant²⁴ as well as the panel’s own evaluation,²⁵ whether an applicant’s claim on a community meets the CPE criteria defined in this Guidebook and whether the application is eligible to receive priority in a contention set based on its score.²⁶

5.4.3 Conditional Fees for Community Priority Evaluation

Once the conditions in Section 5.4.1 Eligibility for Community Priority Evaluation are met, any applicant with a Community Application within a contention set will be notified of the opportunity to participate in CPE and will be requested to submit the required fees within 30 days of notification transmission (see Section 3.3 Fees and Payments). If the fees are not received within 30 days, the applicant will forfeit the opportunity to participate in CPE and will proceed to contention set resolution (see Section 5.2 String Contention and Contention Resolution).

Applications will be given priority numbers, which will be used to determine the general order of the release of evaluation results (as described in Order of Application Processing and Prioritization Draw). However, processing for CPE will largely be dictated by when an application and contention set become eligible, as noted above. Timing for CPE is also dependent upon Registry Commitment Evaluation (see Section 5.4.5 Community Registration Policies and Registry Commitment Evaluation).

5.4.4 Application Questions Related to Community Priority Evaluation

Applicants who designate their application as a Community Application will be asked to answer a series of questions specific to Community Applications.²⁷ The answers to these questions will be evaluated if the applicant elects to participate in CPE.

5.4.5 Evaluation of Community Registration Policies in Community Priority Evaluation

When submitting a Community Application, applicants must propose Community Registration Policies for inclusion in Specification 12 of the applicable Registry Agreements.²⁸ The CPE Panel will evaluate the approved Community Registration Policies (see Section 7.8.4) for consistency with the community objective of the application (see Section 5.4.8.3 Criterion 3: Registration Policies).

This differs from the Registry Commitment Evaluation (RCE) (see Section 7.8.3.2), which verifies that applicant-proposed policies for inclusion in the applicable Registry Agreement are enforceable and compatible with the ICANN Bylaws. See instructions for Question Set 11 Registry Voluntary Commitments for the detailed requirements that guide the drafting approach of proposed Community Registration Policies that will be evaluated through the RCE.

Applicants should be aware that, absent extraordinary circumstances, RCE is estimated to take 60 to 90 days, and occurs before CPE begins.

5.4.6 Role of the Community Priority Evaluation Panel

CPE will be performed by a third-party expert panel appointed by ICANN. The panel’s role is to determine whether a Community Application fulfills the CPE criteria and receives priority over other applications in the contention set. The applicant is expected to provide information and evidence about its identified community in its application (see Question Set 7 Community gTLDs). In making its determination, the panel will review the applicant’s responses to the application questions to ensure all elements of the application are supported by evidence.

The panel may conduct limited independent research deemed necessary to evaluate the application according to the criteria and verify the information provided by the applicant. The panel is expected to focus its limited independent research on the fact-checking required to verify information provided by the applicant. Additionally, as part of this research, the panel may consult with relevant community-related experts to gain insight into highly specialized or localized communities. The guidelines for each criterion in Section 5.4.8 CPE Criteria allow for the panel to consider how a criterion should be evaluated in the context of different types of communities.²⁹

If the panel conducts limited independent research or consults with community experts, it must disclose the results of this research to the applicant and include a citation or link to such research in its evaluation. The applicant will have 30 days to respond before the evaluation decision is rendered. When conducting any such research, panelists are cautioned not to assume an advocacy role either for or against the applicant or application.

Additionally, panelists may issue Clarifying Questions and engage in written dialogue with applicants with applications undergoing CPE, as well as those that have submitted letters of opposition to Community Applications, in order to address potential issues (see Section 5.4.6.1 CPE Clarifying Questions).

5.4.6.1 CPE Clarifying Questions

The panel may issue CPE Clarifying Questions³⁰ to applicants for applications participating in CPE. Clarifying Questions may also be directed to a person or entity that submitted a letter of opposition to a CPE applicant. The applicant, or those who submitted a letter of opposition, will have 21 days to respond from the day after receiving a clarifying question. As described in Section 5.4.6 Role of the CPE Panel, the panel may conduct limited independent research deemed necessary to evaluate the application, including for the preparation and issuing of Clarifying Questions.

5.4.6.2 Challenging CPE

If the panel determines that the application has not met the CPE criteria and the applicant believes there is a factual or procedural error, the applicant may initiate an Evaluation Challenge proceeding within 21 days from the date of transmission of the evaluation determination (see Section 1.2.14.2 Evaluation Challenges). The same CPE provider will review the challenge, using a different set of panelists to form a Challenge Panel, when practicable. If the Challenge Panel finds a factual, procedural, or system error, the application will be reevaluated by the Challenge Panel with those findings in mind. If no error is found, the application will continue to the next stage in the process of contention resolution. There are no additional fees associated with an Evaluation Challenge proceeding.

5.4.7 Community Priority Evaluation Scoring

The CPE Panel will review and score the Community Application against the four CPE criteria. An application must achieve a score of at least 75% (12 out of 16 points) to prevail in CPE. 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 a criterion should only be counted once and should not affect the assessment for other criteria.

The scoring process is designed to identify qualified Community Applications, while preventing both “false positives” (awarding undue priority to an application that refers to a “community” construed merely to get a highly desired 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 panel scores applications based on information provided in the application, plus other relevant information available, such as: responses to CPE Clarifying Questions, application comments, letters of support or opposition, or any limited research conducted by the panel, such as verifying information provided by the applicant with public information regarding the identified community.

A qualified Community Application receives priority over all directly competing applications, allowing it to advance while others cannot. This underscores the strict qualification criteria described below. A panel’s failure to award community priority does not imply the community is inadequate or invalid; it simply indicates the application does not qualify to supersede all other contenders.

If a single Community Application in a contention set is found to meet the CPE criteria, that application will prevail and may proceed to the next step in the application process, subject to meeting all other Program requirements. Other applications in the contention set will be ineligible to proceed at that time.³¹

If more than one Community Application in a contention set is found to meet the criteria, these applications will proceed to an ICANN auction, while other applications in the contention set will be ineligible to proceed. If none of the Community Applications (as there could be more than one) in a contention set meet the CPE criteria,³² then all of the applications in the contention set will proceed to an ICANN auction (see Section 5.2 String Contention and Contention Resolution).

ICANN anticipates that the CPE process will take approximately 180 days.

5.4.8 Community Priority Evaluation Criteria

CPE is based upon the panel’s evaluation of the application against four main criteria:

• Criterion 1: Community Establishment (6 points)

• Criterion 2: Nexus between Proposed String and Community (4 points)

• Criterion 3: Registration Policies (2 points)

• Criterion 4: Community Endorsement (4 points)

5.4.8.1 Criterion 1: Community Establishment

Criterion 1 is used to evaluate the community as explicitly identified in the application. An application can receive up to six points for Criterion 1: two points awarded for the organization sub-criterion, and one point for the engagement, awareness, established presence, and longevity sub-criteria.

The panel will address the following key questions to assess this criterion:

1. Organization (2 points): Is the applicant the organizing body for the community? If not, is the applicant able to demonstrate that the community is organized, with an organizing body(ies) relevant to the community or to each member category of the community? See Section 5.4.8.1.1.

2. Engagement (1 point): Is the applicant able to demonstrate that there is active engagement with community members? See Section 5.4.8.1.2.

3. Awareness (1 point): Is the applicant able to demonstrate awareness among and between community members of the identified community? See Section 5.4.8.1.3.

4. Established Presence (1 point): Is the applicant able to demonstrate external awareness of the community as well as an established presence of the community prior to the opening of the application submission period? See Section 5.4.8.1.4.

5. Longevity (1 point): Is the applicant able to demonstrate the longevity of the community's pursuits, showing that they are enduring and sustainable rather than temporary? See Section 5.4.8.1.5.

5.4.8.1.1 Organization

Table 5-1: Criterion 1 - Organization

• Guidelines for Organization:

  1. Is the applicant able to demonstrate that it is the sole organizing body for the identified community, whether to represent or administer it? If not, is the applicant able to demonstrate that there are organizing bodies relevant to the identified community?

  2. Is there one association dedicated to the identified community as a whole, or are there multiple individual organizations that represent, administer or are relevant to different segments or groups within the identified community?

     1. Multiple entities may administer or represent an identified community. An organization representing an identified community should be regarded with the same level of importance and legitimacy as one that administers the identified community.

  3. In support of providing evidence related to organization, the applicant should provide:

     1. An overview of the identified community structure, as applicable, and whether it is formal or informal:

        1. Formal communities typically have well-defined organizational structures and membership lists, such as economic communities or coalitions of nonprofit organizations.

        2. Non-formal communities may consist of self-identified members, or individuals, such as those in linguistic or cultural groups.

     2. The names of relevant organizations.

     3. Relevant leaders within the identified community, as applicable.

     4. Information regarding how an individual would join the identified community, such as through paying membership fees, skill or accreditation requirements, or certifications aligned with community goals; or, any privileges or benefits entitled to members upon joining the identified community.

     5. Information regarding whether organizing bodies were established to administer or represent the identified community. Relevant information may include the mission statements of the identified organizing bodies.

  4. Does limited independent research deemed necessary to evaluate this criterion (for example, an Internet search) corroborate the evidence provided by the applicant?

     1. Such research may corroborate the existence of bodies or groups that are relevant to the identified community, or, if applicable, evidence of the applicant acting on behalf of the identified community.

     2. The panel may review and verify³³ letters of support or opposition to better understand the organization of the identified community.

     3. The panel may consult with relevant community experts to gain insight into how the organization presents itself in different types of communities.

5.4.8.1.2 Engagement

Table 5-2: Criterion 1 - Engagement

• Guidelines for Engagement:

  1. As noted in the Organization sub-criterion, an identified community may have one or multiple organizations representing or administering it. In the same way, there may be one or multiple organizations or entities conducting engagement activities on behalf of the identified community.

  2. In support of demonstrating active Engagement, the applicant should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:

     1. Offering support.

     2. Sharing information.

     3. Responding to specific community needs.

     4. Fostering and strengthening relationships within the identified community.

     5. The inability to demonstrate recent Engagement-related activities may be an indicator of a community that lacks engagement. However, the panel should take into account different types of communities in evaluating this sub-criterion and the relevance of recent activity.

  2. Does limited independent research deemed necessary to evaluate this criterion (for example, an Internet search) corroborate the evidence provided by the applicant?

     1. Such research may corroborate evidence regarding activities held by the identified community’s organizing body(ies) (or the applicant itself).

     2. The panel may review and verify³⁶ letters of support or opposition to better understand engagement activities of the identified community.

     3. The panel may consult with relevant community experts to gain insight into how engagement may present itself in different types of communities.

5.4.8.1.3 Awareness

Table 5-3: Criterion 1 - Awareness

• Guidelines for Awareness:

1. Are community members aware of the existence of the identified community? Do community members recognize the identified community? The panel should take into account the nature of the identified community. For example, for some communities, awareness or recognition of a community and public acknowledgment of membership in such a community may be limited by national law. The panel should consider that awareness would be assessed differently for such a community.

2. In support of demonstrating Awareness, the applicant should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:

   1. Surveys conducted.

   2. Records of activities involving a diversity of community groups, segments, or members.

   3. The inability to demonstrate recent Awareness-related activities may be an indicator of a community that lacks awareness. However, the panel should take into account different types of communities in evaluating this sub-criterion and the relevance of recent activity.

3. Does limited independent research deemed necessary to evaluate this criterion (for example, an Internet search) corroborate the evidence provided by the applicant?

   1. Such research may corroborate evidence of awareness among community members, including across different segments, such as participation in community activities or discussions in online forums.

   2. The panel may review and verify³⁷ letters of support or opposition to better understand awareness of the identified community.

   3. The panel may consult with relevant community experts to gain insight into how awareness may present itself in different types of communities.

5.4.8.1.4 Established Presence

Table 5-4: Criterion 1 - Established Presence

• Guidelines for Established Presence:

  1. There should be evidence of an established presence of the identified community prior to the opening of the application submission period. The identified community’s existence should be verifiable, and individuals and groups outside of the identified community should be aware of it.³⁸ Awareness levels may vary based on the identified community’s size, scope, or nature. For example, a large, global sports community should demonstrate worldwide recognition, while a small, regional linguistic community may only require evidence of localized awareness.

  2. To demonstrate established presence and external awareness, the applicant should provide documentation of the following practices from the two years leading up to application submission:

     1. Media or other public information regarding the identified community and its activities or members.

     2. Discussion of the identified community in various fora, whether online or in person.

     3. Evidence of partnerships or collaborations with groups outside of the identified community.

     4. Evidence of the chartering or organization of the identified community prior to the opening of the application submission window.

     5. Evidence of contributions (for example, cultural or scientific) to a larger society or population.

     6. The inability to demonstrate an “established presence” may be an indicator of a community that lacks such presence. However, the panel should take into account different types of communities in evaluating this sub-criterion and the relevance of recent activity and how different communities might show presence.

  3. Does limited independent research deemed necessary to evaluate this criterion (for example, an Internet search) corroborate the evidence provided by the applicant?

     1. Such research may corroborate evidence of awareness of the identified community by those outside of it.

     2. The panel may review and verify³⁹ letters of support or opposition to better understand external awareness of the identified community.

     3. The panel may consult with relevant community experts to gain insight into how established presence may present itself in different types of communities.

5.4.8.1.5 Longevity

Table 5-5: Criterion 1 - Longevity

• Guidelines for Longevity:

  1. Is the identified community a relatively short-lived congregation (for example, a group that is formed to represent a one-off event)? Is the identified community forward-looking (that is, will it continue to exist in the future)? The panel should keep in mind that longevity may differ based on the nature of the identified community. For example, in some countries or regions, the continued existence of certain communities may be threatened by national or international policies, and the panel should consider that longevity would be measured differently for such a community.

  2. To demonstrate longevity, the applicant should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:

     1. Evidence of recurring or scheduled activities that demonstrate continuity over time.

     2. Documented records of past activities that demonstrate a long-standing tradition or practice.

     3. Records of discussions emphasizing the identified community’s enduring presence or its cultural significance.

     4. The inability to demonstrate recent longevity-related activities may be an indicator of a community that does not demonstrate longevity. However, the panel should take into account different types of communities in evaluating this sub-criterion and the relevance of recent activity.

  3. Does limited independent research deemed necessary to evaluate this criterion (for example, an Internet search) corroborate the evidence provided by the applicant?

     1. Such research may corroborate evidence of the identified community’s past or planned activities and its ongoing presence, such as through information on community events or published articles about the community’s presence.

     2. The panel may review and verify⁴⁰ letters of support or opposition to better understand longevity of the identified community.

     3. The panel may consult with relevant community experts to gain insight into how longevity may present itself in different types of communities.

5.4.8.2 Criterion 2: Nexus

Criterion 2 is used to evaluate the relevance of the applied-for string to the identified community. An application can receive up to four points for Criterion 2.

The panel will seek to answer the following core question in evaluating the applied-for string against this criterion:

Nexus (4 points): Does the string match the name of the identified community or is it a well-known alternative of the identified community’s name? Would the general public associate the string with the identified community?

Table 5-6: Criterion 2 - Nexus

• Guidelines for Nexus:

  1. What is the name of the identified community? A reference to the name of the identified community is a reference to the established name by which the community is commonly known by others (that is, individuals outside of the community itself or from other relevant organizations,⁴¹ such as established, official, quasi-official, publicly recognized institutions, or other peer groups). The name may be, but does not need to be, the name of an organization dedicated to any member category within the identified community.

  2. Will the general public instinctively think of the identified community when thinking of the applied-for string?

  3. Does the string identify a wider geographic or thematic remit than is related to the identified community? Does the string indicate a community of which the applicant is a part, but is not specific to the applicant’s identified community?

  4. Is the size or definition of the identified community consistent with the string?

  5. If the applied-for string is an IDN, is the applied-for string in the language and script of use for the identified community?

  6. Does limited independent research deemed necessary to evaluate this criterion (for example, an Internet search) corroborate the evidence provided by the applicant regarding the string as it relates to the identified community?

     1. Such research may include verifying whether the applicant’s responses to the application questions align with the mission statements of the relevant organizing bodies to understand the thematic remit of the identified community.

     2. The panel may conduct limited research to help understand whether the string matches the identified community and is known by others. The limited research should also reveal whether there are repeated and frequent references to legal entities or communities other than the identified community referenced in the application.

     3. The panel may review and verify letters of support or opposition to consider in balance how the identified community is known by either its members or those outside of it.

     4. The panel may consult with relevant community experts to gain insight into how different types of communities are named or how they are known by others.

5.4.8.3 Criterion 3: Registration Policies

Criterion 3 is used to evaluate the applicant’s registration policies as indicated in the application. Registration policies are the conditions that the future registry will set for prospective registrants, that is, those desiring to register second-level domain names under the registry. An application can receive up to two points for Criterion 3: one point for eligibility, and one point for name selection.

The panel will seek to answer the following core questions when evaluating the application against this criterion:

1. Eligibility (1 point): Is eligibility for registrants restricted? Who is qualified to register a domain in the applied-for gTLD? Are there specific qualifications provided that entities or individuals must meet to be eligible as registrants by the registry?

2. Name selection (1 point): Do the applicant’s policies include name selection rules? Are name selection rules consistent with the mission statement and articulated community purpose of the applied-for gTLD? What domain names are acceptable in the applied-for gTLD? Are there specific conditions provided that must be fulfilled for a second-level domain name to be considered acceptable by the registry?

5.4.8.3.1 Eligibility

Table 5-7: Criterion 3 - Eligibility

• Guidelines for Eligibility:

  1. What limitations are imposed on potential registrants?

  2. With respect to “Eligibility,” the limitation to community members may involve formal membership or be fulfilled in other ways, depending on the structure and focus of the community at hand. Some informal communities may have different methods for determining membership in a particular community.

     1. For example, for a geographic location Community gTLD, a limitation to members of the community can be achieved by requiring documentation, such as a business license or proof of a local address to verify physical presence in the associated geographic location.

5.4.8.3.2 Name Selection

Table 5-8: Criterion 3 - Name Selection

• Guidelines for Name Selection:

  1. Do the applicant’s policies include name selection rules?

  2. Are the name selection rules consistent with the articulated community purpose of the applied-for gTLD?

  3. If the applied-for string is an IDN, do the name selection rules permit eligible community members to register names in their own language and script, including any necessary variants?

5.4.8.4 Criterion 4: Community Endorsement

Criterion 4 is used to evaluate community support and opposition⁴⁴ to the application. An application can receive up to four points for Criterion 4.

The panel will seek to answer the following core question when evaluating the application against this criterion:

Support and Opposition (4 points): Does the applicant have support from a majority of the identified community?⁴⁵ Does the applicant have any relevant⁴⁶ opposition, from either within the identified community or from relevant organizations outside of it?

Table 5-9: Criterion 4 - Community Endorsement

• Guidelines for the scoring of support or opposition:

  1. To earn full points, the applicant must demonstrate that a majority of the identified community supports the applicant and that the applicant does not have any relevant opposition. The panel should evaluate the applicant’s evidence on community size to determine whether there is majority support or significant opposition.

  2. There may be cases where the applied-for string carries more than one meaning or when an applicant has identified a community that is narrower than the scope suggested by the applied-for string. In those instances, the panel should consider whether the applicant can demonstrate relevant support or no relevant opposition from outside the identified community.

  3. The panel should consider any objections or comments from this application round noting opposition. While these will be assessed, they do not automatically influence the Opposition score, as the panel should consider whether the sources of opposition are clearly spurious, unsubstantiated, or filed for the purpose of obstruction.

  4. The panel should assess whether relevant organizations (for example, official, quasi-official, established, publicly recognized, or peer organizations) oppose the proposal, and if such opposition represents a minority or majority within the community. See guidelines below regarding relevant organizations.

  5. Letters of opposition submitted against a Community Application must be considered in balance with documented support for the application.

  6. The panel may consult with relevant community experts to gain insight into support, opposition, or organization (see guidelines related to relevant organizations below) as they relate to different types of communities.

• Guidelines for majority and minority support or opposition:

  1. Majority and minority are based on the size of the community as specified by the applicant. The panel should consider the applicant’s evidence on the identified community’s size to determine whether there is majority support or notable opposition.

  2. The applicant should clearly define its community, providing estimates of the total size and any sub-groups.

  3. The majority of the identified community may be determined by, but not restricted to, factors like headcount or the geographic reach.

  4. Applicants without evidence of support from a majority of the identified community will not receive points. In some cases, the panel may consider support from outside the community if the applied-for string has multiple meanings or the applicant has identified a narrower community than the scope suggested by the applied-for string.

  5. In some cases, an applicant may have majority support but significant opposition, especially when the community is divided or external parties oppose, such as when a string has multiple meanings. Despite substantial outside opposition, the applicant may still have strong support within the community.

• Guidelines for determining relevant organizations:

  1. The terms relevance and relevant refer to organizations, groups, or communities associated with the string. This means that support or opposition from communities not identified in the application but connected to the applied-for string would be considered relevant.

     1. As noted in “Guidelines for the scoring of support or opposition,” there may be cases where the applied-for string carries more than one meaning or when an applicant has identified a community that is narrower than the scope suggested by the applied-for string. In those instances, the panel should consider whether the applicant can demonstrate relevant support or no relevant opposition from relevant organizations outside the identified community.

  2. Limited research should help determine relevance and size of the objecting or supporting organization(s).

  3. As noted in Section 5.4.8.1 Criterion 1: Community Establishment, there may be one organizing body mainly dedicated to a community or multiple entities dedicated to a community. The panel will consider the following questions in its evaluation:

     1. Are multiple institutions/organizations supporting the application, with documented support from institutions/organizations representing a majority of the overall identified community?

     2. Does the applicant have support from the majority of the recognized community institution/member organizations?

     3. Has the applicant provided full documentation that it has authority to represent the identified community with its application?

  4. In considering relevant support or opposition, the panel should consider both the size of the group or groups expressing support or opposition as well as the relevance to the identified community or the string.

For example, a letter of opposition from an organization claiming to represent millions but weakly connected to the community may carry less weight. In contrast, a letter from a small, closely connected group may be more relevant and impactful. The same principle applies to letters of support.

• Guidelines for reviewing the content of the documentation of support⁴⁸ or opposition:

  1. The documentation clearly expresses the organization’s support or opposition for the identified community.⁴⁹

  2. The documentation demonstrates the organization’s understanding of the string being requested.

  3. The applicant’s documentation is valid, confirming the organization’s existence and the letter’s authenticity.

  4. The documentation should contain a description of the process and rationale used in arriving at the expression of support or opposition. Consideration of support or opposition is not based merely on the number of comments or expressions of support or opposition received. Documentation lacking a clear rationale or substantive explanation for support or opposition will not be considered.

5.5 Contention Resolution for Geographic Names Applications

Due to the sensitivity of contention involving geographic names, their resolution is governed by specific rules.

The following list provides four detailed scenarios and procedures for resolving contention sets involving Geographic Name applications:

1. Capital City Names: As detailed in Section 7.5 Geographic Names, an application for a string that represents a name of the capital city of any country or territory listed in the ISO 3166-1 standard, in any language, will only pass the Geographic Names Evaluation if the Geographic Names Panel (GNP) confirms “that the applicant has provided the required documentation from the relevant governments or public authorities, and that the communication from the government or public authority is legitimate and contains the required content.”⁵⁰ This means that any string that represents such a capital city name but is not supported by the relevant authority or authorities will not pass Geographic Names Evaluation. If an application for a string representing a capital city name, as defined above, is found to be similar visually, aurally or in meaning to another applied-for string (regardless of what string type that string is) then these strings are in contention and will proceed to contention resolution.⁵¹

2. Similar .Brand and Geographic Names: If an application for a Geographic Name string passes the Geographic Names Evaluation and is part of a contention set containing one or more non-Geographic Name applications (and no other applications supported by another government authority), the contention set will be resolved via contention resolution.

Example: If two applications are submitted for .GENERICOPOLIS, one as a Geographic Name application for a city in Genericstan, and the other as a .Brand TLD application not intended to be operated as a Geographic Name, both will proceed to contention resolution if the applications pass all other applicable string evaluations.

3. Support from the Same Government Authorities: ​If two or more applications for strings that represent the same geographic location pass the Geographic Names Evaluation with documentation of support or non-objection from the same relevant government or public authority,⁵² as determined by the GNP, and also pass all applicable string evaluations, these applications will proceed to auction to resolve contention.

Example: If three applications for .GENERICOPOLIS have all received letters of support from the relevant government authority of Genericopolis, Genericstan, then all three will proceed to contention resolution.

4. Support from Different Government Authorities: ​If two or more contending applications for Geographic Name strings pass the Geographic Names Evaluation with documentation of support or non-objection from different relevant governments or public authorities,⁵³ as determined by the GNP, and also pass all applicable string evaluations, these applications will undergo Extended Evaluation by the GNP. If, during Extended Evaluation, the GNP determines that all of the different relevant authorities have issued support for or non-objection to the applications they support to proceed to contention resolution, then the contention set will be resolved via contention resolution.

However, if the GNP determines that one or more relevant authorities have refused to support, or did not issue a statement of non-objection to contention resolution, then no application in the contention set can proceed. All applicants in the contention set will become eligible to receive refunds in accordance with the refund schedule (see Section 3.3 Fees and Payments).

Example: Should ICANN receive two applications for .GENERICOPOLIS and one is supported by Genericopolis, Genericstan and the other one is supported by Genericopolis, Genericland, then the GNP will move these applications to Extended Evaluation. If, during Extended Evaluation, the GNP is satisfied that the supporting authorities of both Genericopolis, Genericstan and Genericopolis, Genericland support or do not object that “their” applications can proceed to contention resolution, then they will proceed accordingly. If the GNP is not satisfied that the supporting authorities of Genericopolis, Genericstan and Genericopolis, Genericland agree that these applications can proceed to contention resolution, then neither application can proceed, and applicants will receive refunds in accordance with the refund schedule.

5.6 ICANN New gTLD Auction

This section provides applicants a high-level overview of the principal features of an ICANN New gTLD Auction. A detailed set of auction rules and procedures, based on those published for the 2012 Round,⁵⁴ along with an auction schedule, will be developed by ICANN in consultation with the auction provider and available no later than 60 days before the first auction.

5.6.1 Auction Overview

The auction is the final method for addressing contention which has not been eliminated previously in the course of the application process or resolved through CPE.⁵⁵ If CPE occurs and more than one application passes CPE, the successful CPE applications will also proceed to the auction to resolve the contention among the applications that received priority.

The auction is intended to resolve contention among applicants in a contention set for a new gTLD. Once the auction has concluded, only one of the participating applications in direct contention for an applied-for gTLD will be eligible to proceed towards delegation, pending the outcome of the Applicant and Application Evaluation and the successful execution of a contract for the applied-for gTLD.

5.6.2 Scheduling of Auctions

In general, auctions will be scheduled on a rolling basis as all applications in a contention set meet the following auction eligibility criteria:

• Completed string evaluation and all related processes (see Module 7 String and Application Evaluation Procedures)

• All applicable objections and appeals are resolved (see Section 4.5 Objections and Appeals)

• All evaluation challenges, if applicable, are completed⁵⁶

• Completed CPE, if applicable

• Have no open, relevant application change requests (see Section 3.8 Application Change Requests)

• Have no pending accountability mechanisms (see Section 2.7 Accountability Mechanisms)

The time required for contention sets to become eligible for auction will vary, depending on the duration of the above-mentioned processes.

Applicants will be notified of the auction time and date via the application system at least 30 days before the auction date.

5.6.3 Auction Method

The auction will be conducted using the “ascending-clock, second-price” auction method, which was also used in the 2012 Round of the New gTLD Program.⁵⁷

In an “ascending-clock, second-price” auction:

• The auction price increases in a series of timed steps.

• As the price rises, participating bidders successively choose to exit from the auction.

• The auction concludes when only one bidder remains.

• The bidder with the highest bid will win the auction and pay the second-highest bid.

• Indirect contention sets will be resolved via a single auction, which may result in more than one winner (see Figure 5-3 Example of Indirect Contention Set Resolution).

5.6.4 Winning Bids Payments

Details regarding the requirements for winning bid payments will be outlined in the auction rules and procedures that will be published no later than 60 days before the first auction.

If the applicant of the application that prevailed in the auction, having paid its winning bid payment as detailed in the forthcoming auction rules and procedures, fails any of the Applicant Evaluation Procedures or String and Application Evaluation Procedures and cannot proceed, the applicant will receive a refund of its winning auction bid in addition to any applicable refund of its application fee. In such a circumstance, ICANN reserves the right to withhold any costs or fees that the auction provider has charged or will charge for their services.

If an applicant of the application that prevailed in the auction, for any reason, is ineligible to execute the Registry Agreement, ICANN may, at its option, offer the runner-up applicant the opportunity to proceed with its application. In such a case, the runner-up would be required to pay its exit bid to proceed. However, 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 for any reason.

5.6.5 Bid Credits for Applicant Support Program Applicants in Auctions

An applicant receiving Applicant Support as part of the Applicant Support Program (ASP) will receive a bid credit to increase its chances of winning an auction by providing a discount on the amount otherwise due on a winning bid.

In this application round, ICANN has set a level of bid credit at a maximum of 35%, not to exceed a monetary value of USD 1.75 million per application. The bid credit provides up to a 35% discount applied to the amount due to be paid by the winning supported applicant, as well as to any deposit that may be required according to the final auction rules. In the case that the winning price (second highest price) auction dues exceed USD five million (the threshold indicating Financial Need to qualify for support), the bid credit applied will be reduced in a phased approach (see Example 2 below and Table 5-10 Phase-out Bid Credit for Supported Applicants).

For example:

• Example 1: A supported applicant submits the highest bid of USD one million. Another application submits the second highest bid of USD 900,000. The winning supported applicant pays USD 585,000 (35% bid credit applied to the second highest bid of USD 900,000).

• Example 2: A supported applicant submits the highest bid of USD seven million. Another application submits the second highest bid of USD six million. The winning supported applicant pays USD 4.8 million (based on the phased approach indicated a 20% bid credit applied to the second highest bid of USD six million). See Table 5-10 for more detail.

Table 5-10: Phased-out Bid Credit for Supported Applicants for Winning Bids >5 Million USD

Full details of the bid credit procedures for eligible auction participants will be included in the ICANN New gTLD Auction rules and procedures.