New gTLD Program Applicant Guidebook Site
Program Website Search
New gTLD Program Applicant Guidebook Banner

Module 7 String and Application Evaluation Procedures

The New gTLD Program: 2026 Round represents a critical evolution of Internet infrastructure. While enthusiasm for potential new domain name extensions is high, the string and application evaluation process is designed to safeguard DNS stability while addressing stakeholder concerns. Each string must be meticulously analyzed for uniqueness, clarity, and potential confusion with existing strings or trademarks to ensure it does not compromise overall DNS integrity.

For specific application types, the assessment of an applicant’s community engagement and commitment to transparency and accountability is especially critical.

Module 7 outlines the assessment process, including:

  • Overview of application types and handling methods.

  • Examination of TLD types, like geographic names and internationalized domain names.

  • Strategies to mitigate name collisions.

  • String Similarity Evaluation.

This module provides a detailed look at this essential, carefully devised process to ensure DNS stability and security.

7.1 String and Application Types

Applicants may encounter different requirements and processing steps depending on the type of application or string they apply for. These variations can affect the following aspects:

  • Application Questions: Some application types will require the applicant to answer specialized questions as part of its application (for example, questions related to an applicant’s community objectives).

  • Prioritization: Certain application types could receive priority in the prioritization draw (for example, an IDN).1

  • Evaluation: The nature, focus, or goal of an application may require a specialized evaluation (for example, for a geographic name).

  • Contention: Contention resolution procedures might be specialized depending upon the application type (for example, Community Priority Evaluation).

  • Registry Agreement: Some application types may be considered exempt from certain provisions while others may be required to include specialized provisions in their Base Registry Agreements (for example, Code of Conduct Exemption).

  • Fees: Additional evaluation or application fees may be required (for example, for conditional evaluations such as Community Priority Evaluation).

Applicants should review the information in this section to understand the potential for differing requirements for different application types.2

7.1.1 General Applications

A general application is one that does not fall into one of the application types defined in Section 7.1.2 Specialized Applications and is subject to the standard set of requirements defined throughout this Applicant Guidebook.

7.1.2 Specialized Applications

Specialized applications are those that may have different requirements based on the application (for example, an application for a Community gTLD), string (for example, an IDN), or applicant type (for example, an IGO or Applicant Support applicant). This section provides an overview of these specialized application types. An application may qualify for multiple designations simultaneously; for example, an application could be classified as both an IDN and a Community Application.

7.1.2.1 Applications for Community gTLDs

At the time of application submission, an applicant may designate an applied-for gTLD string as Community gTLD.3 Such an applicant must operate the string for the benefit of a clearly delineated community (see Section 5.4 Community Priority Evaluation). Applicants submitting a Community Application will be subject to additional requirements throughout various stages of the application lifecycle, including the following areas:

  • Application Questions: Applicants who designate their application as a Community Application will be asked to answer a series of questions specific to Community Applications.4 The answers to these questions will be evaluated if the applicant elects to participate in CPE. See Appendix 1 Application Questions (Question Set 7 Community gTLDs).

  • Evaluation: Evaluation of Registry Agreement Community Registration Policies (“Community Registration Policies”) – through the Registry Commitments Evaluation (RCE) – proposed for inclusion in the Registry Agreement regarding the operation of an applied-for Community gTLD will occur during application evaluation, unless the Community Applicant opts to participate in CPE, which is an option only available to Community Applications to resolve contention. If the applicant opts to participate in CPE, the RCE will occur earlier, before application evaluation, because this evaluation must occur before the application is eligible to participate in CPE. See Section 7.8 Public Interest Commitments, Registry Voluntary Commitments, and Community Registration Policies.

  • Contention: If in contention with other applications for the same string, the applicant may elect to participate in Community Priority Evaluation (See Section 5.4) and potentially an ICANN Auction. See Section 5.2 String Contention and Contention Resolution Procedures.

  • Contracting: The applicant must enumerate Community Registration Policies that are evaluated and approved by ICANN and, where relevant, evaluated during CPE, in Specification 12 of its Base Registry Agreement. See Section 1.2.15 Contracting. See also Section 7.8.4 Community Registration Policies below concerning the evaluation of Community Registration Policies.

  • Fees: Should an applicant opt to participate in CPE, the applicant must pay an additional evaluation fee. See Section 3.3 Fees and Payments.

ICANN will evaluate all Community Registration Policies proposed by applicants for Community gTLDs for inclusion in the applicable Registry Agreement during application evaluation. At a minimum, these policies must cover registrant eligibility and naming selection. The evaluation of the Community Registration Policies aligns with ICANN’s approach to evaluating all supplemental commitments proposed by applicants using a uniform framework. More information about this framework is available in Section 7.8 Public Interest Commitments, Registry Voluntary Commitments, and Community Registration Policies.

To be considered during CPE, proposed Community Registration Policies for inclusion in the Registry Agreement must be assessed in Registry Commitments Evaluation (RCE) (before CPE). This ensures that the commitments can be mutually agreed upon between the applicant and ICANN for inclusion in the applicable Registry Agreement. If such commitments cannot be agreed upon, they will not be considered during CPE.

Any applicant designating its application as a Community Application will be required, if the application is approved, to include the Community Registration Policies agreed upon with ICANN during the application evaluation in Specification 12 of the applicable Base Registry Agreement. This requirement applies even if there are no contending applicants or an applicant with a Community Application chooses not to participate in CPE to resolve contention. In summary, approval of the Community Registration Policies is required not only for a Community Application to participate in CPE, but also to move forward in the application process after RCE. If there are no Community Registration Policies that can be approved by ICANN for inclusion in the Registry Agreement, the Community Application cannot advance – regardless of whether it is in contention or whether the applicant chooses to participate in the CPE.5

See Section 5.4 Community Priority Evaluation for more information on Community Priority Evaluation and Section 7.8 Public Interest Commitments, Registry Voluntary Commitments, and Community Registration Policies.6

There will also be a fee for the Registry Commitment Evaluation (RCE) process for Specification 12 (see Section 3.3 Fees and Payments).

7.1.2.2 Applications for Geographic Names

An applicant may designate its application as a geographic name.7 It is the applicant’s responsibility to identify whether its applied-for gTLD string falls into any of the defined geographic names categories (see Section 7.5 Geographic Names), consult with the relevant governments or public authorities, and determine the level of government support required.

In addition, as part of initial string evaluation, ICANN will review all applications to determine whether an applied-for string qualifies as a geographic name, as described later in this section. If an applicant does not self-designate its application as a geographic name but it is later identified as such by ICANN, the application will still be subject to the additional requirements for a geographic name. Applicants can expect to find differing requirements in the following areas of the application lifecycle:

7.1.2.3 Applications for Reserved Names

All applied-for gTLD strings are compared with both the Reserved and Blocked Names lists. While Blocked Names cannot be applied for, eligible entities may apply for a Reserved Name as defined in Section 7.2 Blocked and Reserved Names.8 To apply for such a name, the applicant must follow the process defined in Section 7.2.2.2.1 Exception Process to Apply for a Reserved Name. Applicants submitting applications for a Reserved Name can expect to find differing requirements in the following areas of the application lifecycle:

  • Application Questions: An applicant will be required to answer additional questions regarding the Reserved Name for which it is applying. See Appendix 1 Application Questions.

  • Evaluation: An applicant for a Reserved Name must submit documentation, including a Certification of Incorporation and a letter from the parent organization, along with documentation of support or non-objection, which may include a signed letter, if applicable. See Section 7.2.2 Reserved Names.

7.1.2.4 Applications for .Brand TLDs

An applicant has the ability to self-designate its application as a .Brand TLD. This application type allows an applicant to use its company or brand name as a TLD.9 A .Brand TLD is a string that is identical to the textual elements (for example, a name, word, or phrase) of a registered trademark valid under applicable law,10 and which the applicant operates as a .Brand TLD.11 Applicants submitting applications for a .Brand TLD should anticipate differing requirements in the following areas of the application lifecycle:

If an applicant for a .Brand TLD qualifies as a .Brand TLD, Specification 13 will be included in its applicable Registry Agreement and the applicant will also obtain a Code of Conduct (CoC) Exemption. However, in some cases, an applicant for a .Brand TLD may obtain a CoC Exemption but not be eligible for Specification 13.

7.1.2.5 Applications for Internationalized Domain Names

Applicants will have the ability to apply for IDNs. Applications for IDNs must comply with the requirements defined in Section 3.1.9 Internationalized Domain Names, and applicants can expect to find differing requirements in the following areas of the application lifecycle:

7.1.2.6 Applications for Variants of Existing gTLDs

Existing registry operators will have the opportunity to apply for allocatable variant strings of existing gTLDs.15 Applications for these variant strings must comply with the requirements defined in Section 3.1.9 Internationalized Domain Names, and applicants can expect to find differing requirements in the following areas of the application lifecycle:

  • Application Questions: An applicant will be asked additional questions regarding the variant string it is applying for. See Appendix 1 Application Questions.

  • Prioritization: Subject to the limits and requirements identified in Section 3.7 Order of Application Processing and Prioritization Draw, applications for allocatable variant strings may be prioritized over applications for non-IDNs.

  • Evaluation: An applicant for an allocatable variant of an existing gTLD will be subject to review by a panel and will be expected to provide justification for the need for the variant (for example, explanation of how the primary and variant strings are considered the same).16 Additional requirements may include using the same RSP for the variant registry as the primary registry. See Appendix 1 Application Questions and Section 7.10 String Similarity Evaluation.

  • Contracting: Specification 14 will be added to the Base Registry Agreement for execution. See Section 1.2.15 Contracting.

  • Fees: Existing registry operators applying for allocatable variant strings of existing gTLDs will have the base application fee waived for up to four variant strings;17 applications for more than four variant strings will incur additional fees. See Section 3.3 Fees and Payments.18

7.1.2.7 Applications for New IDNs Including One or More Variants

Applicants will have the opportunity to apply for a new IDN TLD plus its allocatable variant strings. Applications for a new IDN TLD and its allocatable variant strings must comply with the requirements defined in Section 3.1.9 Internationalized Domain Names and can expect to find differing requirements in the following areas of the application lifecycle:

  • Application Questions: An applicant will be asked additional questions regarding the IDN TLD and its allocatable variant strings for which it is applying. See Appendix 1 Application Questions.

  • Prioritization: Subject to the limits and requirements identified in Section 3.7 Order of Application Processing and Prioritization Draw, applications for IDN TLDs, including allocatable variant strings, may receive priority in processing over applications for non-IDNs.

  • Evaluation: An applicant for a new IDN TLD and its variant strings will be subject to review by a panel and will be expected to provide justification in its application for the necessity of the variant (for example, explaining how the primary and variant strings are considered the same).19 Additional requirements may apply, such as using the same RSP for the variant registry as the primary registry, as well as ensuring that the TLD types are consistent across the primary string and variant strings. See Section 7.10 String Similarity Evaluation.

  • Contracting: Specification 14 will be added to the Base Registry Agreement for execution. See Section 1.2.15 Contracting.

  • Fees: New applicants applying for a primary string plus its variant strings will not incur additional application fees beyond the base fee for up to four variant strings. However, applications for the primary string plus more than four variant strings will incur additional fees. See Section 3.3 Fees and Payments.20

7.1.2.8 Applications from Intergovernmental Organizations or Governmental Entities

An application from intergovernmental organizations (IGOs)21 or governmental entities22 will be accepted. Applicants in this category should consider the requirements for geographic names defined in Section 7.5 Geographic Names, as well as requirements for reserved names specified in Section 7.2 Blocked and Reserved Names. These applicants can expect to find differing requirements in the following areas of the application lifecycle:

7.1.2.9 Applications for Applicants Eligible for Applicant Support

Before the current round opened, prospective applicants had the opportunity to apply to participate in the Applicant Support Program. Applicants that applied to participate were evaluated based upon the criteria set forth in the Applicant Support Handbook. An application for Applicant Support is distinct from an application for a new gTLD. Applicants that receive Applicant Support must also meet the requirements and eligibility criteria for a new gTLD application, as defined in this Applicant Guidebook.

Eligible applicants for Applicant Support can expect to find differing requirements in the following areas of the application lifecycle:

  • Contention: Applicant Support applicants participating in an ICANN Auction will receive a bid-credit. See Section 5.6.5 Bid Credits for Applicant Support Program Applicants in Auctions.

  • Contracting: If an applicant successfully obtains Applicant Support and its application prevails in an auction, the applicant will be restricted from assigning the Registry Agreement, or undergoing any Change of Control for a minimum of three years. See Section 1.2.15 Contracting.

  • Fees: An applicant qualifying for Applicant Support will be eligible to pay a reduced application fee as well as reduced conditional evaluation fees. See Section 3.3 Fees and Payments as well as the Applicant Support Program Handbook for more information.23

7.1.3 Changing Application Types

In some cases, an applicant may wish to change its application type. This may or may not be permitted, based on the application type. For example, an applicant will not be permitted to change a Community gTLD designation. See Section 3.8 Application Change Requests for more information regarding which changes to an application or string type may be permitted.

7.2 Blocked and Reserved Names Overview

Certain names are blocked and therefore not available for use as gTLD strings. The Blocked Names list is informed by a range of sources and inputs, as described below. Other names are reserved at the top level based on consensus policy and maintained on a list by ICANN.24

Note: In the 2012 Applicant Guidebook, the list called “Strings Ineligible for Delegation” is now referred to as the Reserved Names List, and the list previously called the “Top-Level Reserved Names List” is now known as the Blocked Names List.

As part of the Section 3.1.8 Pre-Submission String Validations, all applied-for gTLD strings and their variant strings, are compared with both the Reserved and Blocked Names lists. This comparison ensures that the applied-for gTLD string does not appear on either list. Applicants will have the ability to enter a proposed string in TAMS to check whether it appears on either the Blocked or Reserved Names lists.

In addition, Blocked and Reserved Names that do not conform to the framework of DNS permissible characters will be converted into DNS labels that contain only letters, digits, and hyphens consistent with consensus policy.25

7.2.1 Blocked Names

gTLD strings and their allocatable variants on the Blocked Names list are not eligible for application in the current round or in any future application round, as per consensus policy. However, the list does not apply to gTLDs that have already been delegated into the root zone.

The following gTLD strings and their allocatable variant strings are on the Blocked Names list (see footnotes for actual lists) and cannot be applied for:

  • Special-Use Domain Names: These are specific strings reserved by technical standards for purposes inconsistent with delegation, as explicitly noted on IANA’s Special-Use Domain Names Registry.26,27,28

  • Technical Standards: See Section 3.8.3 DNS Stability Review for more details.

  • Country or Territory Names in relation to Geographic Names: See Section 7.5 Geographic Names.

  • ICANN, IANA, and IETF-Related Bodies and Internet Infrastructure: These include, for example, ICANN's Supporting Organizations (SOs) and Advisory Committees (ACs),29 Regional Internet Registries,30 IETF bodies,31 and system identifiers included through consensus policy.32,33

ICANN, IANA, and IETF-Related Bodies and Internet Infrastructure
AFRINIC GNSO INTERNIC NRO TLD
ALAC GTLDSERVERS INTERNAL PTI WHOIS
APNIC IAB IETF RFCEDITOR WWW
ARIN IANA IRTF RIPE
ASO IANASERVERS ISTF ROOTSERVERS
CCNSO ICANN LACNIC RSSAC
GAC IESG NIC SSAC
Note: The strings on the list are blocked only in the form included above.

  • Other Non-Permitted Strings:

    • Delegated TLDs.34,

    • The gTLD strings which were applied for in previous gTLD rounds and that are still in process.35

    • Existing successfully evaluated ccTLDs.

    • Strings currently requested as IDN ccTLDs.

    • All other one- or two-letter ASCII strings.

7.2.1.1 Blocked Names Identification

When an applicant fills in the name of the applied-for string, the system will automatically check whether the applicant’s chosen string, including any variant strings, appears on the Blocked Names list. If the string is found on this list, the system will prevent the applicant from proceeding with that string. To continue with the application, the applicant must revise the entry and select a different string that is not blocked.

7.2.1.1.1 Blocked Names Identification Challenge

