Module 1 The Applicant Journey

This module provides a comprehensive overview of the entire experience of a new gTLD applicant, from initial application submission to potential delegation. The process is intricate and multi-staged, encompassing technical, financial, and operational evaluations.

This applicant journey is designed to equip prospective applicants with essential information about each stage, including submission, pre-evaluation, community input, evaluation, string contention, dispute resolution, and contracting.

By offering a clear roadmap, this module guides applicants through the complexities of the application process, ensuring they are prepared for every step toward securing a new gTLD.

1.1 Pre-Submission Information

1.1.1 Eligibility

Only legal entities such as corporations, organizations, and institutions as well as governmental, non-governmental, and inter-governmental entities may apply for a new gTLD. Applications from individuals or sole proprietorships will not be considered. Additionally, applications from or on behalf of entities that have not yet been formed, or applications that assume the future formation of a legal entity (such as a pending joint venture) will not be accepted.

1.1.2 Fees

Applicants are required to pay the full gTLD evaluation fee of USD 227,000 for each application, with exceptions for those that qualify for the Applicant Support Program (ASP) and applicants for variant applications that meet the criteria described in Section 3.3 Fees and Payments. The fee is due upon receipt of the invoice, and complete payment must be received by ICANN no later than seven days after the close of the application submission period. If the applicant has not paid the gTLD evaluation fee within this seven-day period, the application will generally not be processed any further and will be canceled.

All applicants, including those that qualify for ASP,¹ may be required to pay additional fees for conditional evaluations. For example, this applies if an applicant seeks for its application to be designated as a .Brand TLD or wishes to have a Registry Voluntary Commitment added to its Registry Agreement. If an applicant fails to pay for a conditional evaluation, depending on the type of conditional evaluation, the applicant may be asked to submit an Application Change Request to remove that section of its application to proceed. Otherwise, required conditional evaluations must be paid on time to avoid disqualification. More information can be found in the Section 3.3 Fees and Payments section.

1.1.3 Terms and Conditions

All applicants must agree to the TLD Application Terms and Conditions New gTLD Program: 2026 Round in order to submit their applications (see Appendix 10 Terms and Conditions, which applicants are encouraged to read in full).

1.1.4 TLD Application Management System

Applications must be submitted electronically through the TLD Application Management System (TAMS). Paper applications will not be allowed. Applicants are encouraged to consult the TAMS User Guide on the New gTLD website² for guidance on how to use the system to ensure proper understanding prior to submitting an application.

1.1.5 Good Faith Intent

Applications must be submitted with a bona fide (“good faith”) intent to operate the gTLD. Applicants must affirm a bona fide intent to operate the gTLD for all submitted applications in TAMS (see Question Set 21 in Appendix 1 Application Questions). ICANN reserves the right to disallow an application from moving forward if it determines that the application was not submitted in good faith.

1.1.6 Universal Acceptance

Universal Acceptance aims to ensure that all Internet-enabled applications, devices, and systems should accept all domain names and email addresses, regardless of script, language, or TLD length. For more information on Universal Acceptance in the New gTLD Program, see Section 2.3 Universal Acceptance of Domain Names and Email Addresses.

1.1.7 Applicant Support Program

Applicants who would like to apply for a new gTLD and operate a registry can apply to the Applicant Support Program (ASP). If eligible, supported applicants may receive financial and non-financial support. See the ASP section on the New gTLD Program website³ for more information and updates.

1.2 Application Stages

This section describes the stages that an application passes through during the application submission window and once submitted. While some stages apply to all applications submitted, others occur only under specific circumstances. This section offers a high-level, non-comprehensive overview of the various processes. For complete information, applicants and other parties should refer to the relevant Applicant Guidebook sections.

1.2.1 Application Submission

Expected Duration: 105 days

1.2.1.1 Creation of an ICANN Account

Before accessing TAMS to submit their application, applicants must register for an ICANN user account on the ICANN Account website⁴ and enable multi-factor authentication.

1.2.1.2 Application Submission Period

The application submission period is expected to open no later than 23:59 UTC on 30 April 2026 and remain open for 105 days, closing on 12 August 2026 at 23:59 UTC. To be considered, all applications must be submitted by the close of the application submission period, as the system will not allow for late submissions. Applicants are encouraged to submit their completed applications as soon as practicable after the application submission period opens. Waiting until the end of this period to begin the process will not provide sufficient time to complete all the necessary steps and submit a complete application on time.

Applicants must pay their gTLD evaluation fee upon receipt of the invoice, and no later than seven days after the close of the application submission period for their application to be considered, as described in Section 3.3 Fees and Payments.

After submitting their application, applicants will not be able to make any changes outside the processes described in Section 3.8 Application Change Requests. Application Change Requests can only be submitted after String Confirmation Day.

1.2.1.3 Application Questions

The application will consist of the following sections to be completed upon user registration:

1. Organization Information

2. Financial Information

3. gTLD Application Information

To complete the application, users must answer a series of questions and provide supporting documents, as required. The system will validate that all mandatory fields include a response before applicants can submit their application. See more information in Section 3.1.3 Application Questions as well as Appendix 1 Application Questions.

1.2.1.4 Strings in an Application

Each application is for one gTLD and may include one or more of its allocatable variant strings, as applicable. An application may also be for one or more allocatable variant strings of an existing gTLD.⁵

1.2.1.5 Replacement String Selection

To potentially reduce the instances of string contention, as part of their application, applicants may also elect to submit replacement strings, as described in Section 5.1 Replacement Strings.

1.2.1.6 Application and String Types

As described in Section 3.1.6 Application and String Types, certain application types may require differential treatment according to the nature of the application, string, or applicant.

The different types of applications include the following: General, Community, Geographic Name, Reserved Name, .Brand TLD, Internationalized Domain Name (IDN), Variant of Existing gTLD, Primary IDN TLD including one or more Variants, Category 1 Safeguard, and applications from governments, IGOs, and supported applicants (Government/IGO Applicant and Applicant Support application types).

In addition, certain strings will initiate specific processing and evaluation procedures: Geographic Names, IDN TLDs, Reserved Names, and Strings Subject to Category 1 Safeguards.

1.2.1.7 Closed Generics

The ICANN Board has resolved that applications for exclusive use strings (closed generics⁶) will not be approved unless and until an approved methodology and criteria are established to evaluate whether a proposed closed generic domain would serve the public interest. See Section 3.1.7 Exclusive Use Strings (Closed Generics).

1.2.1.8 Pre-Submission String Validations

Certain validations (see Section 3.1.8 Pre-Submission String Validations) on the primary and variant strings, including replacement strings, are automatically incorporated into and implemented via TAMS. If a string fails one of the validations or a match is found, the applicant will receive an error or warning message in TAMS explaining the detected issues and will not be allowed to proceed and submit its application or will have to provide additional documentation. Applicants will be able to enter their string in TAMS to check whether there is a match.

1.2.1.8.1 Blocked Names Identification

Certain strings, referred to as “Blocked Names”, are not available for delegation. During the application drafting process, the system will automatically verify whether the applicant’s entered string and any applicable variant strings appear on the Blocked Names list. If so, the applicant will not be able to move forward with that string and must select a different one in order to continue the application. For more information, see Section 3.1.8.1 Blocked Names Identification.

1.2.1.8.2 Reserved Names Identification

Certain strings, known as “Reserved Names,” are available as gTLDs only through a verification process. These names are designated for specific entities, referred to as “Limited International IGO-INGOs,” which are the only parties eligible to apply for them. ICANN maintains the Reserved Names list, compiled from various sources, and requires relevant entities to provide appropriate documentation. During the application drafting process, the system will automatically verify whether the applicant’s entered string and any applicable variant strings appear on the Reserved Names list. If the string is found on this list, the exception process will be initiated, during which the applicant will be prompted to upload documentation demonstrating that it is the entity for which the name is reserved. For more information, see Section 3.1.8.2 Reserved Names.

1.2.1.8.3 DNS Stability Review

This review assesses whether an applied-for string will adversely affect the security or stability of the Domain Name System (DNS) and comply with DNS and other relevant standards, as described in Section 3.1.8.3 DNS Stability Review. The DNS Stability Review includes a check for compliance with the applicable Root Zone Label Generation Rules. If the string fails any of the tests, the applicant will not be able to submit its application.