In cases where an applicant believes it is being prevented from submitting its application or has to provide additional documentation because a system error in the automated Blocked Names Identification process resulted in an applicant’s string being incorrectly classified as a Blocked Name, and, consequently, the applicant was unable to proceed to submission, then the applicant will have the opportunity to file a challenge no later than 14 days prior to the close of the application submission period36 (see Sections 1.2.14.2 Evaluation Challenge and 3.1.8.4 Challenging the Pre-Submission String Validations).

7.2.2 Reserved Names

The Reserved Names evaluation process is divided into two parts: Reserved Names Identification, an automated check that identifies whether an applied-for string appears on the Reserved Names list, and Reserved Names Review, which includes both the exception process for an applicant to apply for a Limited International IGO-INGO name and the verification of required documentation.37

The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in Section 7.2.2.2 Reserved Names Identification below:

  • Names added based on recommendations from the IGO-INGO PDP Working Group38 regarding the protections of IGO-INGO identifiers in all gTLDs,39,40 including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC),41 International Olympic Committee (IOC),42 and International Governmental Organization (IGO)43 – International Non-Governmental Organizations (INGO) Names.,44

7.2.2.2 Reserved Names Identification

When an applicant enters the applied-for string, the system will automatically check whether that string, including any allocatable variant strings, appears on the Reserved Names List. If it does, the exception process will be triggered, prompting the applicant to upload supporting documentation to demonstrate that they are the entity for which the name is reserved.

In addition to this check, the system will also verify whether the string is a variant of a Reserved Name. In such cases, the applicant will only be able to proceed if the Reserved Name itself is being applied for as the primary string, or if the applicant provides confirmation that it is the registry operator for the TLD matching the Reserved Name.

7.2.2.2.1 Reserved Names Identification Challenge

If an applicant believes that a system error in the automated Reserved Names Identification process resulted in its string being incorrectly classified as a Reserved Name, it may initiate an Evaluation Challenge. The challenge must be filed no later than seven days prior to the close of the application submission period.

ICANN will review the Evaluation Challenge. If ICANN determines that a system error led to the incorrect classification of the string as a Reserved Name, the system error will be corrected, allowing the application to proceed to the next appropriate stage in the process. If no error is found, the application will proceed, but must meet the Reserved Name criteria during the Reserved Names Review phase. There are no conditional fees associated with an Evaluation Challenge related to Reserved Names. Applicants are responsible for ensuring compliance with all Reserved Names requirements, even in cases of system error.

7.2.2.3 Reserved Names Review

7.2.2.3.1 Exception Process to Apply for Reserved Names

Applicants may request a string on the Reserved Names list through the exception process. During the Reserved Names Review, the panel evaluates the exception and verifies the applicant’s supporting documentation to confirm they are the eligible entity to operate the reserved name. See Section 7.2.2 Reserved Names for the specific strings included on the Reserved Names list.

To apply for a Reserved Name through the exception process, applicants must submit the following types of documentation at the time of application:

  • Certification of Incorporation and, if applicable, letter from parent organization.

  • Documentation of support or non-objection including a signed letter from the relevant public authority (if applicable).

7.2.2.3.1.1 Verification of Submitted Documentation

If an applicant from one of the Limited International IGO-INGOs listed above uses the exception process to apply for a name from the Reserved Names list, including its allocatable variant strings, a verification process will be initiated. This process will confirm that the applicant has submitted satisfactory documentation establishing its eligibility to apply for that particular TLD. The verification process for the applying organization/entity will occur as part of the application evaluation phase.

ICANN may consult with the relevant authorities for further verification.

If applicable, for further assistance in determining who the relevant government or public authority may be for a request, the requester may wish to consult with the relevant GAC representative.45

7.2.2.3.2 Extended Evaluation for Reserved Names Review

An applicant that does not provide adequate documentation demonstrating its eligibility to apply for a TLD listed on the Reserved Names list will fail the Reserved Names Review.

However, if it is determined that an application does not meet the criteria identified for the Reserved Names Review, the applicant may request Extended Evaluation. During Extended Evaluation, Clarifying Questions may be issued to obtain additional information. To ensure timely processing, applicants will be encouraged to respond as soon as possible, but no later than 21 days after receiving the Clarifying Questions. If the additional information provided does not satisfy the Reserved Names criteria, the application will not pass the review and will not proceed.

7.3 .Brand TLD Eligibility Evaluation

Applicants will have the ability to self-designate an application as a .Brand TLD. This application type allows a business or corporation to use its company or brand name as a TLD. See Section 3.1.6 Application and String Types.

7.3.1 Eligibility for .Brand TLD Eligibility Evaluation

An applicant that seeks to designate its applied-for string as a .Brand TLD must undergo the .Brand TLD Eligibility Evaluation. The purpose of this evaluation is to confirm that the applicant meets the criteria for the .Brand TLD designation. Applications that pass the .Brand TLD Eligibility Evaluation will have Specification 13 added to the applicable Base Registry Agreement if the application proceeds to delegation. See Appendix 4 Base Registry Agreement for Specification 13 terms.46

An applicant may request the .Brand TLD Eligibility Evaluation in its application or via an Application Change Request. See Section 3.8 Application Change Requests.

7.3.2 Conditional Fee for .Brand TLD Eligibility Evaluation

An applicant that requests the .Brand TLD Eligibility Evaluation must pay an additional evaluation fee as specified in Section 3.3 Fees and Payments. The .Brand TLD Eligibility Evaluation will not be performed until ICANN receives the relevant fee.

7.3.3 Evaluation and Outcomes of .Brand TLD Eligibility Evaluation

To qualify for a .Brand TLD designation, an applicant must provide one or more Trademark Clearinghouse (TMCH) Signed Mark Data (SMD) files. See the TMCH guidelines for eligibility requirements.47

7.3.3.1 Engagement with Trademark Clearinghouse Before Submitting a .Brand TLD Application

An applicant that plans to designate its applied-for string as a .Brand TLD should take preparatory actions well in advance of initiating the application to ensure it can demonstrate eligibility upon submission.

.Brand TLD applications must include one or more Trademark Clearing House (TMCH) Signed Mark Data (SMD) files in support of the .Brand designation. Because adding or adjusting the TMCH filings may take several months to complete and may involve fees paid directly to the TMCH, .Brand TLD applicants should carefully review their existing TMCH SMD files or acquire new SMD files as soon as practicable. .Brand TLD applicants should take the following steps in relation to the TMCH (where applicable) before applying for a .Brand TLD:

  • A .Brand TLD applicant without a relationship with the TMCH or without SMD files covering the strings for which it wishes to apply should initiate the TMCH vetting.48

  • Ensure that any desired TLD labels are listed in <mark:label> elements in SMD files. Any string that a .Brand TLD applicant wishes to apply for must exactly match a <mark:label> element in a valid SMD dated prior to application submission.

  • Ensure that any desired variant labels of the primary .Brand string are listed in <mark:label> elements in SMD files. All applied-for variant strings of a .Brand TLD must exactly match a <mark:label> element in a valid SMD dated prior to application submission.

  • Ensure that the <mark:goodsAndServices> elements are correct, complete, and include a word that the applicant may want to use in a .Brand String Change pursuant to a .Brand String Change Request (see Section 5.3). Additional words used to augment the applied-for .Brand string should appear in a <mark:goodsAndServices> element of a valid SMD file dated prior to the submission of a .Brand String Change Request.

If the words used to augment the applied-for string do not appear in a SMD file, it may still be possible to submit a .Brand String Change Request using alternate documentation. See Section 5.3.2 .Brand String Change Request Requirements.

7.3.3.2 .Brand TLD Eligibility Evaluation Criteria

The .Brand TLD Eligibility Evaluation will be performed by a .Brand TLD Eligibility Evaluation Panel. An applicant seeking the .Brand TLD designation must demonstrate that the application meets the following criteria:

1a. The applied-for gTLD string must exactly match the textual elements of a registered trademark verified by the TMCH in the provided SMD files; or

1b. If the applicant changed its applied-for string using a .Brand String Change Request (Section 5.3), the final string must meet all of the requirements set forth therein.

2. The applicant and the final string (including all allocatable variant strings) must meet all of the requirements set forth in Specification 13 of the Base Registry Agreement. See Appendix 4 Base Registry Agreement.

The applicant will be required in its application to self-certify affirming compliance with the criteria as set forth above and in Specification 13 of the Base Registry Agreement (see Appendix 4 Base Registry Agreement). Additionally, the applicant must confirm non-generic usage in its application. See Question Set 13 .Brand TLD and Code of Conduct Exemptions in Appendix 1 Application Questions.

7.3.3.3 .Brand TLD Eligibility Evaluation Clarifying Questions

ICANN may issue Clarifying Questions during the .Brand TLD Eligibility Evaluation. Applicants will have seven days to respond to administrative clarifying questions and 21 days to respond to substantive clarifying questions. If the applicant fails to respond within that defined period, the applicant may forfeit the opportunity to address any issues found by the evaluation panel.

7.3.3.4 Results of .Brand TLD Eligibility Evaluation

The results of the .Brand TLD Eligibility Evaluation will be included in the Application and Applicant Evaluation Reports, as described in Section 1.2.13 Publication of Application and Applicant Evaluation Reports.

If an application passes the .Brand TLD Eligibility Evaluation, Specification 13 will be added to the applicable Base Registry Agreement if the application proceeds to delegation.

If a .Brand TLD Eligibility Evaluation is not successful, the applicant may elect to continue with its application without the .Brand TLD designation, that is, without the addition of Specification 13.

If the .Brand TLD request is made outside of the application submission window by an Application Change Request, or an applicant wishes to withdraw its request for a .Brand TLD designation, a comment window will open for 30 days.

7.3.4 Challenges and Extended Evaluation for .Brand TLD Eligibility Evaluation

Applicants will have the ability to resubmit the required documentation if the initial submission of such documentation is non-compliant. Because of this, extended evaluation or a challenge mechanism is not applicable for this evaluation.

7.3.5 String Contention and String Change

An applicant that successfully completes the .Brand TLD Eligibility Evaluation may be permitted to change its primary string to avoid string contention. See Section 5.3 .Brand String Change Request for more information regarding the procedures for a .Brand TLD String Change Request.

7.4 Registry Operator Code of Conduct Exemption Evaluation

Specification 9 of the Base Registry Agreement contains the Registry Operator Code of Conduct. The purpose of the Code of Conduct is to protect a gTLD’s registrants. In some cases, an exemption from the Code of Conduct may be requested.

7.4.1 Eligibility for Code of Conduct Exemption Evaluation

If a registry operator registers all domain names in the gTLD exclusively for and to be used only by itself or its Affiliates, (as defined in Appendix 4 Base Registry Agreement) and the registry operator would like to waive the protection for itself and its Affiliates, ICANN may grant the registry operator an exemption to the Code of Conduct, provided the gTLD is not a generic string (see Section 3.1.7 Closed Generics) and the registry operator can satisfy all exemption criteria. See Appendix 4 Base Registry Agreement for Specification 9 text.

An applicant is permitted to request a Code of Conduct Exemption in its application or, after the submission of the application, using an Application Change Request. The request for Code of Conduct Exemption is open to the public for review and input via the application comment period (see Section 4.1.3 Application Comments in the Evaluation Process).

7.4.2 Code of Conduct Exemption Evaluation for Variant Strings

If an applicant applies for allocatable variant string(s) of an applied-for primary gTLD string and seeks the Code of Conduct Exemption, the Code of Conduct Exemption Evaluation will cover both the applied-for primary and variant strings.

7.4.3 Conditional Fees for Code of Conduct Exemption Evaluation

Applicants that request the Code of Conduct Exemption Evaluation must pay an additional fee, as specified in Section 3.3 Fees and Payments. The Code of Conduct Exemption Evaluation will not be performed until the relevant fees are received by ICANN.

7.4.4 Code of Conduct Exemption Evaluation Criteria

The Code of Conduct Exemption Evaluation will be performed by the Code of Conduct Exemption Evaluation Panel. The determination of whether ICANN will grant an exemption to the Code of Conduct will consist of a review of the assertions in the exemption request to verify that if the applicant becomes a registry operator, it will satisfy all three of the exemption criteria:

  1. All domain name registrations in the gTLD and variant string(s), if applicable, will be registered to, and maintained by, Registry Operator for the exclusive use of Registry Operator or its Affiliates (as defined in the Base Registry Agreement);

  2. Registry Operator will not sell, distribute or transfer control or use of any registrations in the gTLD and variant string(s), if applicable, to any third party that is not an Affiliate of Registry Operator; and

  3. Application of the Code of Conduct to the gTLD and variant string(s), if applicable, is not necessary to protect the public interest.

An applicant requesting a Code of Conduct Exemption will be required in its application to self-certify affirming compliance with the criteria as set forth above. Additionally, mission and purpose statements must demonstrate non-generic usage. That is, in order to ensure that approval of a Code of Conduct Exemption will not conflict with Specification 11 of the Base Registry Agreement, which prohibits generic gTLDs and variant strings from being operated on an exclusive basis, the string must not be a closed generic as defined in Section 3.1.7 Closed Generics.

7.4.5 Code of Conduct Exemption Evaluation Clarifying Questions

ICANN may issue Clarifying Questions as part of the Code of Conduct Exemption Evaluation. An applicant will have seven days to respond to administrative clarifying questions and 21 days to respond to substantive clarifying questions. If the applicant fails to respond within that defined period, the applicant may forfeit the opportunity to address any issues found by the evaluation panel.

7.4.6 Results of Code of Conduct Exemption Evaluation

The results of the Code of Conduct Exemption Evaluation will be included in the Application and Applicant Evaluation Reports, as described in Section 1.2.13 Publication of Application and Applicant Evaluation Reports.

If an application passes the Code of Conduct Eligibility Evaluation, an exemption to the Code of Conduct will be granted.

If an application does not successfully complete the Code of Conduct Exemption Evaluation, the application may continue with Specification 9 remaining in place.

7.4.6 Challenges and Extended Evaluation for Code of Conduct Exemption Evaluation

Applicants will have the ability to resubmit the required documentation if the initial submission of such documentation is non-compliant. Because of this, extended evaluation or a challenge mechanism is not applicable for this evaluation.

7.5 Geographic Names

Applicants must carefully consider the interests of governments or public authorities concerning Geographic Names. The following sections outline the requirements and procedures that ICANN will follow during the evaluation process. An applicant should review these requirements even if it does not believe its intended gTLD string qualifies as a Geographic Name. All applied-for gTLD strings and their allocatable variant strings will be reviewed according to the requirements in this section, regardless of whether the application indicates it is for a Geographic Name.

The processing of Geographic Names comprises:

  • Geographic Names Identification: a string-level check which is part of String Evaluation.

  • Geographic Names Review: verification and substantive review of application responses for strings determined to be geographic. This review takes place during the application evaluation phase.

Additionally, an applicant for a Geographic Name string can apply for its allocatable variant strings. In such cases, all allocatable variant strings must adhere to the same application requirements and evaluation criteria as the associated primary Geographic Name string. Specifically, the same documentation requirements apply. See Section 3.1.9 Internationalized Domain Names.

7.5.1 Treatment of Country or Territory Names

Applications for strings that are country or territory names will not be approved.49 A string is considered a country or territory name if it meets any of the following criteria:

  1. It is an alpha-3 code listed in the ISO 3166-1 standard.50

  2. It is a long-form name listed in the ISO 3166-1 standard, or a translation of the long-form name in any language.

  3. It is a short-form name listed in the ISO 3166-1 standard, or a translation of the short-form name in any language.

  4. It is the short- or long-form name associated with a code that has been designated as “exceptionally reserved” by the ISO 3166 Maintenance Agency.

  5. It is a separable component of a country or territory name designated on the “Separable Country and Territory Names List,” or is a translation of a name appearing on the list, in any language. See Appendix 2 Materials related to Geographic Names.

  6. Permutations and transpositions of the following strings are reserved and unavailable for delegation:

  1. Long-form names listed in the ISO 3166-1 standard.

  2. Short-form names listed in the ISO 3166-1 standard.

  3. Short- or long-form names associated with a code that has been designated as “exceptionally reserved” by the ISO 3166 Maintenance Agency.

  4. Separable component of a country or territory name designated on the “Separable Country and Territory Names List, or is a translation of a name appearing on the list, in any language.”

Strings resulting from permutations and transpositions of alpha-3 codes listed in the ISO 3166-1 standard are available for delegation, unless the strings resulting from permutations and transpositions are themselves on that list.51

  1. It is a name by which a country is commonly known, as demonstrated by evidence that the country is recognized by that name by an intergovernmental or treaty organization.

7.5.2 Geographic Names Requiring Government or Public Authority Documentation

Certain types of applied-for strings, including their allocatable variant strings, are considered Geographic Names and must be accompanied by documentation of support or non-objection from the relevant governments or public authorities. These types are:

  1. Strings that represent, in any language, the capital city name of any country or territory listed in the ISO 3166-1 standard.

  2. City names where the applicant declares that it intends to use the gTLD for purposes associated with the city name.

City names can present challenges because they may also be generic terms or brand names, and they are often not unique. Unlike other types of Geographic Names, city names do not have established lists for objective references during evaluation. Thus, city names are not universally protected. However, the process does provide a means for cities and applicants to work together where desired.

A city name application will be subject to the Geographic Names requirements (that is, will require documentation of support or non-objection from the relevant governments or public authorities) if:

  1. It is clear from applicant statements within the application that the applicant will use the TLD primarily for purposes associated with the city name; and

  2. The applied-for string is a city name as listed on official city documents.52

  1. Strings that are exact matches of sub-national place names, such as counties, provinces, or states, listed in the ISO 3166-2 standard.

  2. Strings listed as UNESCO regions53 or appearing on the Geographic Regions section of the “Standard country or area codes for statistical use (M49)”.54

Translations of regions included on the list mentioned above will be limited to the languages specified on that list. Region names that do not conform to the framework of DNS permissible characters will be converted into DNS labels that contain only letters, digits, and hyphens as noted in the Root Zone Label Generation Rules (RZ-LGR).55

For strings on these lists, documentation of support or non-objection will be required from at least 60% of the respective national governments in the region, with no more than one written objection to the application from relevant governments in the region or public authorities associated with the continent or the region.

When the 60% rule is applied and regions are common to both lists, the regional composition contained in the “Standard country or area codes for statistical use (M49)” takes precedence.

An applied-for gTLD string that falls into any of the types 1 through 4 listed above is considered to represent a Geographic Name. In cases of uncertainty, it is advisable for the applicant to consult with relevant governments and public authorities to enlist their support or non-objection prior to submission of the application. This proactive approach can help prevent possible objections and clarify any ambiguities concerning the string and applicable requirements.

Strings that include but do not exactly match a Geographic Name as defined in this section will not be considered Geographic Names. Therefore, they will not require documentation of government support or non-objection during the evaluation process.

For each application, the Geographic Names Panel will determine which governments or public authorities are relevant based on the inputs of the applicant, governments, and its own research and analysis. If there is more than one relevant government or public authority for the applied-for gTLD string, the applicant must provide documentation of support or non-objection from all the relevant governments or public authorities. It is anticipated that this may apply to the case of a sub-national place name.

It is the applicant’s responsibility to:

  • Identify whether its applied-for gTLD string falls into any of the above categories.

  • Identify and consult with the relevant governments or public authorities.

  • Identify which level of government support is required.

Note: The level of government and which administrative agency is needed for the filing of letters of support or non-objection is a matter for each national administration to determine. Applicants should consult within the relevant jurisdiction to determine the appropriate level of support.

The requirement to include documentation of support or non-objection for certain applications does not preclude or exempt applications from being the subject of objections on community grounds (see Section 4.5.1.4 Ground for Objection: Community). Applications may still be rejected if objections asserting substantial opposition from the targeted community are successful.

7.5.2.1 Documentation Requirements

The documentation of support or non-objection should include a signed letter from the relevant government(s) or public authority(ies). Recognizing that this will differ across jurisdictions, the letter could be signed by the minister responsible for domain name administration, ICT, foreign affairs, or the Office of the Prime Minister or President of the relevant jurisdiction or, alternatively, a senior representative of the agency or department responsible for domain name administration, ICT, foreign affairs, or the Office of the Prime Minister. To assist in identifying the relevant government(s) or public authority(ies) for a potential Geographic Name, the applicant may wish to consult with the relevant Governmental Advisory Committee (GAC) representative.56

The letter must clearly express the government’s or public authority’s support for or non-objection to the application and demonstrate the government’s or public authority’s understanding of the string being requested and its intended use.

The letter should also demonstrate the government’s or public authority’s understanding that the string is being sought through the gTLD application process and that the applicant is willing to accept the conditions under which the string will be available, that is, entry into a Registry Agreement with ICANN requiring compliance with consensus policies and payment of fees. See Section 1.2.16 Post Contracting and Section 2.10 Fundamental Obligations of Registry Operators to Registrars for a discussion of the obligations of a gTLD registry operator.

A sample letter of support or non-objection from a government entity/public authority is available in Appendix 2 Materials related to Geographic Names.

Applicants and governments may conduct discussions concerning government support or non-objection for an application at any time. Applicants are encouraged to begin such discussions at the earliest possible stage, enabling governments to follow the processes that may be necessary to consider, approve, and generate a letter of support or non-objection. If the letter of support or non-objection is dated more than four months from the opening of the New gTLD Program application submission period, a fresh letter of support or non-objection will be required. However, applicants should provide contact information for a designated person in case the Geographic Names Panel (GNP) needs clarification or has questions.

A government or public authority is under no obligation to provide documentation of support or non-objection in response to a request by an applicant. If support or non-objection is withdrawn during the application process, the application will fail the Geographic Names Review.

Applicants should be aware that ICANN has committed to governments57 that, in the event of a dispute between a government (or public authority) and an applicant or, after delegation, a registry operator that submitted documentation of support from that government or public authority, ICANN will comply with a legally binding order from a court in the jurisdiction of the government or public authority that has given support to an application. If support is withdrawn through a legally binding court order, the applicant or registry operator will no longer have the necessary documentation, and the applicant will either not proceed in the respective next steps in the application process, or, should this occur after delegation, the Registry Transition Processes58 referred to in the Registry Agreement will be followed.

7.5.3 Processing of Geographic Names

7.5.3.1 Geographic Names Identification

As part of the Geographic Names Identification, the Geographic Names Panel will review all applied-for strings to identify which strings may be considered Geographic Names. This process is distinct from and occurs before the more substantive verification process conducted during the Geographic Names Review, which occurs as part of Application (see Module 7) and Applicant Evaluation (see Module 6).

City names that do not fall under the categories defined in Sections 1, 3, and 4 of Geographic Names Requiring Government or Public Authority Documentation (see Section 7.5.2) will not be classified as Geographic Names during the Geographic Names Identification. However, if the applicant indicates an intent to use the applied-for string as a city name, as described in Section 2 of Geographic Names Requiring Government or Public Authority Documentation (see Section 7.5.2), the application will be evaluated by the Geographic Names Panel during the Application and Applicant Evaluation phase. This evaluation will include an assessment of the intended purpose and any required documentation.

7.5.3.2 Geographic Names Review

A Geographic Names Panel (GNP) will determine whether each applied-for gTLD string represents a Geographic Name, and verify the relevance and authenticity of the supporting documentation where necessary.

The GNP will review all applications received, not only those where the applicant has noted its applied-for gTLD string as a Geographic Name. For any application where the GNP determines that the applied-for gTLD string is a country or territory name (as defined in this module), the application will not pass the Geographic Names Review and will be denied. No additional reviews will be available.

For any application where the GNP determines that the applied-for gTLD string is not a Geographic Name requiring government support or non-objection (as described in this module), the application will pass the Geographic Names Review with no additional steps or fees required.

For any application where the GNP determines that the applied-for gTLD string is a Geographic Name requiring government support or non-objection, the GNP will confirm 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. ICANN may confirm the authenticity of the communication by consulting with the relevant diplomatic authorities or members of ICANN’s Governmental Advisory Committee for the government or public authority concerned on the competent authority and appropriate point of contact within their administration for communications.

The GNP may communicate with the signing entity of the letter to confirm its intent and its understanding of the terms on which the support or non-objection for an application is given.

7.5.3.2.1 Extended Evaluation for Geographic Names Review

A Geographic Names Review will qualify for Extended Evaluation in the following instances:

  • Issues with Documentation Provided: In cases where an applicant has not provided the required documentation, the applicant will be contacted and notified of the requirement, and given a limited time frame to provide the documentation. If the applicant is able to provide the documentation before the close of the evaluation period, and the documentation is found to meet the requirements, the applicant will pass the Geographic Names Review. If not, the applicant may elect Extended Evaluation where it will have additional time to obtain the required documentation; however, if the applicant has not produced the required documentation by the required date (at least 90 days from the date of notice), the applicant will not have additional time or opportunities in the current application round to do so. The applicant may reapply in subsequent application rounds, if desired, subject to the fees and requirements of the specific application rounds. See Module 6 Applicant Evaluation Procedures and Module 7 String and Application Evaluation Procedures on Evaluation Challenges for more information.

  • Conflicting Support or Non-Objection for the Same Geographic Name: As noted in Section 5.5 Contention Resolution for Geographic Names Applications, in the event that there is more than one application for a string that represents the same Geographic Name and has received documentation of support or non-objection from different government or public authorities, as determined by the Geographic Names Panel, these applications will also undergo Extended Evaluation. If, during Extended Evaluation, the Geographic Names Panel is satisfied that the supporting authorities of all relevant applications meet the required criteria, and agree that these applications can proceed to contention resolution, then they will either proceed to auction or to CPE, if one of the applications is a Community Application and elects to undergo CPE.

7.6 Variant String Evaluation

A variant string is considered the "same" as the main applied-for gTLD string or an existing gTLD ("primary string") by the script community as defined in the Root Zone Label Generation Rules (RZ-LGR).59 The set of rules in the RZ-LGR determines valid top-level domains and their variant strings.60 An applicant seeking one or more allocatable variant strings of an applied-for primary IDN or existing gTLD must provide justification for the necessity of each variant string. This justification will be evaluated by a panel using a general standard of reasonableness based on the following criteria, in the context of the applied-for primary IDN gTLD or existing gTLD:

  1. The meaning or intended meaning (for non-dictionary words) of each of the applied-for variant strings is consistent, as demonstrated by sources provided by the applicant.

  2. The variant string is recognized as equivalent by the intended user community.

  3. The benefits and the user communities who will gain from the introduction of the applied-for variant string.

  4. Steps the applicant will take to minimize the operational and management complexities of the variant gTLDs and resulting variant domain names that impact registrars, resellers, or registrants.

Commitments made by an applicant to minimize the noted operational and management complexities will form the basis of contractual requirements to be included in the applicable Registry Agreement.

The applicant must meet each criterion for each applied-for variant string to proceed in the Program. The evaluation outcome of any one applied-for variant string will not impact the evaluation outcome of a primary applied-for IDN or any other applied-for variant string in the application.

The ability to manage the applied-for variant strings along with the applied-for primary IDN or the existing gTLD will be evaluated from both a technical and operational perspective, as described in the RSP Handbook.61

7.6.1 Additional Application Requirements for Variant Strings

An applied-for variant string will be subject to the same application requirements and evaluation criteria as the associated primary applied-for IDN or existing gTLD. Specifically, the same documentation requirements apply to both the primary applied-for IDN and its applied-for variant strings. For purposes of clarity, an applied-for primary string and its applied-for variant strings will be evaluated together as a set but will require relevant documentation for each variant string, as needed.

With respect to the following three specialized application types:

  • Applicants for community IDNs and their variant strings must submit the same endorsement for applied-for variant strings as needed for the primary IDN. If a community IDN is in contention (see Section 5.2 String Contention and Contention Resolution Procedures) and opts to participate in Community Priority Evaluation (CPE), then the community IDN and their applied-for variant strings will be evaluated together as a set (see Section 5.4 Community Priority Evaluation).

  • An applicant for a Geographic Name IDN and its variant strings must submit documentation of support or non-objection to its applied-for primary string and applied-for variant strings from relevant governments or public authorities. That is, the requisite documentation of support or non-objection should reference both the applied-for IDN and its applied-for variant strings. See Section 7.5 Geographic Names.

  • An applicant for an IDN applying as a .Brand and its variant strings is required to submit proof that its applied-for primary string and applied-for variant strings are identical to registered trademarks owned and used by the applicant. That is, any applied-for variant string must also show proof that it is identical to registered trademarks owned and used by the applicant. See Section 7.3 .Brand TLD Eligibility Evaluation.

7.6.2 Application for Variant Strings of Reserved Names List

When a Reserved Name is the primary string, only the organization associated with that Reserved Name (see Section 7.2.2 Reserved Names) is allowed to apply for its variant strings at the top level. Although the variant string does not need to be a Reserved Name, it is generated as a variant string of the Reserved Name using the RZ-LGR. An application for variant strings of a Reserved Name cannot precede an application for the Reserved Name, which serves as the primary string for generating the variant strings.

7.6.3 Additional Dependence of Variant Strings

All variant strings depend on their primary IDN for application evaluation. If a primary applied-for IDN is disqualified for any reason, as described in this section or other relevant sections of the Guidebook, then all the associated variant strings will also be disqualified. In such cases, the entire application will not be allowed to proceed.

However, if any applied-for variant strings are disqualified and not able to proceed, then the applicant must file an Application Change Request (ACR) to remove the disqualified applied-for variant string in order for the application to proceed. If the ACR is successful, the corresponding applied-for primary IDN and any remaining applied-for variant strings that are not disqualified will still be able to proceed.

7.7 Name Collision

The delegation of almost any new gTLD carries some risk of Name Collision. Name Collision refers to the situation in which a resource name that is intended to be resolved in one naming system62 is inadvertently resolved in a different naming system, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient.63

In order to assess and mitigate the risk for name collisions between the global DNS and other naming systems, ICANN has implemented the Name Collision Risk Management framework, following recommendations from the Name Collision Analysis Project Study Two Report,64 as directed by the ICANN Board on 7 September 2024.65

All applied-for gTLD strings must be assessed in this framework before being approved for contracting and delegation. This section describes this framework, and the procedures that will be used to assess and, if necessary, mitigate any Name Collision risks associated with such strings.

7.7.1 Applicant Access to Longitudinal Risk Data

Before the opening of the application submission period, ICANN will publish datasets related to all strings above a certain threshold of query volume that may help applicants to assess the risk of Name Collision.

The metrics for an applied-for string are only one of several factors, both quantitative and qualitative in nature, that will be considered when assessing the risk associated with that string.

Out of the approximately 1,400 unique strings that were applied for during the last round, only three (.CORP, .HOME, and .MAIL) were assessed to be high-risk.66 Nevertheless, applicants should not assume that if the datasets indicate a low volume of Name Collision occurrences that the string will be assessed as safe to be delegated.

7.7.2 Name Collision Initial Assessment

Each applied-for string and any allocatable variant strings will undergo the Name Collision Initial Assessment using relevant data sets that can be procured from, for example, root server logs, and DNS recursive server logs, using both volume and diversity of queries, origins, query names (labels), and query types; Identifier Technologies Health Indicators (ITHI)67 data sets; and qualitative evidence that can help deduce the severity of harm. The purpose of this assessment, which will be conducted per the Name Collision Initial Assessment Operating Procedure,68 is to preliminarily identify high-risk strings.

The Initial Assessment will take place following the String Confirmation Day (Section 3.6), and will be overseen by the Technical Review Team (TRT). ICANN will publish an Initial Assessment report describing the assessment, its methodology, and findings, once completed. A Public Comment period will be carried out for the report to allow the community to provide feedback on the methodology and findings.

7.7.3 Temporary Delegation and Final Assessment

Strings (including variant strings) that are not identified as high-risk during the Name Collision Initial Assessment (Section 7.7.2) will be queued for Temporary Delegation. Temporary Delegation will start once the Initial Assessment has been concluded, even if other evaluations that are part of String Evaluation are still being performed. The prioritization of Temporary Delegation will be determined based on the application’s assigned priority number.69 The duration of Temporary Delegation will be outlined in the Name Collision Temporary Delegation Operating Procedure.70 The conclusion of Temporary Delegation is not necessary for other evaluations or contention resolution. However, an application will be able to proceed to contracting only when Temporary Delegation is concluded and the Mitigation Plan has been implemented (if applicable).