1.2.1.9 Registry Service Provider Selection

All applicants are required to identify one or more evaluated Registry Service Providers (RSPs), evaluated via the RSP Evaluation Program⁷ that the applicant intends to use if the applied-for string or strings proceed to delegation. The list of evaluated RSPs can be found on the Registry Service Provider (RSP) Application page.⁸

As part of its application submission, the applicant is encouraged to identify the RSPs it intends to use and the Registry Services it intends to offer in the proposed gTLD(s), but the applicant may choose to specify the RSPs just before Application Evaluation.

Applicants may also engage external third-party RSPs or seek ICANN’s approval to deliver critical registry services themselves as RSPs through the RSP Evaluation Program. See Section 3.1.10 Registry Service Provider Selection.

1.2.2 Pre-Evaluation Processes

1.2.2.1 Administrative Check and Preparation for Reveal Day

Expected duration: Eight weeks

Following the close of the application submission period, ICANN will perform necessary administrative due diligence and verify whether the evaluation fees have been received. ICANN will review the list of submitted applications and place applications for identical strings into contention sets in preparation for Reveal Day.

The administrative check is expected to be completed for all applications in a period of approximately eight weeks, subject to the overall application volume. In the event of a high volume of applications such that it prevents ICANN from processing all applications within the designated period, ICANN will post an updated timeline as soon as feasible.

1.2.2.2 Reveal Day

Absent extraordinary circumstances, ICANN expects to publish the list of all applications that have passed the Administrative Check on Reveal Day no later than nine weeks following the close of the application submission period. This list, which will be posted on the New gTLD Program website,⁹ will include the relevant applied-for strings and any variant and replacement strings, if applicable. The public portions of each application will also be made available. A list of contention sets containing applications for identical strings will also be published on the website. See Section 5.2.4.1 Contention as a Result of Applications for Identical gTLD Strings for more information. Certain communications and activities will be prohibited starting on Reveal Day; for more information, refer to Section 5.2.3.1 Prohibited Communications and Activities.

1.2.2.3 Replacement Period

Expected duration: Two weeks

Once applicants have access to the full list of applied-for strings, as well as any variant strings and replacement strings, they will have the opportunity to replace their applied-for string with their replacement string. Applicants that have selected an eligible replacement string will have a 14-day Replacement Period to notify ICANN via TAMS of their intention to replace their original applied-for string with the replacement string identified in their application. See Section 5.1 Replacement Strings for more information.

1.2.2.4 String Confirmation Day

On String Confirmation Day, ICANN will post an updated list of applications and their chosen strings (whether original or replacement, as noted above). A list of updated contention sets will also be published.

1.2.2.5 Prioritization Draw

A Prioritization Draw is expected to be held no later than 30 days after String Confirmation Day. The Draw will determine the Priority Number of an application and the general order in which it will be processed by ICANN, as described in Section 3.7 Order of Application Processing and Prioritization Draw.

1.2.3 Community Input, Objections, and Appeals

Starting on String Confirmation Day, the community will have the opportunity to provide input as described below.

1.2.3.1 Application Comments

Expected duration: 104 days following String Confirmation Day; 30 days following Application Change Requests

The general public will be able to post application comments to the Application Comment Forum, as described in Section 4.1 Application Comments. ICANN will share these comments and any responses with the evaluators assigned to the relevant applications. Only the comments and responses received during the comment windows (104 days following String Confirmation Day and 30 days following applicable Application Change Requests¹⁰) will be considered by the evaluation panels.

1.2.3.2 GAC Member Early Warnings

Expected duration: 104 days following String Confirmation Day

Members and observers of ICANN’s Governmental Advisory Committee (GAC) may issue GAC Member Early Warnings within the 104 days following String Confirmation Day, as described in Section 4.2 GAC Member Early Warnings.

1.2.3.3 GAC Consensus Advice

The GAC can provide GAC Consensus Advice to the ICANN Board on any application, as outlined in the ICANN Bylaws and as described in Section 4.3 GAC Consensus Advice.

1.2.3.4 Singular/Plural Notifications

Expected duration: 30 days following String Confirmation Day

Within 30 days of String Confirmation Day, the public can notify ICANN about:

• Applied-for strings representing singular or plural versions of the same word in the same language.

• An applied-for string being a singular or plural version of a:

  • Delegated string

  • String still being processed from previous new gTLD round

  • Blocked Name

For more information, refer to Section 4.4 Singular/Plural Notifications.

1.2.3.5 Objections and Appeals

Expected duration of objections filing period: 104 days following String Confirmation Day

Expected duration of appeals filing period: 15 days following objection determination to file notice of appeal; 15 days to file appeal

In the 104 days following String Confirmation Day, parties with standing may file objections against specific applications, which will be evaluated by a panel of expert(s). Objections may be based on four grounds: string confusion, legal rights, limited public interest, and community.

The party that does not prevail in an objection has a limited opportunity to appeal the decision. The non-prevailing party must notify the Dispute Resolution Service Provider (DRSP) of its intent to appeal within 15 days following the issuance of the objection determination. Subsequently, the non-prevailing party has an additional 15 days from the notice date to file the appeal and pay the required fees.

Objections and appeals are filed directly with DRSPs identified by ICANN. Both filing and processing these involve costs for the parties. See Section 4.5 Objections and Appeals for more information on costs and procedures.

1.2.4 String Evaluation

Expected duration: 180 days¹¹

String Evaluation focuses solely on the evaluation of the applied-for strings and their allocatable variant strings. This process starts after String Confirmation Day and is expected to take 180 days. String Evaluation will partially overlap with the period during which the community can provide their input on the applications, as described in Module 4 Community Input, Objections, and Appeals. String Evaluation consists of the five elements described below, each of which will be assessed concurrently. String Evaluation, unlike Application and Applicant Evaluation, does not follow the priority order.

1.2.4.1 String Similarity Evaluation

The String Similarity Evaluation will be performed by an expert panel with the objective of preventing user confusion and loss of confidence in the DNS resulting from delegation of Visually Similar¹² strings, as described in detail in Section 7.10 String Similarity Evaluation.

1.2.4.2 Name Collision Initial Assessment

The Name Collision Initial Assessment aims to identify strings with a high risk of name collision, as described in Section 7.7 Name Collision. If a string is found to be high-risk, the applicant will have an opportunity to submit a Mitigation Plan for evaluation, which will allow the application to proceed if approved. Otherwise, the string will be added to the Collision String List, and the application will not proceed. The section also includes information on Temporary Delegation, which is an additional process applicable for strings not initially identified as high-risk.

1.2.4.3 Safeguard Assessment

The Safeguard Assessment will determine if an applied-for string will be required to have specific safeguards as contractual requirements in the applicable Registry Agreement as it relates to consumer protection, sensitive strings, and regulated markets. More information is found in Section 7.8.2 Safeguard Public Interest Commitments.

1.2.4.4 Geographic Names Identification

As part of the Geographic Names Identification, a panel will review all of the applied-for strings and identify which strings may be considered a Geographic Name, as described in Section 7.5 Geographic Names. This is separate from the more substantive verification process called Geographic Names Review that would take place as part of Application Evaluation.

1.2.4.5 Singular/Plural Notifications Evaluation

ICANN will review the materials submitted as part of the Singular/Plural Notifications process and will determine whether certain strings represent the singular and plural forms of the same word in the same language. See Section 4.4.3 Outcome of Singular/Plural Notifications.

1.2.5 Temporary Delegation

Strings that were not identified as potentially high-risk as described in Section 7.7.2 Name Collision Initial Assessment will undergo Temporary Delegation. Temporary Delegation can start as soon as the Name Collision Initial Assessment has been concluded, even if other evaluations that are part of String Evaluation are still being performed, and will follow the priority order, if applicable. 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.

The duration of Temporary Delegation will be defined as part of the Name Collision process and criteria. Should it be found that a string is high-risk, it will be removed from the root zone and the applicant will have an opportunity to submit a Mitigation Plan for evaluation, which will allow the application to proceed if approved. Otherwise, the string will be added to the Collision String List. See more information in Section 7.7 Name Collision. The conclusion of Temporary Delegation is not necessary for other processes, such as Application and Applicant Evaluation or contention set resolution, to start. However, an application will be able to proceed to contracting only when Temporary Delegation is concluded and the Mitigation Plan is implemented, if applicable.