The rate at which strings will be temporarily delegated will be limited to ensure that the number of TLDs delegated in the DNS root zone does not increase by more than approximately five percent per month. It is expected that this rate limit corresponds to roughly 75 Temporary Delegations per month initially and will increase as more new gTLDs are temporarily delegated. However, as permanent delegations take precedence over Temporary Delegations, this number may vary from month to month.

During Temporary Delegation, the applied-for gTLD string will be delegated to DNS nameservers managed by ICANN in order to collect data about the volume and nature of DNS traffic for that string. Four different assessment methods for notification and data generation will be used during Temporary Delegation. These are outlined in the Appendix 2 of the Name Collision Analysis Project Study Two Report and are named: No Interruption (NI); Controlled Interruption (CI); Visible Interruption (VI); and Visible Interruption and Notification (VIN). The assessment will be overseen by the TRT, which consists of internal experts from relevant ICANN departments. The TRT will determine on a case-by-case basis which method or methods will be used for each assessment.

The TRT will evaluate the data collected during Temporary Delegation, which includes DNS queries to TLD servers, diversity of queries, origins, query names (labels), query types, etc., as well as data collected using the assessment methods, to determine whether the string will be:

  1. Designated as high-risk, in which case the string will be immediately removed from the root zone.

  2. Eligible to proceed with the remainder of the application processing.

Irrespective of the outcome of Temporary Delegation, the TRT will produce a Temporary Delegation report outlining the findings, which will be published for applicants and other interested parties to review.

7.7.4 The Collision String List

ICANN will maintain a Collision String List, which is a list of strings which ICANN has determined to present a high risk of Name Collision.

An applied-for string will be added to the Collision String List if (1) the string has been identified as high-risk in the Name Collision Initial Assessment, or (2) the string has been identified as high-risk during Temporary Delegation.

7.7.5 Name Collision High-Risk Mitigation Plan Evaluation

The applicant for a string on the Collision String List that has cleared contention may amend its application to add a High-Risk String Mitigation Plan, which will then be evaluated. This evaluation will be conducted per the Name Collision High-Risk Mitigation Plan Evaluation Operating Procedure71 and is subject to an additional fee. See Section 3.3 Fees and Payments.

Applicants must submit an Application Change Request to add a Mitigation Plan within 90 days (extendable upon reasonable request up to 180 days) of (a) the designation of the string as High Risk or, if in contention, (b) contention resolution. If the Application Change Request is not submitted within this time frame, the application status will move to Terminated. See Section 3.9 Application Statuses.

The applicant will be provided with relevant data generated during the Initial Assessment or Temporary Delegation of the string to assist in developing the Mitigation Plan, subject to applicable data protection requirements. In cases where the data includes personal data and where technical safeguards, such as anonymization or aggregation, cannot be effectively applied, ICANN may request to enter into a Data Processing Agreement (DPA) with the applicant.

The Mitigation Plan submitted by the applicant must contain at minimum the following:

  1. A summary of the findings from the Initial Assessment, and, if applicable, of the Technical Review Team’s findings during Temporary Delegation.

  2. A Root Cause Analysis and any other relevant evidence, which identifies the underlying reasons why Name Collisions may occur for the string.

  3. A Mitigation Plan, which outlines the specific preventative and corrective actions the applicant will take to mitigate the risk of Name Collisions, including any communication activities with affected end-users. Each mitigation action must have a specific time frame for implementation. The total time frame must not exceed two years.

The Mitigation Plan will be evaluated by a panel of technical experts, which may advise the applicant on possible improvements to it. In the event that amendments are required, a further 90 days will be allowed for such amendments. The evaluation will determine whether or not the plan (a) correctly identifies the root cause of the collisions and (b) has a high probability of being effective.

ICANN will publish the Mitigation Plan and the results of the Mitigation Plan Evaluation for comment. The panel will review any comments received, and take them into consideration, before making its final determination. Within the Mitigation Plan, applicants may identify sections that contain information which, if published, could undermine the effectiveness of the plan, such as where it might allow a malicious actor to interfere with mitigations, and mark these sections for redaction. If the panel agrees, the marked sections will be redacted before publication.

If the Mitigation Plan contemplates mitigation activities that take place before the delegation of the string, then the application will not proceed until those activities have taken place, and their effectiveness has been confirmed by the Evaluation Panel using the same criteria used during the Initial Assessment.

In cases where the Evaluation Panel determines that a mitigation measure must, for technical reasons, be implemented after the string is delegated for operation by the registry operator (after evaluation has been finalized), for example, if the Name Collision issues are limited to a second-level name that the registry agrees to never delegate, the application may be allowed to proceed with the remainder of the application processing as long as the applicant agrees to add the applicable requirements from the Mitigation Plan to its Registry Agreement.

If the Evaluation Panel finds that the Mitigation Plan (a) does not correctly identify the root cause of the collisions or (b) does not have a high probability of being effective, the application will not be allowed to proceed, and the application status will move to Terminated.

7.7.5.1 Challenging the Mitigation Plan Evaluation

The applicant will be given the opportunity to challenge the outcome of a Mitigation Plan Evaluation with respect to its own application if it believes the panel has made a factual or procedural error when it determined that the Mitigation Plan (a) does not correctly identify the root cause of the collisions or (b) does not have a high probability of being effective. To initiate an Evaluation Challenge proceeding, the applicant must file a challenge within 21 days from the date of transmission of the evaluation determination. A Challenge Panel, consisting of the same individuals responsible for the initial plan evaluation, shall conduct the challenge review.

The Evaluation Challenge will be assessed under a “clearly erroneous” standard of review. Specifically, the Challenge Panel must accept the Evaluation Panel's Determination unless the Evaluation Panel: (1) failed to follow the appropriate procedures, or (2) failed to consider/solicit necessary material evidence or information.

The deadline for filing a challenge will be within 21 days from the date the applicant receives notice of the evaluation determination it seeks to challenge. The Challenge Panel will communicate the result of the Challenge Proceeding within 30 days of an applicant filing such a challenge.

If the Challenge Panel finds a factual or procedural error, the Mitigation Plan will be reevaluated. The Evaluation panel will conduct the re-evaluation and provide the result to ICANN. ICANN will post the results and provide a 30-day comment period. After the comment period has ended, ICANN will consider all available information and take a final decision on whether to accept or reject the Mitigation Plan. If the plan is rejected, the application status will move to Terminated.

If the Challenge Panel does not find a factual or procedural error with the initial evaluation of the Mitigation Plan, the application will not be allowed to proceed and the application status will be moved to Terminated.

7.7.6 Interaction with Variant Strings

All applied-for primary strings, including the applied-for allocatable variant strings, will be assessed for Name Collision risk through the Initial Assessment and Temporary Delegation processes outlined above.

If either a primary string or allocatable variant string is found to be high-risk, then the application cannot proceed until the Mitigation Plan Evaluation process has been carried out. However, in the case of an allocatable variant string, the application may be amended to remove that string, allowing the amended application to proceed. Removal of an allocatable variant string may occur at any time as long as the application status has not been moved to Terminated.

7.8 Public Interest Commitments, Registry Voluntary Commitments, and Community Registration Policies

ICANN’s Mission is to ensure the stable and secure operation of the Internet’s unique identifier systems.72 The New gTLD Program supports this with many built-in protections, including robust evaluation of applied-for gTLD strings, applications, and operators, and enforcement of compliance with the Registry Agreement.

Public Interest Commitments (PICs), specifically the Mandatory PICs (see Section 7.8.1) and Safeguard PICs (see Section 7.8.2), are one important protection built into the New gTLD Program. Those PICs are binding Registry Agreement commitments in Specification 11, and ICANN enforces compliance with them. Mandatory PICs and Safeguard PICs are uniform across the relevant Registry Agreements, and were implemented in response to the Governmental Advisory Committee (GAC) concerns about applications in the 2012 application round. The primary issues addressed include consumer protection, intellectual property rights, and regulated market sectors such as financial, health, and charities.73

In addition to PICs, an applicant will be permitted to propose one or more Registry Voluntary Commitments (RVCs) (see Section 7.8.3) to provide additional safeguards with regard to the operation of an applied-for gTLD string. An applicant may propose an RVC to address concerns that are not already addressed by Mandatory or Safeguard PICs or via other means. As set out in further detail in Section 7.8.3 Registry Voluntary Commitments, proposed RVCs are subject to a separate evaluation process, namely the Registry Commitments Evaluation (RCE). ICANN will only approve a proposed RVC if: (1) the RVC meets the RCE criteria (see Section 7.8.3.3); and (2) the applicant and ICANN each agree that the proposed RVC, if included in the Registry Agreement, would be enforceable under the ICANN Bylaws and as a practicable matter. As with PICs, RVCs (once approved and incorporated into the Registry Agreement) are binding commitments in Base Registry Agreement Specification 11.74

Both PICs and RVCs are subject to the Public Interest Commitments Dispute Resolution Procedure (PICDRP).75

As detailed in the Section 7.1 String and Application Types, an applicant may choose to designate an applied-for gTLD string as a Community gTLD. If the applicant identifies an applied-for gTLD string as a Community gTLD, it must propose Registry Agreement Community Registration Policies (see Section 7.8.4) for inclusion in the applicable Registry Agreement to be evaluated by ICANN by applying the RCE criteria (see Section 7.8.3.3).

7.8.1 Mandatory Public Interest Commitments

Mandatory PICs are included in every Registry Agreement. Mandatory PICs require each registry operator to implement measures to protect gTLD registrants and Internet users more broadly, and include obligations related to: mitigation of abusive activity; security checks; and transparency in operation. The Mandatory PICs are included in Specification 11 Section 3(a)-(d) of the Base Registry Agreement (see Appendix 4), namely:

  1. Registry Operator will include a provision in its Registry-Registrar Agreement that requires registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.

  2. Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate DNS Abuse. Registry Operator will maintain statistical reports on identified DNS Abuse and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.76

  3. Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and nondiscrimination by establishing, publishing and adhering to clear registration policies.

  4. Registry Operator of a “Generic String” TLD may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Base Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others.

For more information about Generic Strings, see Section 3.1.7 Closed Generics/Exclusive Generic Strings.

7.8.2 Safeguard Public Interest Commitments

Safeguard PICs are provisions required in certain Registry Agreements, in addition to the Mandatory PICs included in all Registry Agreements.

ICANN classifies gTLDs needing Safeguard PICs into four risk-based groups:

  • Regulated Sectors/Open Entry Requirements: Strings invoking consumer trust but with heightened risks.

  • Highly Regulated Sectors/Closed Entry Requirements: Strings associated with industries requiring licensing or accreditation.

  • Potential for Cyber Bullying/Harassment: Strings that could facilitate harassment.

  • Inherently Governmental Functions: Strings associated with government domains.

See more detailed information and examples listed in the table under Section 7.8.2.2 Applicable Safeguard PICs by String Category.

If ICANN determines during evaluation that an applied-for gTLD string falls into one or more of the categories set out in Section 7.8.2.2 Applicable Safeguard PICs by String Category, the applicable Safeguard PICs (see Section 7.8.2.3) must be included in Specification 11 of the applicable Base Registry Agreement without modification.77

Safeguard PICs were developed and implemented in response to the GAC Consensus Advice in the ICANN46 Beijing Communiqué78 and subsequent ICANN Board Resolution79 during the 2012 Round of the New gTLD Program.80

7.8.2.1 String Group Determination

In the application, the applicant must answer questions to assess which Safeguard PICs, if any, would be required in the Registry Agreement (see Question Set 10 Safeguard Assessment/Mission and Purpose in Appendix 1 Application Questions). The applicant’s responses will be published with the application.

At the closure of an application comment period, ICANN will determine whether or not each applied-for gTLD string falls into one of the four Safeguard PIC groups. This determination concludes the evaluation and serves as input into the contracting procedure. It cannot be challenged under Extended Evaluation and Evaluation Challenges (Section 1.2.14), as it does not have an impact on the application’s progression.

See Section 4.1 Application Comments for more information about application comment periods.

7.8.2.2 Applicable Safeguard PICs by String Category

ICANN will use the framework below to determine whether an applied-for gTLD string requires Safeguard PICs, and if so, which Safeguard PICs apply. The framework identifies the four string groups established in response to the GAC Consensus Advice in the ICANN46 Beijing Communiqué and provides description and relevant examples.81 ICANN will apply Safeguard PICs to applied-for gTLD strings that are identified as falling within the groups of strings set out in the GAC’s ICANN46 Communiqué.

The framework identifies which of the ten Safeguard PICs are applied to each of the four string categories.

Table 7-2: Safeguard PICs Framework
String Group No. String Group Description Required Safeguards
1 Regulated Sectors/Open Entry Requirements in Multiple Jurisdictions

  • String is likely to invoke a level of implied trust from consumers

  • String is likely to carry heightened risks of consumer harm

  • String is associated to a generally open sector, but may require limited registration

See the non-exhaustive list of strings identified by the GAC as falling within this group in the ICANN46 Beijing Communiqué.82

Examples: .kid, .degree, .audio, .town

 1-3
2 Highly-Regulated Sectors/Closed Entry Requirements in Multiple Jurisdictions

String is associated with an industry where licensing or accreditation is required by local, regional, or national governments. This typically involves an assessment of qualifications, regular inspections, and ongoing government oversight

See the non-exhaustive list of strings identified by the GAC as falling within this group in the ICANN46 Beijing Communiqué.83

Examples: .cash, .bet, .abogado, .earth, .care

 1-8
3 Potential for Cyber Bullying/Harassment

String’s implied or actual meaning could result in gTLD being used to facilitate harassment or cyberbullying

Example strings identified by the GAC as falling within this group in the ICANN46 Beijing Communiqué84: .fail, .gripe, .sucks, .wtf

 1-9
4 Inherently Governmental Functions

String is associated with a function that is inherently in the domain of government, such as military branches

Example strings identified by the GAC as falling within this group in the ICANN46 Beijing Communiqué85: .army, .navy, .airforce

 1-8 and 10

7.8.2.3 Safeguard PICs

The ten Safeguard PICs include requirements for registrants to comply with applicable laws, implement appropriate security measures, provide contact information, possess necessary credentials, and report material changes to credentials, among other obligations. The Safeguard PICs are outlined in the following table:

Table 7-2: Types of Safeguard PICs
Safeguard PIC Safeguard PIC Text
1 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision requiring registrants to comply with all applicable laws, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct), fair lending, debt collection, organic farming, disclosure of data, and financial disclosures.
2 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars at the time of registration to notify registrants of the requirement to comply with all applicable laws.
3 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision requiring that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law.
4 Registry Operator will proactively create a clear pathway for the creation of a working relationship with the relevant regulatory or industry self-regulatory bodies by publicizing a point of contact and inviting such bodies to establish a channel of communication, including for the purpose of facilitating the development of a strategy to mitigate the risks of fraudulent and other illegal activities.
5 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision requiring registrants to provide administrative contact information, which must be kept up-to-date, for the notification of complaints or reports of registration abuse, as well as the contact details of the relevant regulatory, or industry self-regulatory, bodies in their main place of business.
6 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision requiring a representation that the registrant possesses any necessary authorizations, charters, licenses and/or other related credentials for participation in the sector associated with the TLD string.
7 If Registry Operator receives a complaint expressing doubt with regard to the authenticity of licenses or credentials, Registry Operator should consult with relevant national supervisory authorities, or their equivalents regarding the authenticity.
8 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision requiring registrants to report any material changes to the validity of the registrants' authorizations, charters, licenses and/or other related credentials for participation in the sector associated with the TLD string in order to ensure they continue to conform to appropriate regulations and licensing requirements and generally conduct their activities in the interests of the consumers they serve.
9 Registry Operator will develop and publish registration policies to minimize the risk of cyber bullying and/or harassment.
10 Registry Operator will include a provision in its Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision requiring a representation that the registrant will take reasonable steps to avoid misrepresenting or falsely implying that the registrant or its business is affiliated with, sponsored or endorsed by one or more country's or government's military forces if such affiliation, sponsorship or endorsement does not exist.