1.2.6 Publication of String Evaluation Reports and Contention Sets

Once the String Evaluation is completed, String Evaluation Reports for all applications, as well as an updated list of contention sets, will be posted to the New gTLD Program website.¹³

1.2.7 String Confusion Objections and Identification of Potential New Contention Sets

Expected duration: 30 days following publication of initial list of contention sets

As described in Section 4.5 Objections and Appeals, once String Evaluation has been completed and an updated list of contention sets published, there will be a second 30-day submission window for String Confusion Objections only. Applications that received a String Confusion Objection may create additional contention sets depending on the DRSP’s determination. Should new contention sets be created, they will be published to the New gTLD Program website.¹⁴

1.2.8 Community Priority Evaluation

• Conditional

Once all contention sets have been finalized (that is, changes are no longer possible to the composition of the set, other than when an applicant withdraws its application) and all applications in the contention set are eligible to proceed to contention resolution, Community Applicants in contention may elect to go through Community Priority Evaluation (CPE).¹⁵ CPE is an independent analysis conducted by an expert panel that determines whether a Community Application fulfills the CPE criteria. If an application meets the CPE criteria, it will receive priority in the contention set. More information on the process and criteria can be found in Section 5.4 Community Priority Evaluation.

1.2.9 ICANN New gTLD Auctions

ICANN will hold auctions to resolve string contention among applicants for new gTLDs. If an auction winner is ineligible to execute or does not execute a Registry Agreement with ICANN, ICANN may, at its discretion, offer the auction runner-up, if any, the opportunity to proceed with its application. More information can be found in Section 5.6 ICANN New gTLD Auction. For additional information regarding eligibility for contracting, see Section 1.2.15 Contracting. See also Module 6 Applicant Evaluation Procedures and Module 7 String and Application Evaluation Procedures for other applicable evaluations which a winning applicant must complete after a New gTLD Auction in order to proceed to contracting.

1.2.10 Applicant Evaluation

Applicant Evaluation occurs after the application has either (a) passed String Evaluation and is not part of a contention set, or (b) passed String Evaluation and has prevailed in the contention set. It is conducted in parallel with Application Evaluation based on the application’s priority number, unless other processes prevent the application from proceeding. See Module 6 Applicant Evaluation Procedures.

Applicant evaluation consists of two mandatory assessments, detailed below:

1.2.10.1 Background Screening

• Mandatory

Background screening is in place to protect the public interest in the allocation of critical Internet resources by ensuring that only established corporations, organizations, or institutions in good standing are allowed to operate a new gTLD. ICANN reserves the right to deny an otherwise qualified application based on findings from the background screening process. See Section 6.1 Background Screening.

1.2.10.2 Financial and Operational Evaluation

• Mandatory

The Financial and Operational Evaluation assesses whether an applicant has the financial and operational capacity to sustain the registry long-term and has implemented reasonable safeguards to ensure robust business operations and address abuse concerns.¹⁶ See Section 6.2 Financial and Operational Evaluation.

1.2.11 Application Evaluation

Expected Duration: See Section 1.5 Lifecycle Timelines

Application evaluation comprises the evaluations described below. Among these, only the Registry Service Provider Review is mandatory for all applications. The Registry Commitments Evaluation (RCE) is mandatory for all Community Applications, but conditional for other applications.

1.2.11.1 Registry Service Provider Review

• Mandatory

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). See Section 7.9 Registry Service Provider Review.

1.2.11.2 Geographic Names Review

• Conditional

A Geographic Names Panel will verify the relevance and authenticity of the supporting documentation for any application for a string determined to be a Geographic Name during the String Evaluation process, as described in Section 7.5.3.2 Geographic Names Review.

1.2.11.3 Reserved Names Review

• Conditional

The Reserved Names evaluation process will determine whether the appropriate organization has applied for the reserved string and will verify the supporting documentation, as described in Section 7.2.2 Reserved Names.

1.2.11.4 Name Collision High-Risk Mitigation Plan Evaluation

• Conditional