7.8.3 Registry Voluntary Commitments

There may be circumstances in which the multitude of safeguards built into the application process and into the Registry Agreement, including the Mandatory and Safeguard PICs, do not completely address a specific issue with an application or proposed Registry Agreement. In these circumstances, an applicant may consider proposing an RVC to help resolve the potential issue.

An applicant’s decision to propose an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice (see explanation in Section 7.8.3.2.3.1 Situation 1: Commitments Made to Overcome Objections or GAC Consensus Advice). These commitments will be contractually binding if approved and included in the Registry Agreement. RVCs may vary, potentially increasing commitments related to the public interest or codifying stakeholder commitments. An RVC could also institute safeguards that may help overcome a third-party concern with an applied-for gTLD string or application. For example, applicants could propose RVCs in response to Objections, GAC Member Early Warnings or GAC Consensus Advice, application comments, or other issues that might otherwise negatively impact the application’s evaluation process. See Section 3.8 Application Change Requests and Module 4 Community Input, Objections and Appeals for further details about these topics.

An applicant may include a proposed RVC in its application or request to add one afterward via the Application Change Request process (see Section 3.8), which includes an application comment period and other conditions.

All proposed RVCs submitted with the application or as an Application Change Request will appear in the public application section, accessible on the New gTLD Program website86, and be open to the public for review and comment during the application comment period (see Section 4.1 Application Comments).

7.8.3.1 Factors to Consider Before Proposing an RVC

Before deciding to propose an RVC, applicants are encouraged to review ICANN’s Bylaws; relevant ICANN agreements, including but not limited to the Registry Agreement and the Registrar Accreditation Agreement (RAA); and the ICANN Consensus Policies and Temporary Policies. Applicants and any third parties that raise concerns about any applications should consider whether the pre-existing, standardized provisions could provide sufficient safeguards for the applied-for gTLD string, to avoid the need for the evaluation and implementation of a customized RVC.87

The ICANN community recommended that ICANN include the Mandatory PICs in each Registry Agreement and also include Safeguard PICs (where applicable) in Registry Agreements for strings identified during the evaluation process as falling within the four string groups set out in Section 7.8.2 Safeguard Public Interest Commitments. In some cases, it may be possible for an applicant that is not required to implement the Safeguard PICs to propose to use one or more of the approved Safeguard PICs as an RVC to resolve issues or concerns raised regarding an applied-for gTLD string or application.

In addition, an applicant should consider whether the performance of a proposed RVC requires the operation of an additional Registry Service.88 If so, the applicant shall engage its selected Registry Service Provider (RSP) to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN. If ICANN identifies a proposed RVC that requires the operation through an additional Registry Service, and such a Registry Service has not yet been approved for the applicant’s selected RSP, then the RSP must seek ICANN’s approval via the RSP Program before ICANN considers approving the proposed commitment as an RVC.89

Any proposed RVC that is incompatible with ICANN’s Bylaws, policies, and agreements will not be approved, as explained in Section 7.8.3.3 Registry Commitments Evaluation Criteria.

An applicant is encouraged to consider whether there are other means, separate from the Registry Agreement, that could help resolve the issues raised regarding the applied-for gTLD string or application. For example, an applicant may consider addressing the concerns, possibly in consultation with the third party that raised the concerns, by including relevant commitments in the applicant’s own registry policies, terms of use, or through a separate agreement between the applicant and the third party. Any such separate agreement shall not be enforced by ICANN, and any such third party shall not be a “third-party beneficiary” of the Registry Agreement with ICANN.90

7.8.3.2 Registry Commitments Evaluation

Each proposed RVC for each applied-for gTLD string (and its applied-for allocatable variant strings, if applicable) will be subject to ICANN evaluation and approval via the Registry Commitments Evaluation (RCE). The purpose of the RCE is to determine whether a proposed commitment meets all the evaluation criteria as set out in RCE Criteria (see Section 7.8.3.3) for inclusion in the Registry Agreement.

Each Community Registration Policy proposed for inclusion in the applicable Registry Agreement will also be subject to the Registry Commitments Evaluation (see Section 7.8.4 Community Registration Policies). See Section 7.8.3.5 Proposed RVC for Variant Strings for more information regarding this evaluation for variant strings.

In the application, applicants that wish to submit proposed RVCs and Community Registration Policies for inclusion in the Registry Agreement must answer a series of questions that are designed to facilitate ICANN’s evaluation (see Appendix 1 Application Questions).

An applicant that submits RVCs or Community Registration Policies is required to pay a fixed, one-time payment that covers the cost of the Registry Commitments Evaluation. For details on fees associated with the RCE, see Section 3.3.2 Conditional Evaluations.

7.8.3.2.1 Applicants Must Identify Purposes for Proposed RVC

The applicant must provide background information to explain why its proposed RVC is relevant, important, and necessary in support of the application. ICANN will conduct a completeness check for this requirement when the RVC is proposed by the applicant, prior to the Registry Commitments Evaluation. This information will help to provide context for the proposed RVC and, in certain cases, could be useful if adjustments to the terms of the RVC are needed to meet the aims of the proposed commitment while also meeting the criteria for an RVC to be included in the Registry Agreement, as explained in Section 7.8.3.3 Registry Commitments Evaluation Criteria.

For example, if a proposed RVC responds to a third-party objection, the applicant should identify the specific objection and objector, provide the relevant references or links to the objection, and offer other pertinent details. These details could include, but are not limited to, how the applicant constructed the proposed RVC to address the concern, whether the applicant consulted with the objector in the development of the proposed RVC, and the means and systems in place to ensure compliance with the RVC.

7.8.3.2.2 General Rule: Registry Commitments Evaluation of Proposed RVCs Does Not Impact Application Progression

In circumstances other than those identified in Section 7.8.3.2.3 Exception: Registry Commitments Evaluation of Proposed RVCs Impacts Application Progression, the Registry Commitments Evaluation of proposed RVCs will not impact the ability of the application to proceed. Outside of these exceptional circumstances, the Registry Commitments Evaluation has no impact on the evaluation of an applicant’s or application’s ability to proceed to contracting, but merely determines whether the proposed RVC meets the criteria for inclusion in the applicable Registry Agreement if the application advances.

The evaluation will not determine whether the proposed RVC successfully addresses third-party concerns. Although ICANN may consider application comments and other inputs and may consult third parties during the evaluation, it will not typically involve third parties in this evaluation.

Applicants intending to propose an RVC to resolve an objection or other third-party concern are encouraged to engage with the concerned party or parties first. If they can agree on an RVC that addresses the issue before submitting an Application Change Request, it may prevent ICANN from evaluating a proposed RVC that the third party believes does not adequately resolve the concern regarding the applied-for gTLD or application. If an applicant proposes an RVC during objection proceedings to resolve an objection or third-party concern, and that RVC is approved by ICANN, the objector or other third party must separately decide whether and how to continue pursuing their concerns.

For example, if an application proposes an RVC to address an objection during the “cooling off” period, once the Registry Commitments Evaluation concludes — either approving or rejecting the RVC — the objector can then decide whether to continue pursuing the objection. To give another example, an applicant might propose an RVC as an Application Change Request after receiving a GAC Member Early Warning to reduce the risk of later receiving GAC Consensus Advice that could hinder the application’s progress. In this case, the evaluation would not determine whether the proposed RVC would be likely to alleviate the concern raised in the GAC Member Early Warning, but approval of the RVC could inform GAC discussions on issuing Consensus Advice to the Board regarding the application or applied-for gTLD string.

If an applicant plans to propose an RVC as an Application Change Request to address a third-party concern, the applicant should keep in mind the relevant timelines and processes for objections, GAC Consensus Advice, GAC Member Early Warnings, application comments, etc., if it wants the RVC to be taken into account in those processes (see Module 4 Community Input, Objections, and Appeals). As noted above, all proposed RVCs that are submitted as an Application Change Request (see Section 3.8) are subject to an application comment period.

7.8.3.2.3 Exception: Registry Commitments Evaluation of Proposed RVCs Impacts Application Progression

The Registry Commitments Evaluation result for a proposed RVC can only impact the application’s progression in two scenarios. See Section 3.9 Application Statuses to learn what to expect when an application is deemed unable to proceed.

7.8.3.2.3.1 Situation 1: Commitments Made to Overcome Objections or GAC Consensus Advice

If an RVC is recognized by ICANN for resolving an objection or addressing GAC Consensus Advice, it will be subject to heightened restrictions during the application process and after contract execution.

Although the RVCs proposed in this circumstance are labeled as “voluntary”, ICANN recognizes that they are not solely proposed at the applicant’s own discretion but are conditions necessary for the application to proceed.

An RVC must be approved by ICANN via the Registry Commitments Evaluation to resolve an objection or address GAC Consensus Advice. Without such approval, the application cannot proceed.91 See Section 4.5.8.13 Objections and Registry Voluntary Commitments and Section 4.3.3 GAC Consensus Advice and Registry Voluntary Commitments.

Proposed RVCs to overcome objections or GAC Consensus Advice are open to the public for review and comment via an application comment period. If negotiations with ICANN lead to changes for approval, both the original proposal and the ICANN-approved versions will be published for comment. See more information in Section 3.8 Application Change Requests.

Due to the specific purpose these RVCs serve, applicants and registry operators generally will not, absent extraordinary circumstances, be able to materially change or remove these commitments once they are approved by ICANN. These commitments are expected to be included in a separate subsection of Specification 11 to make clear that they are subject to heightened restrictions. See Section 7.8.3.4 RVC Addition, Changes, and Removals.

7.8.3.2.3.2 Situation 2: Application Change Request Required Following Rejection of Proposed RVC

If an applicant proposes an RVC in its initial submission, and it does not pass the Registry Commitments Evaluation, the applicant must file an Application Change Request to modify or remove the proposed RVC for the application to proceed. The Application Change Request will be reviewed by ICANN according to the published criteria (see Section 3.8).

Absent extraordinary circumstances, if the applicant does not submit an Application Change Request within 30 days of notification that the proposed RVC did not pass the evaluation, the application will not be permitted to proceed.

7.8.3.2.4 Registry Commitments Evaluation Timing and Result Notification

Regarding the timing of Registry Commitments Evaluation for proposed RVCs under Situation 1: Commitments Made to Overcome Objections or GAC Consensus Advice (see Section 7.8.3.2.3.1) and proposed Community Registration Policies (see Section 7.8.4) submitted by Community Applicants participating in the Community Priority Evaluation (CPE), the Registry Commitments Evaluation will be conducted as soon as possible after ICANN has received the applicable fee. ICANN acknowledges the importance of conducting the RCE in a timely manner to ensure that dependent processes can proceed without delay.

In all other cases, the Registry Commitments Evaluation is expected to occur later in the application process, prior to contracting, after the evaluation fee is received by ICANN.

Absent extraordinary circumstances, the estimated timeline for RCE is 60 to 90 days.

ICANN will publish and regularly update the RCE results of all submitted RVCs and Community Registration Policies on the New gTLD Program website and notify the respective applicants of the outcomes.92

7.8.3.3 Registry Commitments Evaluation Criteria

ICANN will reject any proposed RVC that is not compatible with the ICANN Bylaws.93 See criterion 5 in the table below for details.

ICANN will evaluate each proposed RVC based on the following criteria, and approval depends on meeting all of them. Applicants should follow the associated guidance and consider each criterion’s relevance when preparing their RVC.

Each commitment in the Community Registration Policy (see Section 7.8.4) that is proposed for inclusion in the applicable Registry Agreement must also meet all of the Registry Commitments Evaluation criteria in order to be approved.

See instructions for Questions 150-155 in Question Set 7 Community gTLDs and Question Set 11 Registry Voluntary Commitments (RVCs) in Appendix 1 Application Questions for the detailed requirements that guide the drafting approach of proposed Community Registration Policies and Registry Voluntary Commitments that will be evaluated through the RCE.

As noted in Section 7.8.3.1 Factors to Consider Before Proposing an RVC, applicants may consider including certain commitments outside of the Registry Agreement, in vehicles such as the applicant’s own registry policies, terms of use, or through a separate agreement between the applicant and a third party. Any such commitment not proposed for inclusion in the Registry Agreement will not be subject to the Registry Commitments Evaluation.94

Table 7-3: RVC Evaluation Criteria
Criterion Description Guidance

  1. RVC must clearly state what commitments “must” be implemented.

 A proposed RVC must be a compulsory commitment or obligation and must clearly state what commitments the registry operator “must” implement, not what commitments the registry operator “may” or “might” implement.

  • Use definitive language: Avoid qualifiers, and express certainty when describing the proposed RVC. State what the applicant proposes that the registry operator “must” do.

  1. RVC must be clear, detailed, mutually understood between the applicant and ICANN, objective, and measurable.

 Each RVC must clearly state what the RVC requires the registry operator to do. This level of detail in the RVC is necessary to ensure that the RVC is enforceable as a practicable matter. The RVC must be clear, so that in the event of a contractual compliance issue, the registry operator’s actions can be measured against the objective language in the RVC to determine whether or not the registry operator complied with the RVC.

  • Be clear: Use simple and straightforward language that is easy to understand.

  • Be precise and specific: Avoid vague or ambiguous statements that could lead to misunderstanding.

  • Be detailed: Specify which entity will be responsible for implementing the RVC; describe the actions, steps or tasks required to implement the RVC; outline the specific actions that the registry operator must take to fulfill the RVC.

  • Consider registry operator’s internal compliance monitoring: Describe how the registry operator will monitor and assess its implementation of and compliance with the RVC.

  1. RVC must specify any applicable limitations.

 The applicant must provide details on whether, how, and why a proposed RVC is limited in time, duration, scope, or any other factors, if applicable.

  • Define any applicable limitations of the proposed RVC: For example, if an RVC is time-limited, it must state if it will apply for the lifetime of the gTLD, only during a specified launch period, or for some other defined period.

  1. RVC should95 not duplicate or be contrary to requirements under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies.

 An RVC should not duplicate obligations that would apply to the registry operator per the Registry Agreement, applicable ICANN Consensus Policies and Temporary Policies, or applicable law. An RVC will not be approved if it is contrary to applicable ICANN agreements and policies. The registry operator must be able to comply with the RVC while also complying with applicable ICANN agreements and policies. An RVC also must not prevent other parties’ (for example, registrars’) compliance with applicable ICANN agreements and policies.96 If the performance of a proposed RVC requires the operation of an additional Registry Service, such a Registry Service must be evaluated through the RSP Program and approved by ICANN before ICANN considers approving the proposed commitment as an RVC.

  • Avoid duplication: Before proposing an RVC, an applicant should carefully review provisions in the Registry Agreement, the Registrar Accreditation Agreement, as well as the ICANN Consensus Policies and Temporary Policies to see if there is already such an obligation. If so, the applicant should not propose the RVC.

  • Enhancements to contract or policy obligations: An RVC could enhance, supplement, or expand upon requirements in the Registry Agreement and other applicable obligations so long as the RVC is not contrary to those applicable obligations.

  • RVC must apply alongside other contract and policy requirements: An RVC cannot commit a registry operator to take actions that contradict requirements in the Registry Agreement or applicable ICANN Consensus Policies or Temporary Policies. An RVC must not commit a registry operator to include terms in its Registry-Registrar Agreements that would require the registrars to take actions in violation of the Registrar Accreditation Agreement, applicable ICANN Consensus Policies or Temporary Policies, or applicable law.

  1. RVC must be compatible with ICANN’s Bylaws.

 ICANN cannot approve an RVC that is incompatible with the ICANN Bylaws.

One area of particular focus under this criterion is whether a proposed RVC would restrict content or use of an applied-for gTLD string.97 If a proposed RVC would put ICANN in a position of enforcing a registry operator’s compliance with a restriction on content in the applicable gTLD, that proposed RVC will be rejected.98

“Content” is the substance of a message being delivered, whereas non-content-restrictive factors could include, but are not limited to, how and when content is delivered and by whom. Differentiating between content-restrictive commitments and non-content-restrictive commitments in the context of RVCs involves understanding the scope, focus, and impact of the commitments:

Scope: Non-content-restrictive commitments could focus on operational, procedural, and technical aspects of the domain name registration and management, rather than specific content within the gTLD.

Focus: Non-content-restrictive commitments could involve adherence to industry standards, registration eligibility requirements, and procedures that are not specific to content in the gTLD.

Impact: Non-content-restrictive commitments could influence how domain names are managed and the operational environment in which they exist.

7.8.3.4 RVC Additions, Changes, and Removals

If a proposed RVC is added or modified after the application submission date and before the applicable Registry Agreement is executed, it shall be subject to the Application Change Request process, which includes an application comment period for material changes as set out in Section 3.8 Application Change Requests. For different types of application comment periods for proposed RVCs, see Section 3.8.3 Application Change Request Types and Required Processes.

Absent extraordinary circumstances, the RVCs pursuant to Situation 1: Commitments Made to Overcome Objections or GAC Consensus Advice (see Section 7.8.3.2.3.1) may generally not be materially changed or removed prior to contract execution.

ICANN does not currently have a process for registry operators to request modification to RVCs in Registry Agreements that have been executed. ICANN may propose a process for the community to provide its input with respect to registry operators requesting modification to RVCs following contract execution.

7.8.3.5 Proposed RVC for Variant Strings

If an applicant seeks allocatable variant strings of an applied-for primary string and plans to propose an RVC with its application or as an Application Change Request, the proposed RVC must apply to both the primary and variant strings and undergo the same Registry Commitments Evaluation. This requirement also applies to the proposed Community Registration Policy for the applied-for primary and variant strings of a Community gTLD explained in Section 7.8.4 Community Registration Policies.

7.8.4 Community Registration Policies

Registry Agreement Community Registration Policies (Community Registration Policies) are Registry Agreement conditions that gTLD registry operators must impose upon registrants within Community gTLDs. When submitting an application for a Community gTLD (Community Application), applicants must propose Community Registration Policies for inclusion in the applicable Registry Agreements. At a minimum, these policies must cover registrant eligibility and naming selection.

As with proposed RVCs for inclusion in the Registry Agreement, a Community Registration Policy proposed by an applicant for inclusion in the applicable Registry Agreement must be evaluated pursuant to the RCE criteria (see Section 7.8.3.3). Its evaluation outcome will affect whether a Community Application can move forward. Specifically, an applicant must have approved Community Registration Policies as a prerequisite in order for its application to participate in the Community Priority Evaluation (CPE), an option only available to Community Applications to resolve contention.99 Nevertheless, approval is required not only for a Community Application to participate in the CPE, but also to move forward in the application process after the RCE. In other words, if there are no Community Registration Policies that can be approved by ICANN for inclusion in the Registry Agreement, the Community Application cannot advance, regardless of whether it is in contention or whether the applicant chooses to participate in the CPE.100

A Community Registration Policy meeting RCE criteria (see Section 7.8.3.3) will be included in the applicable Registry Agreement if the applied-for string proceeds to delegation. See instructions for Questions 150-155 in Question Set 7 Community gTLDs in Appendix 1 Application Questions for the detailed requirements that guide the drafting approach of proposed Community Registration Policies that will be evaluated through the RCE. As with PICs and RVCs, an approved Community Registration Policy will be subject to ICANN contractual compliance oversight. Community Registration Policies included in the Registry Agreement are subject to the Registration Restrictions Dispute Resolution Procedure (RRDRP) and the Community gTLD Change Requests Procedure.101

Furthermore, operators of Community gTLDs may implement any additional registration policies outside of the Registry Agreement that are desired, so long as the policies are not contrary to requirements under applicable ICANN agreements and policies.102

7.8.5 ICANN Enforcement

ICANN will enforce compliance with PICs, RVCs, and Community Registration Policies evaluated and approved pursuant to the RCE criteria (see Section 7.8.3.3) and included in the Registry Agreement as any other contractual obligations. The PICDRP may be used to address alleged complaints that a registry operator may not be complying with one or more of its PICs or RVCs. The RRDRP may be used to address circumstances in which the operator of a Community gTLD allegedly deviates from the Community Registration Policies outlined in the Registry Agreement. See Section 1.2.17 Dispute Resolution Procedures After Delegation for further details about the PICDRP and the RRDRP.

7.9 Registry Service Provider Review

ICANN will verify whether the applicant has selected one or more evaluated RSPs as part of its application. If not, Extended Evaluation is available for an applicant to provide the requested information regarding the chosen RSP(s). ICANN will also review the willingness of the RSP(s) to support the gTLD, including their capacity to support the gTLD with any additional Registry Services. See Section 3.1.10 Registry Service Provider Selection.

7.10 String Similarity Evaluation

The objective of the String Similarity Evaluation is to prevent user confusion and loss of confidence in the DNS resulting from delegation of visually similar strings. Strings or their variant strings must not be Visually Similar (defined below) to an existing top-level domain or its variant strings, or a Blocked Name or its variant strings as set out in more detail in Section 7.10.1 Scope of String Similarity Evaluation (see Section 7.2.1 Blocked Names). The variant strings are calculated using the applicable version of the Root Zone Label Generation Rules (see Section 3.1.8.3.1.1 Applicable RZ-LGR Version and Scripts and Languages Supported).103

An application is based on the primary applied-for string or existing gTLD. Each primary string is a member of and creates a variant-strings-set.104 An application may contain one or more strings from the same variant-strings-set (see Section 3.1.9 Internationalized Domain Names), based on the applicant’s choice and with other applicable constraints.105 For any application, the String Similarity Evaluation is conducted using all the strings in the variant-strings-set even if many of these strings are not being applied for by the applicant, as per the details below.

“Visually Similar” in this context means visually confusing strings, specifically “strings so visually similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.”106 The String Similarity Evaluation will be conducted by an independent String Similarity Evaluation Panel. If the panel finds applied-for strings or variant strings to be Visually Similar, they will be marked and excluded from proceeding or form contention sets. The String Similarity Evaluation that occurs during String Evaluation complements the string confusion objection process. See Section 4.5 Objections and Appeals.

7.10.1 Scope of String Similarity Evaluation

String Similarity Evaluation involves a preliminary comparison of each applied-for string and its variant strings to corresponding strings and variant strings in relevant categories. The evaluation is conducted using all the strings in the variant-strings-set, regardless of whether the applicant applies for them, as detailed below. The comparisons are done to determine whether the strings are visually similar to the extent that it creates a probability of user confusion107 following the String Similarity Evaluation Guidelines (see Section 7.10.2.3).

For each application, the primary string (if not already delegated) and all allocatable variant strings108 in its variant-strings-set will be compared with the following:109

  • Existing delegated gTLDs and all of their allocatable and blocked variant strings.

  • The gTLD strings that were applied for in the previous gTLD rounds and that are still in the process,110 and all of their allocatable and blocked variant strings.

  • Existing successfully evaluated111 or delegated112 ccTLDs and all of their allocatable and blocked variant strings.

  • Strings currently requested as IDN ccTLDs113 (see Section 7.10.3.3 Strings Similar to Successfully Evaluated or Delegated ccTLDs or Their Variant Strings) and all of their allocatable and blocked variant strings.

  • Other applied-for gTLD strings in the current application round and all of their allocatable and blocked variant strings.

  • A subset of Blocked Names114 and all of their allocatable and blocked variant strings.

  • All other two-letter ASCII strings115 and all of their allocatable and blocked variant strings.

In addition, for each application, all of its blocked variant strings in its variant-strings-set will be compared against the following:

  • Existing delegated gTLDs and all of their allocatable variant strings.

  • The strings that were applied for in previous rounds of the New gTLD Program and that are still in process,116 and all of their allocatable variant strings.

  • Existing successfully evaluated or delegated ccTLDs and all of their allocatable variant strings.

  • Strings currently requested as IDN ccTLDs (see Section 7.10.3.3 Strings Similar to Successfully Evaluated or Delegated ccTLDs or Their Variant Strings) and all of their allocatable variant strings.

  • Other applied-for strings in the current application round and all of their allocatable variant strings.

  • A subset of Blocked Names117 and all of their allocatable variant strings.

  • All other two-letter ASCII strings and all of their allocatable variant strings.

As an exception to the comparisons listed above, during the String Similarity Evaluation, the String Similarity Evaluation Panel may decide to omit some comparisons with the blocked variant strings. Any such decision must be based on the String Similarity Evaluation Guidelines that justify such an omission citing a low level of confusability between the scripts being compared.

The table below summarizes the comparisons the String Similarity Evaluation Panel will perform, based on the categories marked as “Yes.” As noted, the String Similarity Evaluation Panel may omit comparisons for gray shaded cells marked “Yes*” if it concludes the scripts are unlikely to be confused, following the String Similarity Evaluation Guidelines (Section 7.10.2.3). The comparisons listed as “No” will not be performed.

Table 7-4: Scope of Comparisons Performed by the String Similarity Evaluation Panel
Categories for Comparison The applied-for string
Primary string All allocatable variant string(s) All blocked variant string(s)

  • Existing gTLD

  • Applied-for string from previous round(s) of the New gTLD Program still in process

  • Existing ccTLD

  • Requested IDN ccTLD

  • Another applied-for string

  • Blocked Name

  • Any two-Character ASCII

 Primary String Yes Yes Yes*
All allocatable variant string(s) Yes Yes Yes*
All blocked variant string(s) Yes* Yes* No

*The String Similarity Evaluation Panel may omit comparisons for gray shaded cells marked “Yes*” if it concludes the scripts are unlikely to be confused, following the String Similarity Evaluation Guidelines.

7.10.2 Methodology of String Similarity Evaluation

7.10.2.1 Same Primary or Variant Strings

Both uppercase forms and lower case forms of ASCII letters are considered, and any permutation of the casing in a string may be used for String Similarity Evaluation, for example, “EXAMPLE”, “Example,” or “example.”

Applications from different applicants with strings from the same variant-strings-set will be marked as the same by the String Similarity Evaluation Panel.

7.10.2.2 Batching of Strings

If batching is required, the String Similarity Evaluation will be completed on all applied-for strings prior to the establishment of evaluation priority batches. For applications identified as part of a contention set, ICANN will put all the strings in the contention set in the same batch according to the highest priority string in that contention set.

7.10.2.3 String Similarity Evaluation Guidelines

The String Similarity Evaluation Panel will conduct the evaluation as per the String Similarity Evaluation Guidelines, which will be posted on the New gTLD Program website.

7.10.2.4 Process for String Similarity Evaluation Panel

The String Similarity Evaluation will be conducted by an independent String Similarity Evaluation Panel. All applied-for strings and their variants will be evaluated against other applied-for strings and their variants, existing gTLDs, and Blocked Names, as detailed in Section 7.10.1 Scope of the String Similarity Evaluation.

The String Similarity Evaluation Panel will conduct the String Similarity Evaluation in the following steps:

  1. Compile the lists of strings for comparison:

    1. Existing gTLDs

    2. Applied-for strings in previous rounds of the New gTLD Program and still in process

    3. Existing ccTLDs

    4. Requested IDN ccTLDs

    5. Other applied-for strings

    6. Blocked Names

    7. Two-character ASCII strings

  2. Consider all allocatable variant strings of the above strings using the RZ-LGR.

  3. Consider all blocked variant strings of the above strings using the RZ-LGR which are in the same script (mixed script strings for Kana and Han scripts as allowed by the RZ-LGR).

  4. Decide which blocked variant strings to omit from the evaluation, if any, and document the rationale for the decision. Any such decision by the panel must be based on the String Similarity Evaluation Guidelines (see Section 7.10.2.3 ) on the basis of a low level of confusability between the scripts of strings being compared.

  5. Identify strings in different applications but in the same variant-strings-set to determine contention sets caused by same strings or variant strings.

  6. Conduct the comparison of the strings to identify any sets of Visually Similar strings based on the String Similarity Evaluation Guidelines (see Section 7.10.2.3), and document the analysis. Visual similarity tools are not used as input for this process, but the String Similarity Evaluation Panel may use automation and data provided by the respective script community to make the manual comparison process efficient.

  7. Determine and document (along with rationale) the outcome of the String Similarity Evaluation.

7.10.3 Outcomes of String Similarity Evaluation

As noted above, the String Similarity Evaluation Panel will conduct the analysis and determine the String Similarity Evaluation outcomes. These outcomes, along with their rationale, will be based on similarity comparisons conducted for all applied-for gTLD strings (including their variant-strings-set), as per the details in this section. The possible outcomes are as follows:

  1. String Visually Similar to an existing gTLD or its variant strings.

  2. String Visually Similar to an applied-for string in previous rounds of the New gTLD Program and still in process or its variant strings.

  3. String Visually Similar to an existing ccTLD or its variant strings.

  4. String Visually Similar to a requested IDN ccTLD or its variant strings.

  5. String same as another applied-for string or its variant strings.

  6. String Visually Similar to another applied-for string or its variant strings.

  7. String Visually Similar to a Blocked Name or its variant strings.

  8. String Visually Similar to a two-character ASCII string or its variant strings.

  9. String not Visually Similar to any of these categories listed.

ICANN will publish the outcomes of the String Similarity Evaluation on the Evaluation Results Page of the New gTLD Program website.

All strings from a variant-strings-set, comprising the primary string and all of its allocatable and blocked variant strings, will share the same outcome of the String Similarity Evaluation:

  • If any applied-for string or any of its variant strings is not able to proceed or placed in a contention set due to Visual Similarity, then the applied-for string and all of its variant strings (that is, the entire variant-strings-set) will share the same outcome.

  • In cases when an application in a contention set prevails, it applies to the entire variant-strings-set, and all strings in the prevailing application can proceed to the next stage of the application process. See Section 5.2.2 String Contention Resolution.

7.10.3.1 Strings Visually Similar to Existing gTLDs or Their Variant Strings

If any applied-for string or any of its variant strings is found to be Visually Similar to any of the existing gTLDs or any of their variant strings, the application will not be able to proceed, except in the case stated below.

The exception occurs when the applied-for string is an allocatable variant of an existing gTLD, is part of the same variant-strings-set as the existing gTLD, the applied-for string is found to be Visually Similar to that existing gTLD or any of its variant strings, and the applicant is the same registry operator of that existing gTLD. In this case, the application can proceed with evaluation as a variant string.

7.10.3.2 Strings Visually Similar to Strings and Their Variants Still in Process from Previous Rounds of the New gTLD Program

If an applied-for primary string or any of its variant strings is Visually Similar to an applied-for primary string or any of its variant strings that have been held over from a previous application round and are still in progress, the newly submitted application will be put on hold until the outcome of the application from the previous round has been determined.

  • If the application from a previous round of the New gTLD Program successfully completes evaluation and is eligible for entry into a Base Registry Agreement, the entire variant-strings-set of the newly applied-for primary string is ineligible to proceed in the application process.

  • If the application from a previous round is withdrawn or fails evaluation, the newly submitted application is eligible to proceed to the next stage of the application process.

A new applicant is not allowed to apply for a string that is part of the same variant-strings-set as the string from the previous round of the New gTLD Program that is still in process.

7.10.3.3 Strings Visually Similar to Successfully Evaluated or Delegated ccTLDs or Their Variant Strings

If any applied-for string or any of its variant strings is found to be Visually Similar to any of the successfully evaluated or delegated ccTLDs or any of their variant strings, the gTLD application will not proceed.

7.10.3.4 Strings Visually Similar to a Requested IDN ccTLD

An IDN ccTLD string can be requested through the IDN ccTLD Fast Track Process or its successor on a rolling basis.118 The IDN ccTLD string application process is separate and independent from the gTLD application process. If an applied-for gTLD string is found to be Visually Similar to any requested IDN ccTLDs,119 the String Similarity Evaluation Panel will report it as a conflict with a requested IDN ccTLD, without forming a contention set, since contention sets are only for applied-for gTLD strings. ICANN will take the approach below to resolving the conflict.