An applicant for a string that ICANN has deemed to present a high risk of Name Collision and has resolved contention may submit a High-Risk String Mitigation Plan for review. This plan will be reviewed by technical experts (see Section 7.7.5 Name Collision High-Risk Mitigation Plan Evaluation).

1.2.11.5 Registry Operator Code of Conduct Exemption Evaluation

• Conditional

The Registry Operator Code of Conduct (included in Specification 9 of the Registry Agreement) is a set of guidelines for the registry operator relating to certain and limited operations of a registry. If an applicant proposes to register all domain names in the gTLD exclusively for the registry operator’s own use or for use by its affiliates, and wishes to waive the protection for itself and its affiliates, ICANN may grant an exemption to the Code of Conduct provided the gTLD is not a generic string (see Section 3.1.7 Exclusive Use Strings (“Closed Generics”)) and the registry operator meets the exemption criteria (see Section 7.4 Registry Operator Code of Conduct Exemption Evaluation).

1.2.11.6 Registry Commitments Evaluation

• Conditional¹⁷

As described in 7.8.3.2 Registry Commitments Evaluation, each Registry Voluntary Commitment proposed by the applicant and each Registry Agreement Community Registration Policy (“Community Registration Policy”) proposed by the applicant for a Community gTLD for inclusion in the applicable Registry Agreement will be assessed by ICANN and published for an application comment period.

1.2.11.6.1 Registry Voluntary Commitments Evaluation

Each proposed Registry Voluntary Commitment (RVC) will undergo an ICANN evaluation. The objective of this evaluation is to determine whether the proposed RVC meets all the evaluation criteria as set out in Section 7.8.3.2 Registry Commitments Evaluation for ICANN’s approval to include the commitment in Specification 11 of the Base Registry Agreement.

1.2.11.6.2 Community Registration Policies Evaluation

Community Registration Policies, which all Community Applicants must propose during application submission, are subject to ICANN evaluation and approval before they can be included in Specification 12 of the Base Registry Agreement. More information can be found in Section 7.8.4 Community Registration Policies.

1.2.11.7 .Brand TLD Eligibility Evaluation

• Conditional

The purpose of the .Brand TLD Eligibility Evaluation is to confirm that the application meets the criteria for a .Brand TLD designation. A successful designation will result in Specification 13 being added to the applicant’s Registry Agreement, provided the applicant successfully completes all phases of evaluation. See Section 7.3 .Brand TLD Eligibility Evaluation.

An applicant for a .Brand TLD that is found in contention has the option to change its string and avoid further contention resolution procedures by completing a .Brand String Change Request, subject to the requirements set out in Section 5.3 .Brand String Change Requests.

1.2.11.8 Variant String Evaluation

• Conditional

An applicant seeking one or more allocatable variant string of an applied-for primary IDN or existing gTLD must justify the need for each applied-for variant string. This justification will be evaluated by a panel based on a general standard of reasonableness. See Section 7.6 Variant String Evaluation for more information. Variants will be included in Specification 14 of the Base Registry Agreement.

1.2.12 Clarifying Questions

Expected duration: Seven days for administrative questions; 21 days for substantive questions

During each Application and Applicant Evaluation,¹⁸ the respective evaluation panel may issue clarifying questions if it requires additional information to complete its evaluation, if it intends to fail an applicant, or if any of the application comments it considered may have an impact on the evaluation of the application. 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.²⁰

1.2.13 Publication of Application and Applicant Evaluation Reports

Application and Applicant Evaluation reports will be compiled after all required evaluations specific to an application are completed and will be published on a rolling basis.²¹ Certain processes, such as Application Change Requests, contention, or objections, may affect the timing of the publication of the reports.

1.2.14 Extended Evaluation and Evaluation Challenge

An extended evaluation or evaluation challenge is available for certain evaluations, as described below. There are no conditional fees associated with either process.

1.2.14.1 Extended Evaluation

Applicants that are unable to resolve issues through clarifying questions may be eligible to enter extended evaluation, which provides additional time and interaction to address outstanding concerns regarding a specific evaluation. Applicants may request extended evaluation within 15 days of notification of their Application and Applicant Evaluation results. Extended evaluation is conducted by the same set of evaluators who initially conducted the relevant evaluation. Where applicable, an evaluation panel may issue additional clarifying questions as part of extended evaluation.