If an applied-for gTLD string is found Visually Similar to a requested IDN ccTLD, ICANN will determine the outcome based on the completion status of their respective evaluation processes. The scenarios are as follows:

  • A gTLD application that has successfully completed all relevant evaluation stages, including dispute resolution and string contention, if applicable, and is eligible for entry into a Base Registry Agreement, will be considered complete, and therefore that gTLD application (primary string and applied-for variant strings, if applicable) would not be disqualified by a newly filed IDN ccTLD request. The IDN ccTLD applicant will be informed accordingly.

  • A requested primary IDN ccTLD string that is validated120 will be considered complete. Therefore, that IDN ccTLD string (primary IDN ccTLD string and requested variant strings, if applicable) would not be disqualified by a newly filed gTLD application.

In the case where neither application has completed its respective evaluation process, the gTLD application (including the applied-for variant strings, if applicable) will be put on hold while the IDN ccTLD request (including the requested variant strings, if applicable) undergoes evaluation. The hold could be for an undetermined period of time based on the IDN ccTLD applicant providing sufficient documentation and input to complete its evaluation process, as solely governed by the IDN ccTLD application evaluation process. The gTLD applicant will be informed accordingly of one of two outcomes:

  • Upon successful completion of its evaluation, the request for an IDN ccTLD will prevail and the gTLD application will not be approved.

  • If the requested IDN ccTLD is not successfully evaluated, or withdrawn by the IDN ccTLD applicant, then the IDN gTLD string may proceed with application evaluation.

If the gTLD applicant received relevant government or public authority support or non-objection but its application is eventually eliminated due to Visual Similarity with a string requested in the IDN ccTLD application process, a full refund of the evaluation fee will be issued if the gTLD application was submitted before the ccTLD’s publication.

An applicant is not allowed to apply for a gTLD string that is part of the same variant-strings-set as an applied-for ccTLD string that is validated.

7.10.3.5 Identical or Visually Similar Strings to Applied-for Strings and Their Variants

If any applied-for primary string and any of its variant strings are found to be Visually Similar to each other, and these strings are applied for in the same application, they will not be put in contention with each other and can proceed as primary and variant strings of each other.

If any applied-for string or any of its variant strings are found to be identical or Visually Similar to any other applied-for strings or any of their variant strings, the variant-string-sets121 for these applications will be placed in a contention set by the String Similarity Evaluation Panel. A contention set contains at least two applied-for strings that are identical or Visually Similar to one another or their variants. See Module 5 Contention Set Resolution for more information on contention sets and contention resolution.

These contention sets will also include information on direct contention (string A is confusable with string B) or indirect contention through string Visual Similarity transitivity (string A is confusable with string B and string B is confusable with string C but string A and string C are not confusable) or string-variant Visual Similarity transitivity (for example, string A is confusable with string B-variant-1 and string B-variant-2 is confusable with string C but string A and string C are not confusable). Indirect contention can be resolved to allow both string A and string C to proceed in case string B cannot proceed, but if string B proceeds, neither string A nor string C can proceed.

7.10.3.6 Strings Visually Similar to a Blocked Name

If any applied-for string or any of its variant strings is found to be Visually Similar to any Blocked Name122 or any of its variant strings, the application will not proceed.

7.10.3.7 String Visually Similarity with a Two-Character ASCII String

If any applied-for two-character string or any of its variant strings is found to be Similar to any two-character ASCII string or any of its variant strings, the applied-for string will not proceed.

7.10.3.8 Outcomes of String Similarity Evaluation

The outcomes discussed above are summarized in the table below. If the string is deemed not Visually Similar to any of the strings from any of the categories, it can proceed to the next stage in the application evaluation process.

Table 7-5: Outcomes for the gTLD Application Due to the String Similarity Evaluation Performed by the Panel
If the applied-for string or any member of its variant-strings-set is found to be:
Same as Variant of

Visually Similar to

(but not a variant of)
Existing gTLD Application will not be accepted. Application can proceed if existing registry operator is also the applicant. Application cannot proceed.
Applied-for string from previous round(s) of the New gTLD Program still in process123 Application will not be accepted. Application will not be accepted. Application put on hold until the previous string completes evaluation. Application can proceed with evaluation if the gTLD string from the previous round is withdrawn or not successfully evaluated.
Existing ccTLD Application will not be accepted. Application will not be accepted. Application cannot proceed.
Requested IDN ccTLD Application will not be accepted if the IDN ccTLD string has been validated. Application put on hold while the ccTLD string undergoes evaluation. Application will not be accepted if the IDN ccTLD string has been validated. Application put on hold while the ccTLD string undergoes evaluation. Application can proceed if it has successfully completed all relevant evaluation stages, and is eligible for entry into a Base Registry Agreement at the time of filing of the IDN ccTLD request. Otherwise, application put on hold until ccTLD evaluation is completed and application can proceed if Requested IDN ccTLD is withdrawn or not successfully evaluated.
Other Applied-for gTLD String Application put in contention set.

Application not put in contention set if the other applied-for string is a variant string by the same applicant.

Application put in contention set if other applied-for string is by a different applicant.

 Application put in contention set.
Blocked Name Application will not be accepted. Application will not be accepted. Application cannot proceed.
Two-Character ASCII String Application will not be accepted. Application will not be accepted. Application cannot proceed.

7.10.4 Challenging String Similarity Evaluation

The String Similarity Evaluation may be challenged. If an applicant believes the String Similarity Evaluation Panel made a factual or procedural error – such as when it determined that the applicant’s applied-for string (or a variant string) is Visually Similar and therefore either cannot proceed or should be placed in a contention set based on the cases listed above – then the applicant may file a challenge.

The evaluation challenge will be assessed under a “clearly erroneous” standard of review. Specifically, the Evaluation Challenge Service Provider must accept the String Similarity Evaluation Panel’s evaluation determination unless: (1) the panel failed to follow the established evaluation procedures, or (2) failed to consider or solicit necessary material evidence or information.

The evaluation challenge can be made within 21 days from the date the applicant receives notice of the String Similarity Evaluation determination. The String Similarity Evaluation Panel will communicate the conclusions resulting from the Evaluation Challenge within 30 days of an applicant filing such a challenge.

If the String Similarity Evaluation Panel finds a factual, procedural, or system error, then the String Similarity Evaluation for the application will be reevaluated, taking into account the findings of the Evaluation Challenge.

If the String Similarity Evaluation Panel does not find any factual, procedural, or system error, then:

  • If the challenge is based on a determination that an applied-for string is Visually Similar to an existing gTLD, any already applied-for string from a previous round of the New gTLD Program, any existing ccTLD, a requested IDN ccTLD that has been validated, any other two-character ASCII string, or any other Blocked Name, the application will not proceed further.

  • If the challenge is based on a determination that an applied-for string is Visually Similar to another applied-for string, the application remains in the relevant contention set.

7.10.5 Exception for .Brand TLDs