The following evaluations can be subject to extended evaluation:

Table 1-1: Evaluations Subject to Extended Evaluation

1.2.14.2 Evaluation Challenge

The evaluation challenge mechanism allows applicants to challenge an evaluation result based on claims of procedural, factual, or system error in the automatic validations run by TAMS that may have led to an incorrect evaluation outcome. While applicants can provide documentary evidence of a perceived factual or procedural error, they are not allowed to submit any new information that would constitute a material change to the original application. Typically, the challenge mechanism does not provide for clarifying questions.

The challenge mechanism is subject to a “quick look” assessment. The panel may dismiss the challenge based on one or more of the criteria below:

• The challenge is not filed on one of the accepted grounds.

• The party filing the challenge is not the applicant.

• Insufficient or no evidence is provided to support the challenge.

• The challenge is far-fetched, clearly invented, or contrary to common sense.

• Duplicate or repeated challenges on the same ground for the same evaluation are filed by the applicant.

• Other facts that may clearly show that the challenge is manifestly unfounded or an abuse of the right to challenge.

See Table 1-2: Evaluations that Qualify for Challenge for an overview of the evaluations that qualify for a challenge, the deadline for requesting it, and the grounds.

Table 1-2: Evaluations that Qualify for Challenge

The Challenge Panel will communicate the result of the Pre-Submission String Validations within five days of an applicant filing the challenge. For the other evaluations listed in the table above, the Challenge Panel will communicate the result within 30 days of an applicant filing such a challenge.

For more detailed information on each evaluation and challenge type, see the sections linked in the table above. Each evaluation section provides additional details regarding the challenge process and its outcomes.

1.2.15 Contracting

Expected duration: Applicant must complete contracting no later than 90 days following the date of invitation to contracting

An applicant that successfully completes all the relevant stages outlined in this section must execute a Registry Agreement with ICANN to be eligible for the delegation of its applied-for string (and any variant strings, where applicable) into the DNS root zone. Applicants that pass the Application and Applicant Evaluation will be invited to provide additional contracting information, including the authorized signatory. At that time, applicants must also confirm that the statements and representations contained in the application and supplemented throughout the application process (including any documents or written materials submitted in connection with the application) remain true, accurate, and complete in all material respects as required by Section 3.8 Application Change Requests and the Terms and Conditions of this Guidebook (Appendix 10).

In parallel, ICANN will seek confirmation from an applicant’s identified RSP that it acknowledges plans to support that particular applicant and gTLD.

The Base Registry Agreement (Appendix 4) is the product of extensive community consultation. ICANN will only consider modification to the agreement in extraordinary circumstances, such as unique legal, jurisdictional, or regulatory issues that would legally prevent an entity from executing the Base Registry Agreement as-is. Applicants that request to negotiate limited amendments to the Base Registry Agreement will be required to provide a rationale justifying the need for such changes, along with a redline of the requested changes. Applicants must submit a negotiation request to ICANN as soon as possible in the process and no later than 15 days following the date of its invitation to contracting.

Where applicable, a Registry Agreement will include the following based on an applicant’s response to the application questions and evaluation results:

• Public Interest Commitments, including Registry Voluntary Commitments and Safeguards, are included in Specification 11.

• Community Registration Policies are included in Specification 12.

• Information on .Brand applications are included in Specification 13.

• Information on variant strings are included in Specification 14.

• Special Provision Relating to Intergovernmental Organizations or Governmental Entities are included in Article 7.

Absent extraordinary circumstances, applicants are required to execute the contract within 90 days from the time they are invited to start the contracting process.

1.2.16 Post Contracting

This Post-Contracting section provides new registry operators with resources to understand the requirements of launching and operating their gTLDs.

After successfully passing evaluation and signing a Registry Agreement with ICANN, the former new gTLD applicant’s operation of the gTLD will be governed by this Registry Agreement, which outlines the obligations between the registry operator and ICANN. Registry operators must complete onboarding activities for various ICANN systems and processes in accordance with the applicable Registry Agreement. This onboarding is critical for ensuring compliance with contractual obligations and operational responsibilities. New registry operators must delegate their TLD within one year from the date of Registry Agreement execution, except as described in Base Registry Agreement Section 2.19.

New registry operators are referred to the New gTLD Program website, which will provide comprehensive resources to help emerging registry operators navigate ICANN interactions and understand their contractual obligations. For additional information regarding delegation of gTLDs and the timeline for completion, review Section 1.2.15 Contracting and Appendix 4 Base Registry Agreement.

1.2.17 Dispute Resolution Procedures After Delegation

Post-delegation dispute resolution procedures provide an avenue for pursuing complaints against a registry operator's conduct.

Sometimes, a complainant may be required to take specific steps to address its issues before filing a formal complaint. ICANN or qualified third-party providers administer these dispute resolution procedures. An expert panel, if appointed, determines whether a registry operator is at fault and, if so, recommends remedies to ICANN.

Registry operators must comply with the dispute resolution mechanisms outlined in the Base Registry Agreement and agree to be bound by any determination by ICANN or the expert panel, and to implement and adhere to any remedies subsequently imposed by ICANN.

Currently, there are three post-delegation dispute resolution procedures:

1. Public Interest Commitments Dispute Resolution Procedure (PICDRP): The PICDRP addresses alleged complaints that a registry operator may not be complying with one or more Public Interest Commitments (PICs) or Registry Voluntary Commitments (RVCs) in its Registry Agreement. See Section 7.8 Public Interest Commitments, Registry Voluntary Commitments, and Community Registration Policies for further details about PICs and RVCs.

2. Registry Registration Dispute Resolution Procedure (RRDRP): The RRDRP addresses circumstances in which a Community gTLD registry operator allegedly deviates from the registration restrictions outlined in its Registry Agreement. A Community gTLD is operated for the benefit of a clearly delineated community. See Section 5.4 Community Priority Evaluation for further details about Community Applications.

3. Trademark Post-Delegation Dispute Resolution Procedure (TM-PDDRP): The TM-PDDRP generally addresses alleged complicity in trademark infringement on the first or second level of a gTLD. Among the three post-delegated dispute resolution procedures, only the TM-PDDRP is specifically intended to address trademark-related issues concerning registry operators. See Rights Protection Mechanisms²³ for further details about requirements for rights protection mechanisms for all gTLDs.

For more information about the scope of procedures, the roles of all parties, and the adjudication process with respect to these post-delegation dispute resolution procedures, see the Frequently Asked Questions on the New gTLD Program website,²⁴ as well as the Rights Protection Mechanisms (RPMs) & Dispute Resolutions Procedures (DRPs) information page.

1.3 Process Overview

Figure 1-1: Process Overview

1.4 Posted Materials

ICANN will post the following materials related to the submitted applications to the New gTLD Program website:

• Public portions of the applications

• Assigned Priority Number

• Application status and stage

• Applications with GAC Member Early Warnings and GAC Consensus Advice

• Statuses of objections and appeals

• Application Comments

• Changes to the public portion of the application due to Application Change Requests

• Evaluation result reports (String, Application and Applicant, and CPE)

• Name Collision Initial Assessment report

• Temporary Delegation report

• High-Risk Mitigation Plan and report

• Extended Evaluation and Evaluation Challenge reports

• Clarifying Questions (CQs) and Applicant’s CQ Responses for the public portions of the applications

• List of contention sets

• CPE election status

• Auction status and results

1.5 Lifecycle Timelines

The table below provides a high-level estimation of the duration of each process in months, based on the number of applications submitted. The indicated durations refer to a simple and standard application that is part of the first priority batch, not subject to GAC Consensus Advice, objections, or conditional evaluations, and not in contention or facing any other issues. Applications in later priority batches may be held until their designated processing time. Applicants with applications requiring conditional evaluations or that are subject to GAC Consensus Advice or have otherwise more complex applications may experience longer processing times.

Table 1-3: Estimated Duration of Each Process

*Estimated duration to complete onboarding and delegation will be provided at a later time.

The table below provides an estimation of the duration of some of the conditional processes an application may be subject to.

Table 1-4: Estimated Duration of Some Conditional Processes

These tables do not cover all possible scenarios, and a number of factors may influence the duration of each process. Metrics on the various processes will be posted to the New gTLD Program website²⁷ and regularly updated.