If an applied-for string has met the criteria to be qualified as a .Brand TLD (see Section 7.1.2.4 Applications for .Brand TLDs), and this applied-for .Brand TLD is found Similar as per details in Table 7-5: Outcomes for the gTLD Application Due to the String Similarity Evaluation Performed by the Panel above, and therefore is either unable to proceed or put in a contention set, then that .Brand TLD applicant will have the opportunity to change their string. The rules for the string change for .Brand TLD applications can be found in Section 5.3 .Brand String Change Requests.124

  1. See Section 3.7.1 Prioritization Draw for information regarding the draw, which will be held to determine the priority number of an application and the general order in which it will be processed by ICANN.↩︎

  2. There may also be different requirements for application change requests, including what types of application designations can or cannot be changed. See Section 7.1.3 Changing Application Types below for more information as well as Section 3.8 Application Change Requests for full details regarding application change requests.↩︎

  3. An applicant cannot change its application either to or from a Community Application following application submission. See Section 3.8 Application Change Requests.↩︎

  4. An Application Change Request to change the community status of an application will not be allowed. See Section 3.8 Application Change Requests for information regarding allowable change requests.↩︎

  5. It is expected that an applicant and ICANN may negotiate the specific language of a Community Registration Policy in the course of the Registry Commitments Evaluation in order to identify proposed Registry Agreement language that meets the RCE criteria (see Section 3.8.4.2 Application Change Requests: Workflow 2). The applicant is required to submit an Application Change Request that reflects the negotiated Registry Agreement language for the proposed Community Registration Policy after receiving notification from ICANN. ICANN does not outright or automatically reject a proposed Community Registration Policy without any communication with an applicant. However, an applicant’s failure to submit the requisite Application Change Request within the designated time period as defined in Section 3.8 Application Change Requests would result in a negative outcome of the RCE.↩︎

  6. See relevant instructions in Question Set 7 Community gTLDs in Appendix 1 Application Questions for the detailed requirements and suggested approach for drafting proposed Community Registration Policies, which will be evaluated through the RCE.↩︎

  7. See Section 7.5 Geographic Names for a full list of categories of strings that would qualify as geographic names.↩︎

  8. The section details an exception process, which allows for applicants to apply for a name from the Reserved Names list. This process applies exclusively to Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) - International Non-Governmental Organizations (INGO) names.↩︎

  9. For reference, see Specification 13 9.3(i) of Base Registry Agreement (Appendix 4) for more information concerning .Brand TLDs and requirements.↩︎

  10. In cases of contention with other applicants a .Brand TLD applicant may have the opportunity to change its string to add a descriptor to the domain name, in which case the domain name may no longer be an exact match to the textual elements of a registered trademark. See Section 5.3 .Brand String Change Requests.↩︎

  11. It is not always the case that a string that matches a brand name will be operated as a .Brand. It is possible that an applicant applies for a string, which matches a brand name, not intending to operate as a .Brand TLD.↩︎

  12. In some cases, a .Brand TLD applicant may obtain a Code of Conduct (Specification 9) Exemption but not be eligible for Specification 13.↩︎

  13. See also Section 3.8 Application Change Requests regarding eligibility and evaluation requirements.↩︎

  14. As noted above, eligible applicants may also apply for a Registry Code of Conduct Exemption. See Section 7.4 Registry Operator Code of Conduct Exemption Evaluation.↩︎

  15. Applicants will also have the opportunity to apply for variants of “new” IDN TLDs. See Section 7.1.2.7 Applications for New IDN TLD Including One or More Variants.↩︎

  16. See Recommendation 3.5 of the Phase 1 Final Report on the Internationalized Domain Names Expedited Policy Development Process: https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎

  17. Ibid. See Recommendations 3.11 and 3.12. The total number of variants that can be applied for is based upon the calculation in the RZ-LGR.↩︎

  18. Ibid.↩︎

  19. Ibid. See Recommendation 3.5.↩︎

  20. See Phase 1 Final Report on the Internationalized Domain Names Expedited Policy Development Process: https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎

  21. An IGO is an organization composed primarily of sovereign states, or of other intergovernmental organizations. IGOs are established by treaty or other agreement that acts as a charter creating the group. Examples include the United Nations, the World Bank, or the European Union. Source: Union of International Associations, https://uia.org/faq/yb3.↩︎

  22. Typically defined as a national government or any department, agency, or subdivision thereof with the relevant authority.↩︎

  23. See Applicant Support Program Handbook: https://newgtldprogram.icann.org/en/application-rounds/round2/asp/handbook.↩︎

  24. See outcome of PDP Protection of IGO and INGO Identifiers in All gTLDs for more information: https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎

  25. See DNS Label Conversion Rules under “Implementation Notes” for more information: https://www.icann.org/en/contracted-parties/consensus-policies/protection-of-intergovernmental-organization-and-international-non-governmental-organization-identifiers-policy/protection-of-igo-and-ingo-identifiers-in-all-gtlds-policy-21-02-2024-en.↩︎

  26. See Special-Use Domain Names: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.↩︎

  27. See RFC 6761: https://tools.ietf.org/html/rfc6761.↩︎

  28. Note: ICANN will reserve translations of the terms “test” and “example” in multiple languages.↩︎

  29. See ICANN Community: https://www.icann.org/community.↩︎

  30. See Regional Internet Registries: https://aso.icann.org/about/aso-and-nro/rirs/.↩︎

  31. See IETF Groups: https://www.ietf.org/about/groups/.↩︎

  32. See Reserved Names Working Group Final Report: https://gnso.icann.org/en/issues/new-gtlds/final-report-rn-wg-23may07.htm.↩︎

  33. As a result of SAC113 and subsequent work as directed by the ICANN Board, .INTERNAL was added to the Blocked Names list. See https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf.↩︎

  34. See Root Zone Database: https://www.iana.org/domains/root/db.↩︎

  35. 2012 Round New gTLD Program website: https://gtldresult.icann.org/applicationstatus/viewstatus.↩︎

  36. Applicants should be aware that any challenge submitted after this point will not be accepted and are therefore advised to start their application(s) as soon as possible and submit any challenges no later than 14 days prior to the close of the application submission period.↩︎

  37. As noted in Section 7.10.1 Scope of String Similarity Evaluation, per GNSO Council motion 20251113, “[t]he relevant identifiers [associated with the Red Cross Red Crescent Movement and the International Olympic Committee and the full names of specific International Governmental Organizations and International Non-Governmental Organizations] shall not be included in the String Similarity Evaluation in the New gTLD Program and such a relevant identifier shall not operate as a bar to an application for a confusingly similar string by another applicant, during evaluation.” See the full GNSO Council motion: https://gnso.icann.org/en/council/resolutions/2020-current#20251113.↩︎

  38. See Policy Development Process for Protection of IGO and INGO Identifiers in All gTLDs for the scope of relevant names: https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎

  39. See Board Resolution 2014.04.30.03: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-of-directors-30-04-2014-en#2.a.↩︎

  40. See Board Resolution 2019.01.27.19: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-27-01-2019-en#2.d.↩︎

  41. See Red Cross names: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#red-cross1. Note that this list–and the ones for IOC and IGO names–applies to second-level domain names but will also be repurposed to reserve those same names at the top level in the context of the New gTLD Program: 2026 Round. Reference the “Name” column of each list linked for the relevant names.↩︎

  42. See IOC names: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IOC.↩︎

  43. See IGO names: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IGOs.↩︎

  44. See “List of non-governmental organizations in consultative status with the Economic and Social Council as at 31 December 2022”: https://docs.un.org/en/E/2023/INF/5, found here: https://esango.un.org/civilsociety/displayConsultativeStatusSearch.do?method=search.↩︎

  45. See GAC membership list: https://gac.icann.org/about/gac-members.↩︎

  46. Eligible applicants may also apply for a Code of Conduct (Specification 9) exemption as well as Section 7.4 Code of Conduct Exemption Evaluation.↩︎

  47. See Trademark Clearinghouse: https://trademark-clearinghouse.com/.↩︎

  48. See Trademark Clearinghouse: https://trademark-clearinghouse.com/.↩︎

  49. Country and territory names are excluded from the process based on advice from the Governmental Advisory Committee in past communiqués. ​​These communiqués interpret Principle 2.2 of the GAC Principles regarding New gTLDs stating that strings which are a meaningful representation or abbreviation of a country or territory name should be handled through a ccPDP, and other geographic strings could be allowed in the gTLD space if in agreement with the relevant government or public authority.↩︎

  50. See ISO 3166-1 standard list: https://www.iso.org/obp/ui.↩︎

  51. Permutations include removal of spaces, insertion of punctuation, and addition or removal of grammatical articles like “the.” A transposition is considered a change in the sequence of the long or short–form name, for example, “RepublicCzech” or “IslandsCayman.”↩︎

  52. City governments with concerns about strings that are duplicates, nicknames or close renderings of a city name should not rely on the evaluation process as the primary means of protecting their interests in a string. Rather, relevant concerned parties may elect to file a formal objection to an application that is opposed by the relevant community, or may submit their own application for the string.↩︎

  53. ​​The five regions recognized by UNESCO (in the six UN languages) include: Africa, Arab States, Asia and the Pacific, Europe and North America, Latin America and the Caribbean (as of May 2025).↩︎

  54. See Standard country or area codes for statistical use (M49): https://unstats.un.org/unsd/methodology/m49/ published as of December 2025.↩︎

  55. See Root Zone Label Generation Rules Version 6: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎

  56. See the GAC Membership: https://gac.icann.org/about/gac-members.↩︎

  57. See 4 March 2011 ICANN Board Notes on the GAC New gTLDs Scorecard: https://archive.icann.org/en/topics/new-gtlds/board-notes-gac-scorecard-04mar11-en.pdf.↩︎

  58. See Registry Transition Processes: https://www.icann.org/en/contracted-parties/registry-operators/services/registry-transition-processes.↩︎

  59. See RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎

  60. See definitions for variant related concepts in the Glossary.↩︎

  61. See Registry Service Provider Evaluation Program Handbook: https://newgtldprogram.icann.org/sites/default/files/documents/rsp-handbook-03jun24-en.pdf.↩︎

  62. See RFC 9499, section 2: https://www.rfc-editor.org/rfc/rfc9499.html#name-names.↩︎

  63. For examples of name collisions, see Section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf.↩︎

  64. See Name Collision Analysis Project Study Two Report: https://www.icann.org/en/system/files/files/ncap-study-2-report-05apr24-en.pdf.↩︎

  65. See Board Resolution 2024.09.07.01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-09-2024-en.↩︎

  66. For further information about how Name Collisions were managed during the last round, see https://www.icann.org/resources/pages/name-collision-2013-12-06-en.↩︎

  67. See Identifier Technology Health Indicators (ITHI): https://ithi.research.icann.org/.↩︎

  68. This procedure will be available on the New gTLD Program website.↩︎

  69. For details on how strings are assigned priority, see Section 3.7 Order of Application Processing and Prioritization Draw.↩︎

  70. This procedure will be available on the New gTLD Program website: https://newgtldprogram.icann.org/en.↩︎

  71. This procedure will be available on the New gTLD Program website: https://newgtldprogram.icann.org/en.↩︎

  72. See ICANN Bylaws, Article 1, Section 1.1(a): https://www.icann.org/resources/pages/governance/bylaws-en/#article1.↩︎

  73. See more details in the GAC ICANN45 Toronto Communiqué: https://gac.icann.org/contentMigrated/icann45-toronto-communique, the GAC ICANN46 Beijing Communiqué: https://gac.icann.org/contentMigrated/icann46-beijing-communique, and the subsequent ICANN Board resolution 2014.02.05.NG01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en; see more background on the GAC Consensus Advice and its impact on the 2012 Round of the New gTLD Program: https://newgtlds.icann.org/en/applicants/gac-advice#gac-1-applicant-advisories.↩︎

  74. In the Base Registry Agreements between ICANN and existing registry operators from the 2012 Round of the New gTLD Program, the terms “Registry Voluntary Commitments” and “RVCs” did not exist and instead, the term “specific public interest commitments” was used (the terms “voluntary PICs” and “private PICs” were also used informally in the past). The Base Registry Agreement for the 2026 Round of the New gTLD Program will use the term “specific voluntary public interest commitments” to refer to what we now call “Registry Voluntary Commitments” or “RVCs”. This approach conforms to the existing structure and phrasing of the Base Registry Agreement Specification 11, as well as ICANN’s Public Interest Commitments Dispute Resolution Procedure (PICDRP), which continues to be the dispute resolution procedure for addressing alleged complaints that a registry operator may not be complying with one or more Mandatory and Safeguard PICs, as well as future approved RVCs in its Registry Agreement going forward. See Specification 11 in Appendix 4 Base Registry Agreement and Section 1.2.17 Dispute Resolution Procedures After Delegation.↩︎

  75. See the Public Interest Commitment Dispute Resolution Procedure (PICDRP): https://www.icann.org/picdrp-en.↩︎

  76. This item reflects the Base Registry Agreement Specification 11 Section 3(b) as amended on 5 April 2024. For the purpose of the Base Registry Agreement, “DNS Abuse” is defined as malware, botnets, phishing, pharming, and spam (when spam serves as a delivery mechanism for the other forms of DNS Abuse) as those terms are defined in Section 2.1 of SAC 115 - SSAC Report on an Interoperable Approach to Addressing Abuse Handling in the DNS: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-115-en.pdf. See Section 4.1 on p. 2 of the 2024 Global Amendment to Registry Agreements: https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-global-amendment-05-04-2024-en.pdf.↩︎

  77. The Base Registry Agreement is the product of extensive community consultation. ICANN will only consider modification to the agreement in extraordinary circumstances, such as situations in which unique legal, jurisdictional, or regulatory issues would legally prevent an entity from executing the Base Registry Agreement as-is. See Section 1.2.15 Contracting.↩︎

  78. See ICANN46 Beijing Communiqué: https://gac.icann.org/contentMigrated/icann46-beijing-communique.↩︎

  79. See ICANN Board resolution 2014.02.05.NG01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en.↩︎

  80. See Annex 2 of the ICANN Board resolution 2014.02.05.NG01: https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf.↩︎

  81. The ICANN46 Beijing Communiqué (see https://gac.icann.org/contentMigrated/icann46-beijing-communique) identified a non-exhaustive list of strings that were applied for in the 2012 Round of the New gTLD Program and advised the Board that Safeguard PICs should apply to those applied-for strings. The GAC organized these identified strings into applicable sub-groups.↩︎

  82. See ICANN46 Beijing Communiqué: https://gac.icann.org/contentMigrated/icann46-beijing-communique↩︎

  83. Ibid.↩︎

  84. Ibid.↩︎

  85. Ibid.↩︎

  86. See the New gTLD Program website: https://newgtldprogram.icann.org/.↩︎

  87. See the current ICANN Consensus Policies: https://www.icann.org/consensus-policies-en.↩︎

  88. Additional Registry Services refer to the services offered by a Registry Service Provider outside of the Critical Functions (that is, DNS Service, DNSSEC proper resolution, EPP, RDDS, and Data Escrow). See more explanation of the additional Registry Service under section 1.1A-D in the Registry Services Evaluation Policy (see https://www.icann.org/rsep-en). See details about the Critical Functions in Section 6 of Specification 10 in the Base Registry Agreement (Appendix 4).↩︎

  89. If the performance of an approved RVC requires the operation of an approved Registry Service, the commitment itself is expected to be included in Specification 11 of the applicable Base Registry Agreement, but the approved Registry Service is expected to be included in Exhibit A of the Base Registry Agreement.↩︎

  90. As a response to Question Set 20 Additional Information and Supporting Material in Appendix 1 Application Questions, an applicant can include additional information and supporting materials that may be of interest to the public or relevant to the application. For example, an applicant may include links to its separate agreements with a third party and its additional commitments outside the Registry Agreement. The applicant’s responses to this question will be for informational purposes only, and will not be evaluated or binding on the applicant via the Registry Agreement. However, these responses will be open to the public for review and comment. Accordingly, applicants should carefully consider whether and what additional information they wish to disclose in response to Question Set 20. For example, it could be used by a third party to support an objection, but may also help address third-party concerns and avoid a potential objection.↩︎

  91. It is expected that an applicant and ICANN may negotiate the specific language of an RVC in the course of the Registry Commitments Evaluation in order to identify proposed Registry Agreement language that meets the RCE criteria (see Section 3.8.4.2 Application Change Requests: Workflow 2). ICANN does not outright or automatically reject a proposed RVC without any communication with an applicant.↩︎

  92. See the New gTLD Program website: https://newgtldprogram.icann.org/.↩︎

  93. The five RVC evaluation criteria reflect this fundamental principle, which was recognized by the ICANN Board when it directed ICANN org to implement evaluation criteria and processes for the consideration of commitments proposed by applicants for inclusion in the applicable Registry Agreements: “In order to enter into any agreement, ICANN must believe that the proposed terms (including any public interest commitments) are being entered into in service of ICANN's Mission, which is to ensure the stable and secure operation of the Internet's unique identifier systems.” (See rationale for ICANN Board resolutions 2024.06.08.08 – 2024.06.08.10: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b).↩︎

  94. If the applicant believes such commitments not proposed for inclusion in the Registry Agreement may be of interest to the public or relevant to the application, the applicant may include these as a response to Question Set 20 Additional Information and Supporting Material in the Appendix 1 Application Questions for the public to review and comment. The applicant’s responses to this question will be for informational purposes only, and will not be evaluated or binding on the applicant via the Registry Agreement. Accordingly, applicants should carefully consider whether and what additional information they wish to disclose in response to Question Set 18. For example, it could be used by a third party to support an objection, but may also help address third-party concerns and avoid a potential objection.↩︎

  95. The word “should” (as opposed to “must”) is purposefully used in criterion 4. See RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels: https://datatracker.ietf.org/doc/html/rfc2119 (“This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course”). There may be circumstances in which an RVC that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion, for example, if this type of RVC is necessary to address GAC Consensus Advice.↩︎

  96. See Appendix 4 Base Registry Agreement, the Registrar Accreditation Agreement: https://www.icann.org/resources/pages/registrars/registrars-en, and the current ICANN Consensus Policies: https://www.icann.org/consensus-policies-en.↩︎

  97. See additional background information in the ICANN Board Resolution 2024.06.08.08 - 2024.06.08.10: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b.↩︎

  98. The ICANN Bylaws state that “ICANN shall not regulate (that is, impose rules and restrictions on) services that use the Internet's unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a)....” (See ICANN Bylaws, at Article 1, Section 1.1(c): https://www.icann.org/resources/pages/governance/bylaws-en/#article1). Following extensive deliberation and community consultation regarding how the Bylaws impact the evaluation of RVCs, the ICANN Board determined that ICANN should exclude from the 2026 Round Registry Agreements “any RVCs and other comparable registry commitments that restrict content in gTLDs.”↩︎

  99. If an applicant for a Community gTLD desires for a Community Registration Policy to be scored in the Community Priority Evaluation (CPE), it must propose such a policy for inclusion in Specification 12 of the applicable Base Registry Agreement when submitting a Community Application. Such a policy serves as a prerequisite to the application’s participation in CPE (see Section 5.4 Community Priority Evaluation).↩︎

  100. It is expected that an applicant and ICANN may negotiate the specific language of a Community Registration Policy in the course of the Registry Commitments Evaluation in order to identify proposed Registry Agreement language that meets the RCE criteria (see Section 3.8.4.2 Application Change Requests: Workflow 2). The applicant is required to submit an Application Change Request that reflects the negotiated Registry Agreement language for the proposed Community Registration Policy after receiving notification from ICANN. ICANN does not outright or automatically reject a proposed Community Registration Policy without any communication with an applicant. However, applicant’s failure to submit the requisite Application Change Request within the designated time period as defined in Section 3.8 Application Change Requests would result in a negative outcome of the RCE.↩︎

  101. See Registration Restrictions Dispute Resolution procedure (RRDRP): https://www.icann.org/rrdrp-en, and Community gTLD Change Requests Procedure: https://www.icann.org/resources/pages/community-gtld-change-requests-en.↩︎

  102. If an applicant for a Community gTLD believes additional registration policies that the applicant plans to implement but does not propose to include in the applicable Registry Agreement may be of interest to the public or relevant to the application, the applicant may include these as a response to Question Set 20 Additional Information and Supporting Material in Appendix 1 Application Questions for the public to review and comment. The applicant’s responses to this question will be for informational purposes only, and will not be evaluated (for example, it will not be considered in any applicable scoring during the Community Priority Evaluation (CPE)) or binding on the applicant via the Registry Agreement. Accordingly, applicants should carefully consider whether and what additional information they wish to disclose in response to Question Set 20. For example, it could be used by a third party to support an objection, but may also help address third-party concerns and avoid a potential objection.↩︎

  103. See Root Zone Label Generation Rules: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎

  104. For any variant string, its primary string is used to determine its variant-strings-set by the Root Zone Label Generation Rules. The set contains the primary string, any allocatable variant strings, and any blocked variant strings.↩︎

  105. For example, an applicant can only apply for allocatable variant strings but cannot apply for blocked variant strings, as calculated by the Root Zone Label Generation Rules. See Section 3.1.9.1 Rules for IDNs and Their Variants.↩︎

  106. See Affirmation 24.2, New gTLD Subsequent Procedures Final Report, p.108: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎

  107. Such strings are referred to as Visually Similar.↩︎

  108. In the future, after the next new gTLD round, some of these allocatable variant strings will be allocated (and are included in this category).↩︎

  109. Per GNSO Council motion 20251113, “[t]he relevant identifiers [associated with the Red Cross Red Crescent Movement and the International Olympic Committee and the full names of specific International Governmental Organizations and International Non-Governmental Organizations] shall not be included in the String Similarity Evaluation in the New gTLD Program and such a relevant identifier shall not operate as a bar to an application for a confusingly similar string by another applicant, during evaluation.” See the full GNSO Council motion: https://gnso.icann.org/en/council/resolutions/2020-current#20251113. See also Section 7.2.2 Reserved Names.↩︎

  110. These are strings that are not of the following status: “Withdrawn”, “RA Terminated”, or “Delegated.” All strings in process from the 2012 new gTLD round are published at: https://gtldresult.icann.org/. See also Board Resolution 2025.09.14.05-2025.09.14.06 on Termination Procedure for Remaining 2012 Round Applications that were not Successful: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎

  111. For a list of all successfully evaluated IDN ccTLDs, see https://www.icann.org/resources/pages/string-evaluation-completion-2014-02-19-en.↩︎

  112. All top-level domains currently in the root zone can be found at https://data.iana.org/TLD/tlds-alpha-by-domain.txt (the list is updated regularly).↩︎

  113. Strings currently requested in the IDN ccTLD Fast Track process (see https://www.icann.org/resources/pages/fast-track-2012-02-25-en) or an IDN ccTLD policy, which may replace the IDN ccTLD Fast Track process. There may be a period where both IDN ccTLD Fast Track Process and an IDN ccTLD Policy may be running concurrently. In such a case, prospective IDN ccTLD strings from both these processes will be considered in scope.↩︎

  114. The broader definition of Blocked Names is provided in Section 7.2.1 Blocked Names. For the purposes of String Similarity Evaluation, only two categories are applicable: (i) Special-Use Domain Names, and (ii) ICANN, IANA, and IETF-Related Bodies and Internet Infrastructure. Other categories of Blocked Names listed will not be used in String Similarity Evaluation.↩︎

  115. All two-letter ASCII codes are reserved for country code assignment by the independent ISO 3166 Management Agency.↩︎

  116. A string from a previous round of the New gTLD Program will be in one of the following statuses: “Active”, “In Contracting”, “On-hold”, or “In PDT.” Also see the Application status page: https://gtldresult.icann.org/application-result/applicationstatus.↩︎

  117. The broader definition of Blocked Names is provided in Section 7.2.1 Blocked Names. For the purposes of String Similarity Evaluation, only two categories are applicable: (i) Special-Use Domain Names, and (ii) ICANN, IANA, and IETF-Related Bodies and Internet Infrastructure. Other categories of Blocked Names listed will not be used in String Similarity Evaluation.↩︎

  118. The ccNSO is currently working on the IDN cc Policy Development Process (ccNSO PDP4 (De-)Selection of IDN ccTLDs), which is intended to replace the IDN ccTLD Fast Track Process. Once the IDN ccPDP4 policy is approved and implemented, it will provide another mechanism for IDN ccTLD applicants and will also be applicable here.↩︎

  119. A requested IDN ccTLD string is one that has been submitted to ICANN through the IDN ccTLD application system and is undergoing string evaluation.↩︎

  120. The term “validated” essentially means successfully evaluated. This term was initially defined in the IDN ccTLD Fast Track Process Implementation and reaffirmed in the ccPDP4 Initial Report. See the “Validation of IDN ccTLD Strings & Variants” section in the ccPDP4 Initial Report for more details.↩︎

  121. As defined in Section 3.1.8.3.1.3 Choosing Primary and Variant Strings Using the RZ-LGR.↩︎

  122. The broader definition of Blocked Names is provided in Section 7.2.1 Blocked Names. For the purposes of String Similarity Evaluation, only two categories are applicable: (i) Special-Use Domain Names, and (ii) ICANN, IANA, and IETF-Related Bodies and Internet Infrastructure. Other categories of Blocked Names listed will not be used in String Similarity Evaluation.↩︎

  123. These are strings that are not of the following status: “Withdrawn”, “RA Terminated”, or “Delegated.” All strings in process from the 2012 new gTLD round are published at: https://gtldresult.icann.org/. See also Board Resolution 2025.09.14.05-2025.09.14.06 on Termination Procedure for Remaining 2012 Round Applications that were not Successful: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎

  124. The .Brand String Change Request is separate from the replacement string process. See Section 5.1 Replacement Strings.↩︎