AT-LARGE GATEWAY
At-Large Regional Policy Engagement Program (ARPEP)
ALAC Liaisons and Representatives
At-Large Review Implementation Plan Development
Page History
Module 1
Introduction to the gTLD Application Process
This module gives applicants an overview of the process for applying for a new generic top-level domain, and includes instructions on how to complete and submit an application, the supporting documentation an applicant must submit with an application, the fees required, and when and how to submit them.
This module also describes the conditions associated with particular types of applications, and the stages of the application life cycle.
A glossary of relevant terms is included at the end of this Applicant Guidebook.
Prospective applicants are encouraged to read and become familiar with the contents of this entire module, as well as the others, before starting the application process to make sure they understand what is required of them and what they can expect at each stage of the application evaluation process.
For the complete set of the supporting documentation and more about the origins, history and details of the policy development background to the New gTLD Program, please see
Anchor | ||||
---|---|---|---|---|
|
This Applicant Guidebook is the implementation of Board-approved consensus policy concerning the introduction of new gTLDs, and has been revised extensively via public comment and consultation over a two-year period.
1.1Application Life Cycle and Timelines
This section provides a description of the stages that an application passes through once it is submitted. Some stages will occur for all applications submitted; others will only occur in specific circumstances. Applicants should be aware of the stages and steps involved in processing applications received.
1.1.1 Application Submission Dates
The application submission period opens at [time] UTC [date].
The application submission period closes at [time] UTC [date].
To receive consideration, all applications must be submitted electronically through the online application system by the close of the application submission period.
An application will not be considered, in the absence of exceptional circumstances, if:
- It is received after the close of the application submission period.
- The application form is incomplete (either the questions have not been fully answered or required supporting documents are missing). Applicants will not ordinarily be permitted to supplement their applications after submission.
- The evaluation fee has not been paid by the deadline. Refer to Section 1.5 for fee information.
ICANN has gone to significant lengths to ensure that the online application system will be available for the duration of the application submission period. In the event that the system is not available, ICANN will provide alternative instructions for submitting applications on its website.
1.1.2Application Processing Stages
This subsection provides an overview of the stages involved in processing an application submitted to ICANN. In Figure 1 1, the shortest and most straightforward path is marked with bold lines, while certain stages that may or may not be applicable in any given case are also shown. A brief description of each stage follows.
Figure 1-1 – Once submitted to ICANN, applications will pass through multiple stages of processing.
1.1.2.1Application Submission Period
At the time the application submission period opens, those wishing to submit new gTLD applications can become registered users of the TLD Application System (TAS).
After completing the registration, applicants will supply a deposit for each requested application slot (see section 1.4), after which they will receive access to the full application form. To complete the application, users will answer a series of questions to provide general information, demonstrate financial capability, and demonstrate technical and operational capability. The supporting documents listed in subsection 1.2.2 of this module must also be submitted through the application system as instructed in the relevant questions.
Applicants must also submit their evaluation fees during this period. Refer to Section 1.5 of this module for additional information about fees and payments.
Following the close of the application submission period, ICANN will provide applicants with periodic status updates on the progress of their applications.
1.1.2.2Administrative Completeness Check
Immediately following the close of the application submission period, ICANN will check all applications for completeness. This check ensures that:
- All mandatory questions are answered;
- Required supporting documents are provided in the proper format(s); and
- The evaluation fees have been received.
ICANN will post all applications considered complete and ready for evaluation as soon as practicable after the close of the application submission period. Certain questions relate to internal processes or information: applicant responses to these questions will not be posted. Each question is labeled in the application form as to whether the information will be posted. See the full set of questions in the attachment to Module 2. The administrative completeness check is expected to be completed for all applications in a period of approximately 4 weeks, subject to extension depending on volume. In the event that all applications cannot be processed within a 4-week period, ICANN will post updated process information and an estimated timeline.
1.1.2.3Initial Evaluation
Initial Evaluation will begin immediately after the administrative completeness check concludes. All complete applications will be reviewed during Initial Evaluation. At the beginning of this period, background screening on the applying entity and the individuals named in the application will be conducted. Applications must pass this step before the Initial Evaluation reviews are carried out.
There are two main elements of the Initial Evaluation:
- String reviews (concerning the applied-for gTLD string). String reviews include a determination that the applied-for gTLD string is not likely to cause security or stability problems in the DNS, including problems caused by similarity to existing TLDs or reserved names.
- Applicant reviews (concerning the entity applying for the gTLD and its proposed registry services). Applicant reviews include a determination of whether the applicant has the requisite technical, operational, and financial capability to operate a registry.
By the conclusion of the Initial Evaluation period, ICANN will post notice of all Initial Evaluation results. Depending on the volume of applications received, such notices may be posted in batches over the course of the Initial Evaluation period.
Anchor | ||||
---|---|---|---|---|
|
The Initial Evaluation is expected to be completed for all applications in a period of approximately 5 months. If the volume of applications received significantly exceeds 500, applications will be processed in batches and the 5-month timeline will not be met. The first batch will be limited to 500 applications and subsequent batches will be limited to 400 to account for capacity limitations due to managing extended evaluation, string contention, and other processes associated with each previous batch.
A process external to the application submission process will be employed to establish evaluation priority. This process will be based on an online ticketing system or other objective criteria.
If batching is required, the String Similarity review will be completed on all applications prior to the establishment of evaluation priority batches. For applications identified as part of a contention set, the entire contention set will be kept together in the same batch.
If batches are established, ICANN will post updated process information and an estimated timeline.
Note that the processing constraints will limit delegation rates to a steady state even in the event of an extremely high volume of applications. The annual delegation rate will not exceed 1,000 per year in any case, no matter how many applications are received. See the paper "Delegation Rate Scenarios for New gTLDs" at http://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdf for additional discussion.
1.1.2.4Objection Filing
Formal objections to applications can be filed on any of four enumerated grounds, by parties with standing to object. The objection filing period will open after ICANN posts the list of complete applications as described in subsection 1.1.2.2, and will last for approximately 5 ½ months.
Objectors must file such formal objections directly with dispute resolution service providers (DRSPs), not with ICANN. The objection filing period will close following the end of the Initial Evaluation period (refer to subsection 1.1.2.3), with a two-week window of time between the posting of the Initial Evaluation results and the close of the objection filing period. Objections that have been filed during the objection filing period will be addressed in the dispute resolution stage, which is outlined in subsection 1.1.2.7 and discussed in detail in Module 3.
All applicants should be aware that third parties have the opportunity to file objections to any application during the objection filing period. Applicants whose applications are the subject of a formal objection will have an opportunity to file a response according to the dispute resolution service provider's rules and procedures. An applicant wishing to file a formal objection to another application that has been submitted would do so within the objection filing period, following the objection filing procedures in Module 3.
Applicants are encouraged to identify possible potential regional, cultural, property interests, or other sensitivities regarding TLD strings and their uses before applying and, where possible, identify and consult with interested parties to mitigate any concerns in advance.
1.1.2.5Public Comment
Public comment mechanisms are part of ICANN's policy development, implementation and operational processes. As a private-public partnership, ICANN is dedicated to: preserving the operational security and stability of the Internet, promoting competition, achieving broad representation of global Internet communities, and developing policy appropriate to its mission through bottom-up, consensus-based processes. This necessarily involves the participation of many stakeholder groups in a public discussion review.
In the new gTLD application process, all applicants should be aware that public comment fora are a mechanism for the public to bring relevant information and issues to the attention of those charged with handling new gTLD applications. Anyone may submit a comment in a public comment forum.
ICANN will open a public comment period at the time applications are publicly posted on ICANN's website (refer to subsection 1.1.2.2), which will remain open for 45 calendar days. This period will allow time for the community to review and submit comments on posted application materials, and will allow for subsequent consolidation of the received comments, distribution to the evaluator panels performing reviews, and analysis and consideration and evaluation of the comments by the evaluators within the 5-month timeframe allotted for Initial Evaluation. This public comment period is subject to extension, should the volume of applications or other circumstances require. To be considered by evaluators, comments must be received in the designated public comment forum within the stated time period.
Comments received during the public comment period will be tagged to a specific application. Evaluators will perform due diligence on the comments (i.e., determine their relevance to the evaluation, verify the accuracy of claims, analyze meaningfulness of references cited) and take the information provided in these comments into consideration. Consideration of the applicability of the information submitted through public comments will be included in the evaluators' reports.
A general public comment forum will remain open through all stages of the evaluation process, to provide a means for the public to bring forward any other relevant information or issues.
A distinction should be made between public comments, which may be relevant to ICANN's task of determining whether applications meet the established criteria, and formal objections that concern matters outside those evaluation criteria. The formal objection process was created to allow a full and fair consideration of objections based on certain limited grounds outside ICANN's evaluation of applications on their merits. Public comments associated with formal objections will not be considered by panels during Initial Evaluation; however, they may be subsequently considered by an expert panel during a dispute resolution proceeding (see subsection 1.1.2.7).
Governments may provide a notification using the public comment forum to communicate concerns relating to national laws. However, a government's notification of concern will not in itself be deemed to be a formal objection. A notification by a government does not constitute grounds for rejection of a gTLD application.
Governments may also communicate directly to applicants using the contact information posted in the application, e.g., to send a notification that an applied-for gTLD string might be contrary to a national law, and to try to address any concerns with the applicant.
As noted above, applicants are encouraged to identify potential sensitivities in advance and work with the relevant parties to mitigate concerns related to the application.
1.1.2.6Extended Evaluation
Extended Evaluation is available only to certain applicants that do not pass Initial Evaluation.
Applicants failing certain elements of the Initial Evaluation can request an Extended Evaluation. If the applicant does not pass Initial Evaluation and does not expressly request an Extended Evaluation, the application will proceed no further. The Extended Evaluation period allows for an additional exchange of information between the applicant and evaluators to clarify information contained in the application. The reviews performed in Extended Evaluation do not introduce additional evaluation criteria.
An application may be required to enter an Extended Evaluation if one or more proposed registry services raise technical issues that might adversely affect the security or stability of the DNS. The Extended Evaluation period provides a time frame for these issues to be investigated. Applicants will be informed if such a review is required by the end of the Initial Evaluation period.
Evaluators and any applicable experts consulted will communicate the conclusions resulting from the additional review by the end of the Extended Evaluation period.
At the conclusion of the Extended Evaluation period, ICANN will post summary reports, by panel, from the Initial and Extended Evaluation periods.
If an application passes the Extended Evaluation, it can then proceed to the next relevant stage. If the application does not pass the Extended Evaluation, it will proceed no further.
The Extended Evaluation is expected to be completed for all applications in a period of approximately 5 months, though this timeframe could be increased based on volume. In this event, ICANN will post updated process information and an estimated timeline.
1.1.2.7Dispute Resolution
Dispute resolution applies only to applicants whose applications are the subject of a formal objection.
Where formal objections are filed and filing fees paid during the objection filing period, independent dispute resolution service providers (DRSPs) will initiate and conclude proceedings based on the objections received. The formal objection procedure exists to provide a path for those who wish to object to an application that has been submitted to ICANN. Dispute resolution service providers serve as the fora to adjudicate the proceedings based on the subject matter and the needed expertise. Consolidation of objections filed will occur where appropriate, at the discretion of the DRSP.
Public comments may also be relevant to one or more objection grounds. (Refer to Module 3, Dispute Resolution Procedures, for the objection grounds.) The DRSPs will have access to all public comments received, and will have discretion to consider them.
As a result of a dispute resolution proceeding, either the applicant will prevail (in which case the application can proceed to the next relevant stage), or the objector will prevail (in which case either the application will proceed no further or the application will be bound to a contention resolution procedure). In the event of multiple objections, an applicant must prevail in all dispute resolution proceedings concerning the application to proceed to the next relevant stage. Applicants will be notified by the DRSP(s) of the results of dispute resolution proceedings.
Dispute resolution proceedings, where applicable, are expected to be completed for all applications within approximately a 5-month time frame. In the event that volume is such that this timeframe cannot be accommodated, ICANN will work with the dispute resolution service providers to create processing procedures and post updated timeline information.
1.1.2.8String Contention
String contention applies only when there is more than one qualified application for the same or similar gTLD strings.
String contention refers to the scenario in which there is more than one qualified application for the identical gTLD string or for similar gTLD strings. In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
Applicants are encouraged to resolve string contention cases among themselves prior to the string contention resolution stage. In the absence of resolution by the contending applicants, string contention cases are resolved either through a community priority evaluation (if a community-based applicant elects it) or through an auction.
In the event of contention between applied-for gTLD strings that represent geographical names, the parties may be required to follow a different process to resolve the contention. See subsection 2.2.1.4 of Module 2 for more information.
Groups of applied-for strings that are either identical or similar are called contention sets. All applicants should be aware that if an application is identified as being part of a contention set, string contention resolution procedures will not begin until all applications in the contention set have completed all aspects of evaluation, including dispute resolution, if applicable.
To illustrate, as shown in Figure 1-2, Applicants A, B, and C all apply for .EXAMPLE and are identified as a contention set. Applicants A and C pass Initial Evaluation, but Applicant B does not. Applicant B requests Extended Evaluation. A third party files an objection to Applicant C's application, and Applicant C enters the dispute resolution process. Applicant A must wait to see whether Applicants B and C successfully complete the Extended Evaluation and dispute resolution phases, respectively, before it can proceed to the string contention resolution stage. In this example, Applicant B passes the Extended Evaluation, but Applicant C does not prevail in the dispute resolution proceeding. String contention resolution then proceeds between Applicants A and B.
Figure 1-2 – All applications in a contention set must complete all previous evaluation and dispute resolution stages before string contention resolution can begin.
Applicants prevailing in a string contention resolution procedure will proceed toward delegation of the applied-for gTLDs.
In the event of a community priority evaluation (see Module 4, String Contention Procedures), ICANN will provide the comments received during the public comment period to the evaluators with instructions to take the relevant information into account in reaching their conclusions.
String contention resolution for a contention set is estimated to take from 2.5 to 6 months to complete. The time required will vary per case because some contention cases may be resolved in either a community priority evaluation or an auction, while others may require both processes.
1.1.2.9Transition to Delegation
Applicants successfully completing all the relevant stages outlined in this subsection 1.1.2 are required to carry out a series of concluding steps before delegation of the applied-for gTLD into the root zone. These steps include execution of a registry agreement with ICANN and completion of a pre-delegation technical test to validate information provided in the application.
Following execution of a registry agreement, the prospective registry operator must complete technical set-up and show satisfactory performance on a set of technical tests before delegation of the gTLD into the root zone may be initiated. If the pre-delegation testing requirements are not satisfied so that the gTLD can be delegated into the root zone within the time frame specified in the registry agreement, ICANN may in its sole and absolute discretion elect to terminate the registry agreement.
Once all of these steps have been successfully completed, the applicant is eligible for delegation of its applied-for gTLD into the DNS root zone.
It is expected that the transition to delegation steps can be completed in approximately 2 months, though this could take more time depending on the applicant's level of preparedness for the pre-delegation testing and the volume of applications undergoing these steps concurrently.
1.1.3 Lifecycle Timelines
Based on the estimates for each stage described in this section, the lifecycle for a straightforward application could be approximately 8 months, as follows:
Figure 1-3 – A straightforward application could have an approximate 8-month lifecycle.
The lifecycle for a highly complex application could be much longer, such as 19 months in the example below:
Figure 1-4 – A complex application could have an approximate 19-month lifecycle.
1.1.4Posting Periods
The results of application reviews will be made available to the public at various stages in the process, as shown below.
Period | Posting Content |
End of Administrative Check | Public portions of all applications that have passed the Administrative Completeness Check. |
During Initial Evaluation | Status updates for applications withdrawn or ineligible for further review. |
End of Initial Evaluation | Application status updates with all Initial Evaluation results. |
End of Extended Evaluation | Application status updates with all Extended Evaluation results. |
During Objection Filing/Dispute Resolution | Information on filed objections and status updates available via Dispute Resolution Service Provider websites. |
During Contention Resolution (Community Priority Evaluation) | Results of each Community Priority Evaluation posted as completed. |
During Contention Resolution (Auction) | Results from each auction posted as completed. |
Transition to Delegation | Registry Agreements posted when executed. |
1.1.5Sample Application Scenarios
The following scenarios briefly show a variety of ways in which an application may proceed through the evaluation process. The table that follows exemplifies various processes and outcomes. This is not intended to be an exhaustive list of possibilities. There are other possible combinations of paths an application could follow.
Estimated time frames for each scenario are also included, based on current knowledge. Actual time frames may vary depending on several factors, including the total number of applications received by ICANN during the application submission period. It should be emphasized that most applications are expected to pass through the process in the shortest period of time, i.e., they will not go through extended evaluation, dispute resolution, or string contention resolution processes. Although most of the scenarios below are for processes extending beyond eight months, it is expected that most applications will complete the process within the eight-month timeframe.
Scenario Number | Initial Eval-uation | Extended Eval-uation | Objec-tion(s) Filed | String Conten-tion | Ap-proved for Dele-gation Steps | Esti-mated Elapsed Time |
1 | Pass | N/A | None | No | Yes | 8 months |
2 | Fail | Pass | None | No | Yes | 13 months |
3 | Pass | N/A | None | Yes | Yes | 10.5 – 14 months |
4 | Pass | N/A | Applicant prevails | No | Yes | 13 months |
5 | Pass | N/A | Objector prevails | N/A | No | 11 months |
6 | Fail | Quit | N/A | N/A | No | 6 months |
7 | Fail | Fail | N/A | N/A | No | 11 months |
8 | Fail | Pass | Applicant prevails | Yes | Yes | 15.5 – 19 months |
9 | Fail | Pass | Applicant prevails | Yes | No | 13.5 – 17 months |
Scenario 1 – Pass Initial Evaluation, No Objection, No Contention – In the most straightforward case, the application passes Initial Evaluation and there is no need for an Extended Evaluation. No objections are filed during the objection period, so there is no dispute to resolve. As there is no contention for the applied-for gTLD string, the applicant can enter into a registry agreement and the application can proceed toward delegation of the applied-for gTLD. Most applications are expected to complete the process within this timeframe.
Scenario 2 – Extended Evaluation, No Objection, No Contention – In this case, the application fails one or more aspects of the Initial Evaluation. The applicant is eligible for and requests an Extended Evaluation for the appropriate elements. Here, the application passes the Extended Evaluation. As with Scenario 1, no objections are filed during the objection period, so there is no dispute to resolve. As there is no contention for the gTLD string, the applicant can enter into a registry agreement and the application can proceed toward delegation of the applied-for gTLD.
Scenario 3 – Pass Initial Evaluation, No Objection, Contention – In this case, the application passes the Initial Evaluation so there is no need for Extended Evaluation. No objections are filed during the objection period, so there is no dispute to resolve. However, there are other applications for the same or a similar gTLD string, so there is contention. In this case, the application prevails in the contention resolution, so the applicant can enter into a registry agreement and the application can proceed toward delegation of the applied-for gTLD.
Scenario 4 – Pass Initial Evaluation, Win Objection, No Contention – In this case, the application passes the Initial Evaluation so there is no need for Extended Evaluation. During the objection filing period, an objection is filed on one of the four enumerated grounds by an objector with standing (refer to Module 3, Dispute Resolution Procedures). The objection is heard by a dispute resolution service provider panel that finds in favor of the applicant. The applicant can enter into a registry agreement and the application can proceed toward delegation of the applied-for gTLD.
Scenario 5 – Pass Initial Evaluation, Lose Objection – In this case, the application passes the Initial Evaluation so there is no need for Extended Evaluation. During the objection period, multiple objections are filed by one or more objectors with standing for one or more of the four enumerated objection grounds. Each objection is heard by a dispute resolution service provider panel. In this case, the panels find in favor of the applicant for most of the objections, but one finds in favor of the objector. As one of the objections has been upheld, the application does not proceed.
Scenario 6 – Fail Initial Evaluation, Applicant Withdraws – In this case, the application fails one or more aspects of the Initial Evaluation. The applicant decides to withdraw the application rather than continuing with Extended Evaluation. The application does not proceed.
Scenario 7 – Fail Initial Evaluation, Fail Extended Evaluation – In this case, the application fails one or more aspects of the Initial Evaluation. The applicant requests Extended Evaluation for the appropriate elements. However, the application fails Extended Evaluation also. The application does not proceed.
Scenario 8 – Extended Evaluation, Win Objection, Pass Contention – In this case, the application fails one or more aspects of the Initial Evaluation. The applicant is eligible for and requests an Extended Evaluation for the appropriate elements. Here, the application passes the Extended Evaluation. During the objection filing period, an objection is filed on one of the four enumerated grounds by an objector with standing. The objection is heard by a dispute resolution service provider panel that finds in favor of the applicant. However, there are other applications for the same or a similar gTLD string, so there is contention. In this case, the applicant prevails over other applications in the contention resolution procedure, the applicant can enter into a registry agreement, and the application can proceed toward delegation of the applied-for gTLD.
Scenario 9 – Extended Evaluation, Objection, Fail Contention – In this case, the application fails one or more aspects of the Initial Evaluation. The applicant is eligible for and requests an Extended Evaluation for the appropriate elements. Here, the application passes the Extended Evaluation. During the objection filing period, an objection is filed on one of the four enumerated grounds by an objector with standing. The objection is heard by a dispute resolution service provider that finds in favor of the applicant. However, there are other applications for the same or a similar gTLD string, so there is contention. In this case, another applicant prevails in the contention resolution procedure, and the application does not proceed.
Transition to Delegation – After an application has successfully completed Initial Evaluation, and other stages as applicable, the applicant is required to complete a set of steps leading to delegation of the gTLD, including execution of a registry agreement with ICANN, and completion of pre-delegation testing. Refer to Module 5 for a description of the steps required in this stage.
1.1.6 Subsequent Application Rounds
ICANN's goal is to launch subsequent gTLD application rounds as quickly as possible. The exact timing will be based on experiences gained and changes required after this round is completed. The goal is for the next application round to begin within one year of the close of the application submission period for the initial round.
1.2 Information for All Applicants
1.2.1 Eligibility
Established corporations, organizations, or institutions in good standing may apply for a new gTLD. Applications from individuals or sole proprietorships will not be considered. Applications from or on behalf of yet-to-be-formed legal entities, or applications presupposing the future formation of a legal entity (for example, a pending Joint Venture) will not be considered.
ICANN has designed the New gTLD Program with multiple stakeholder protection mechanisms. Background screening, features of the gTLD Registry Agreement, data and financial escrow mechanisms are all intended to provide registrant and user protections.
The application form requires applicants to provide information on the legal establishment of the applying entity, as well as the identification of directors, officers, partners, and major shareholders of that entity.
Background screening at both the entity level and the individual level will be conducted for all applications to confirm eligibility. This inquiry is conducted on the basis of the information provided in questions 1-11 of the application form.
ICANN will perform background screening in only two areas: (1) General business diligence and criminal history; and (2) History of cybersquatting behavior. The criteria used for criminal history are aligned with the "crimes of trust" standard sometimes used in the banking and finance industry.
Background screening is in place to protect the public interest in the allocation of critical Internet resources, and ICANN reserves the right to deny an otherwise qualified application, or to contact the applicant with additional questions, based on the information obtained in the background screening process.
Applicants with confirmed convictions of the types listed in (a) – (k) below will be automatically disqualified from the program.
Circumstances where ICANN may deny an otherwise qualified application include, but are not limited to instances where the applicant, or any individual named in the application:
Anchor | ||||
---|---|---|---|---|
|
- within the past ten years, has been convicted of a felony, or of a misdemeanor related to financial or corporate governance activities, or has been judged by a court to have committed fraud or breach of fiduciary duty, or has been the subject of a judicial determination that ICANN deemed as the substantive equivalent of any of these;
Anchor id.d8d227b00b71 id.d8d227b00b71 - within the past ten years, has been disciplined by any government or industry regulatory body for conduct involving dishonesty or misuse of the funds of others;
- within the past ten years has been convicted of any willful tax-related fraud or willful evasion of tax liabilities;
- within the past ten years has been convicted of perjury, forswearing, failing to cooperate with a law enforcement investigation, or making false statements to a law enforcement agency or representative;
- has ever been convicted of any crime involving the use of a weapon, force, or the threat of force;
- has ever been convicted of any violent or sexual offense victimizing children, the elderly, or individuals with disabilities;
- has been convicted of aiding, abetting, facilitating, enabling, conspiring to commit, or failing to report any of the listed crimes within the respective timeframes specified above;
has entered a guilty plea as part of a plea agreement or has a court case in any jurisdiction with a disposition of Adjudicated Guilty or Adjudication Withheld (or regional equivalents) for any of the listed crimes within the respective timeframes listed above;Anchor id.43b71d8c5fac id.43b71d8c5fac Anchor id.a4000c353622 id.a4000c353622 - is the subject of a disqualification imposed by ICANN and in effect at the time the application is considered;
- fails to provide ICANN with the identifying information necessary to confirm identity at the time of application or to resolve questions of identity during the background screening process;
has been involved in of a pattern of decisions indicating that the applicant or individual named in the application was engaged in cybersquatting as defined in the UDRP, ACPA, or other equivalent legislation. Three or more such decisions with one occurring in the last four years will generally be considered to constitute a pattern.Anchor id.73524be22267 id.73524be22267
- fails to provide a good faith effort to disclose all relevant information relating to items (a) – (k).
All applicants are required to provide complete and detailed explanations regarding any of the above events as part of the application. Crimes of a personal nature that do not meet any of the criteria listed in (a) – (k) will not be considered for the purpose of criminal background screening and do not need to be disclosed. Background screening information will not be made publicly available by ICANN.
Registrar Cross-Ownership -- ICANN-accredited registrars are eligible to apply for a gTLD. However, all gTLD registries are required to abide by a Code of Conduct addressing, inter alia, non-discriminatory access for all authorized registrars. ICANN reserves the right to refer any application to the appropriate competition authority relative to any cross-ownership issues.
Legal Compliance -- ICANN must comply with all U.S. laws, rules, and regulations. One such set of regulations is the economic and trade sanctions program administered by the Office of Foreign Assets Control ("OFAC") of the U.S. Department of the Treasury. These sanctions have been imposed on certain countries, as well as individuals and entities that appear on OFAC's List of Specially Designated Nationals and Blocked Persons (the "SDN List"). ICANN is prohibited from providing most goods or services to residents of sanctioned countries or their governmental entities or to SDNs without an applicable U.S. government authorization or exemption. ICANN generally will not seek a license to provide goods or services to an individual or entity on the SDN List. In the past, when ICANN has been requested to provide services to individuals or entities that are not SDNs, but are residents of sanctioned countries, ICANN has sought and been granted licenses as required. In any given case, however, OFAC could decide not to issue a requested license.
1.2.2Required Documents
All applicants should be prepared to submit the following documents, which are required to accompany each application:
- Proof of legal establishment – Documentation of the applicant's establishment as a specific type of entity in accordance with the applicable laws of its jurisdiction.
- Financial statements. Applicants must provide audited or independently certified financial statements for the most recently completed fiscal year for the applicant. In some cases, unaudited financial statements may be provided.
- Supporting documentation should be submitted in the original language. English translations are not required.
All documents must be valid at the time of submission. Refer to the Evaluation Criteria, attached to Module 2, for additional details on the requirements for these documents.
Some types of supporting documentation are required only in certain cases:
- Community endorsement – If an applicant has designated its application as community-based (see section 1.2.3), it will be asked to submit a written endorsement of its application by one or more established institutions representing the community it has named. An applicant may submit written endorsements from multiple institutions. If applicable, this will be submitted in the section of the application concerning the community-based designation.
- Government support or non-objection – If an applicant has applied for a gTLD string that is a geographic name, the applicant is required to submit a statement of support for or non-objection to its application from the relevant governments or public authorities. Refer to subsection 2.2.1.4 for more information on the requirements for geographical names. If applicable, this will be submitted in the geographic names section of the application.
- Documentation of third-party funding commitments – If an applicant lists funding from third parties in its application, it must provide evidence of commitment by the party committing the funds. If applicable, this will be submitted in the financial section of the application.
1.2.3Community-Based Designation
All applicants are required to designate whether their application is community-based.
1.2.3.1Definitions
For purposes of this Applicant Guidebook, a community-based gTLD is a gTLD that is operated for the benefit of a clearly delineated community. Designation or non-designation of an application as community-based is entirely at the discretion of the applicant. Any applicant may designate its application as community-based; however, each applicant making this designation is asked to substantiate its status as representative of the community it names in the application by submission of written endorsements in support of the application. Additional information may be requested in the event of a community priority evaluation (refer to section 4.2 of Module 4). An applicant for a community-based gTLD is expected to:
- Demonstrate an ongoing relationship with a clearly delineated community.
- Have applied for a gTLD string strongly and specifically related to the community named in the application.
- Have proposed dedicated registration and use policies for registrants in its proposed gTLD, including appropriate security verification procedures, commensurate with the community-based purpose it has named.
- Have its application endorsed in writing by one or more established institutions representing the community it has named.
For purposes of differentiation, an application that has not been designated as community-based will be referred to hereinafter in this document as a standard application. A standard gTLD can be used for any purpose consistent with the requirements of the application and evaluation criteria, and with the registry agreement. A standard applicant may or may not have a formal relationship with an exclusive registrant or user population. It may or may not employ eligibility or use restrictions. Standard simply means here that the applicant has not designated the application as community-based.
1.2.3.2 Implications of Application Designation
Applicants should understand how their designation as community-based or standard will affect application processing at particular stages, and, if the application is successful, execution of the registry agreement and subsequent obligations as a gTLD registry operator, as described in the following paragraphs.
Objection / Dispute Resolution – All applicants should understand that an objection may be filed against any application on community grounds, even if the applicant has not designated itself as community-based or declared the gTLD to be aimed at a particular community. Refer to Module 3, Dispute Resolution Procedures.
String Contention – Resolution of string contention may include one or more components, depending on the composition of the contention set and the elections made by community-based applicants.
- A settlement between the parties can occur at any time after contention is identified. The parties will be encouraged to meet with an objective to settle the contention. Applicants in contention always have the opportunity to resolve the contention voluntarily, resulting in the withdrawal of one or more applications, before reaching the contention resolution stage.
- A community priority evaluation will take place only if a community-based applicant in a contention set elects this option. All community-based applicants in a contention set will be offered this option in the event that there is contention remaining after the applications have successfully completed all previous evaluation stages.
- An auction will result for cases of contention not resolved by community priority evaluation or agreement between the parties. Auction occurs as a contention resolution means of last resort. If a community priority evaluation occurs but does not produce a clear winner, an auction will take place to resolve the contention.
Refer to Module 4, String Contention Procedures, for detailed discussions of contention resolution procedures.
Contract Execution and Post-Delegation – A community-based applicant will be subject to certain post-delegation contractual obligations to operate the gTLD in a manner consistent with the restrictions associated with its community-based designation. ICANN must approve all material changes to the contract, including changes to community-based nature of the gTLD and any associated provisions.
Community-based applications are intended to be a narrow category, for applications where there are unambiguous associations among the applicant, the community served, and the applied-for gTLD string. Evaluation of an applicant's designation as community-based will occur only in the event of a contention situation that results in a community priority evaluation. However, any applicant designating its application as community-based will, if the application is approved, be bound by the registry agreement to implement the community-based restrictions it has specified in the application. This is true even if there are no contending applicants.
1.2.3.3Changes to Application Designation
An applicant may not change its designation as standard or community-based once it has submitted a gTLD application for processing.
1.2.4 Notice concerning Technical Acceptance Issues with New gTLDs
All applicants should be aware that approval of an application and entry into a registry agreement with ICANN do not guarantee that a new gTLD will immediately function throughout the Internet. Past experience indicates that network operators may not immediately fully support new top-level domains, even when these domains have been delegated in the DNS root zone, since third-party software modification may be required and may not happen immediately.
Similarly, software applications sometimes attempt to validate domain names and may not recognize new or unknown top-level domains. ICANN has no authority or ability to require that software accept new top-level domains, although it does prominently publicize which top-level domains are valid and has developed a basic tool to assist application providers in the use of current root-zone data.
ICANN encourages applicants to familiarize themselves with these issues and account for them in their startup and launch plans. Successful applicants may find themselves expending considerable efforts working with providers to achieve acceptance of their new top-level domain.
Applicants should review http://www.icann.org/en/topics/TLD-acceptance/ for background. IDN applicants should also review the material concerning experiences with IDN test strings in the root zone (see http://idn.icann.org/).
1.2.5 Notice concerning TLD Delegations
ICANN is only able to create TLDs as delegations in the DNS root zone, expressed using NS records with any corresponding DS records and glue records. There is no policy enabling ICANN to place TLDs as other DNS record types (such as A, MX, or DNAME records) in the root zone.
1.2.6 Terms and Conditions
All applicants must agree to a standard set of Terms and Conditions for the application process. The Terms and Conditions are available in Module 6 of this guidebook.
1.2.7 Notice of Changes to Information
If at any time during the evaluation process information previously submitted by an applicant becomes untrue or inaccurate, the applicant must promptly notify ICANN via submission of the appropriate forms. This includes applicant-specific information such as changes in financial position and changes in ownership or control of the applicant.
ICANN reserves the right to require a re-evaluation of the application in the event of a material change. This could involve additional fees or evaluation in a subsequent application round.
Failure to notify ICANN of any change in circumstances that would render any information provided in the application false or misleading may result in denial of the application.
1.2.8 Voluntary Designation for High Security Zones
ICANN and its stakeholders are currently developing a special designation for "High Security Zone Top Level Domains" ("HSTLDs"). This work is currently focusing on developing a standard for possible adoption by an international standards body who can administer audits and certifications on an independent basis.
This voluntary designation is for top-level domains that demonstrate and uphold enhanced security-minded practices and policies. While any registry operator, including successful new gTLD applicants, will be eligible to participate in this program, its development and operation are beyond the scope of this guidebook. An applicant's election to pursue an HSTLD designation is entirely independent of the evaluation process and will require completion of an additional set of requirements.
For more information on the HSTLD program, including current program development material and activities, please refer to http://www.icann.org/en/topics/new-gtlds/hstld-program-en.htm.
1.2.9Security and Stability
Root Scaling: There has been significant study, analysis, and consultation in preparation for launch of the New gTLD Program: indicating that the addition of gTLDs to the root zone will not negatively impact the security or stability of the DNS.
It is estimated that 200-300 TLDs will be delegated annually, and determined that in no case will more than 1000 new gTLDs be added to the root zone in a year. The delegation rate analysis, consultations with the technical community, and anticipated normal operational upgrade cycles all lead to the conclusion that the new gTLD delegations will have no significant impact on the stability of the root system. However, all applicants should be aware that delegation of any new gTLDs is conditional on the continued absence of significant negative impact on the security or stability of the DNS.
1.2.10Resources for Applicant Assistance
A variety of support resources are available to gTLD applicants. More information will be available on ICANN's website at http://www.icann.org/en/topics/new-gtld-program.htm. The Joint SO/AC New gTLD Applicant Support Working Group is currently developing recommendations for support resources that may be available to gTLD applicants. Information on these resources will be published on the ICANN website once identified.
1.3Information for Internationalized Domain Name Applicants
Some applied-for gTLD strings are expected to be Internationalized Domain Names (IDNs). IDNs are domain names including characters used in the local representation of languages not written with the basic Latin alphabet (a - z), European-Arabic digits (0 - 9), and the hyphen . As described below, IDNs require the insertion of A-labels into the DNS root zone.
1.3.1 IDN-Specific Requirements
An applicant for an IDN string must provide information indicating compliance with the IDNA protocol and other technical requirements. The IDNA protocol and its documentation can be found at http://icann.org/en/topics/idn/rfcs.htm.
Applicants must provide applied-for gTLD strings in the form of both a U-label (the IDN TLD in local characters) and an A-label.
An A-label is the ASCII form of an IDN label. Every IDN A-label begins with the IDNA ACE prefix, "xn--", followed by a string that is a valid output of the Punycode algorithm, making a maximum of 63 total ASCII characters in length. The prefix and string together must conform to all requirements for a label that can be stored in the DNS including conformance to the LDH (host name) rule described in RFC 1034, RFC 1123, and elsewhere.
A U-label is the Unicode form of an IDN label, which a user expects to see displayed in applications.
For example, using the current IDN test string in Cyrillic script, the U-label is <испытание> and the A-label is <xn--80akhbyknj4f>. An A-label must be capable of being produced by conversion from a U-label and a U-label must be capable of being produced by conversion from an A-label.
Applicants for IDN gTLDs will also be required to provide the following at the time of the application:
- Meaning or restatement of string in English. The applicant will provide a short description of what the string would mean or represent in English.
- Language of label (ISO 639-1). The applicant will specify the language of the applied-for TLD string, both according to the ISO codes for the representation of names of languages and in English.
- Script of label (ISO 15924). The applicant will specify the script of the applied-for gTLD string, both according to the ISO codes for the representation of names of scripts, and in English.
- Unicode code points. The applicant will list all the code points contained in the U-label according to its Unicode form.
- Applicants must further demonstrate that they have made reasonable efforts to ensure that the encoded IDN string does not cause any rendering or operational problems. For example, problems have been identified in strings with characters of mixed right-to-left and left-to-right directionality when numerals are adjacent to the path separator (i.e., the dot). See examples at http://stupid.domain.name/node/683
- If an applicant is applying for a string with known issues, it should document steps that will be taken to mitigate these issues in applications. While it is not possible to ensure that all rendering problems are avoided, it is important that as many as possible are identified early and that the potential registry operator is aware of these issues. Applicants can become familiar with these issues by understanding the IDNA protocol (see http://www.icann.org/en/topics/idn/rfcs.htm), and by active participation in the IDN wiki (see http://idn.icann.org/) where some rendering problems are demonstrated.
- [Optional] - Representation of label in phonetic alphabet. The applicant may choose to provide its applied-for gTLD string notated according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/). Note that this information will not be evaluated or scored. The information, if provided, will be used as a guide to ICANN in responding to inquiries or speaking of the application in public presentations.
1.3.2IDN Tables
- An IDN table provides the list of characters eligible for registration in domain names according to the registry's policy. It identifies any multiple characters that are considered equivalent for domain name registration purposes ("variant characters"). Variant characters occur where two or more characters can be used interchangeably.
Examples of IDN tables can be found in the IANA IDN Repository at http://www.iana.org/procedures/idn-repository.html.
In the case of an application for an IDN gTLD, IDN tables must be submitted for the language or script for the applied-for gTLD string (the "top level tables"). IDN tables must also be submitted for each language or script in which the applicant intends to offer IDN registrations at the second or lower levels.
Each applicant is responsible for developing its IDN Tables, including specification of any variant characters. Tables must comply with ICANN's IDN Guidelines See http://www.icann.org/en/topics/idn/idn-guidelines-26apr07.pdf and any updates thereto, including:
- Complying with IDN technical standards.
- Employing an inclusion-based approach (i.e., code points not explicitly permitted by the registry are prohibited).
- Defining variant characters.
- Excluding code points not permissible under the guidelines, e.g., line-drawing symbols, pictographic dingbats, structural punctuation marks.
- Developing tables and registration policies in collaboration with relevant stakeholders to address common issues.
- Depositing IDN tables with the IANA Repository for IDN Practices (once the TLD is delegated).
- An applicant's IDN tables should help guard against user confusion in the deployment of IDN gTLDs. Applicants are strongly urged to consider specific linguistic and writing system issues that may cause problems when characters are used in domain names, as part of their work of defining variant characters.
To avoid user confusion due to differing practices across TLD registries, it is recommended that applicants cooperate with TLD operators that offer domain name registration with the same or visually similar characters.
As an example, languages or scripts are often shared across geographic boundaries. In some cases, this can cause confusion among the users of the corresponding language or script communities. Visual confusion can also exist in some instances between different scripts (for example, Greek, Cyrillic and Latin).
Applicants will be asked to describe the process used in developing the IDN tables submitted. ICANN may compare an applicant's IDN table with IDN tables for the same languages or scripts that already exist in the IANA repository or have been otherwise submitted to ICANN. If there are inconsistencies that have not been explained in the application, ICANN may ask the applicant to detail the rationale for differences. For applicants that wish to conduct and review such comparisons prior to submitting a table to ICANN, a table comparison tool will be available.
ICANN will accept the applicant's IDN tables based on the factors above.
Once the applied-for string has been delegated as a TLD in the root zone, the applicant is required to submit IDN tables for lodging in the IANA Repository of IDN Practices. For additional information, see existing tables at http://iana.org/domains/idn-tables/, and submission guidelines at http://iana.org/procedures/idn-repository.html.
1.3.3IDN Variant TLDs
A variant TLD string results from the substitution of one or more characters in the applied-for gTLD string with variant characters based on the applicant's IDN table.
Each application contains one applied-for gTLD string. The applicant may also declare any variant strings for the TLD in its application. However, no variant gTLD strings will be delegated through the New gTLD Program until variant management solutions are developed and implemented. The ICANN Board directed that work be pursued on variant management in its resolution on 25 Sep 2010, http://www.icann.org/en/minutes/resolutions-25sep10-en.htm#2.5.
When a variant delegation process is established, applicants may be required to submit additional information such as implementation details for the variant TLD management mechanism, and may need to participate in a subsequent evaluation process, which could contain additional fees and review steps.
The following scenarios are possible during the evaluation process:
- Applicant declares variant strings to the applied-for gTLD string in its application. If the application is successful, the applied-for gTLD string will be delegated to the applicant. The declared variant strings are noted for future reference. These declared variant strings will not be delegated to the applicant along with the applied-for gTLD string, nor will the applicant have any right or claim to the declared variant strings.
Variant strings listed in successful gTLD applications will be tagged to the specific application and added to a "Declared Variants List" that will be available on ICANN's website. A list of pending (i.e., declared) variant strings from the IDN ccTLD Fast Track is available at http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm.
ICANN may independently determine which strings are variants of one another, and will not necessarily treat the applicant's list of purported variants as dispositive in the process.
- Multiple applicants apply for strings that are identified by ICANN as variants of one another. These applications will be placed in a contention set and will follow the contention resolution procedures in Module 4.
- Applicant submits an application for a gTLD string and does not indicate variants to the applied-for gTLD string. ICANN will not identify variant strings unless scenario (b) above occurs.
Each variant string listed must also conform to the string requirements in section 2.2.1.3.2.
Variant strings listed in the application will be reviewed for consistency with the IDN tables submitted in the application. Should any declared variant strings not be based on use of variant characters according to the submitted top-level tables, the applicant will be notified and the declared string will no longer be considered part of the application.
Declaration of variant strings in an application does not provide the applicant any right or reservation to a particular string. Variant strings on the Declared Variants List may be subject to subsequent additional review per a process and criteria to be defined.
It should be noted that while variants for second and lower-level registrations are defined freely by the local communities without any ICANN validation, there may be specific rules and validation criteria specified for variant strings to be allowed at the top level. It is expected that the variant information provided by applicants in the first application round will contribute to a better understanding of the issues and assist in determining appropriate review steps and fee levels going forward.
1.4Submitting an Application
Applicants may complete the application form and submit supporting documents using ICANN's TLD Application System (TAS). To access the system, each applicant must first register as a TAS user.
As TAS users, applicants will be able to provide responses in open text boxes and submit required supporting documents as attachments. Restrictions on the size of attachments as well as the file formats are included in the instructions on the TAS site.
ICANN will not accept application forms or supporting materials submitted through other means than TAS (that is, hard copy, fax, email), unless such submission is in accordance with specific instructions from ICANN to applicants.
Anchor | ||||
---|---|---|---|---|
|
1.4.1Accessing the TLD Application System
The TAS site will be accessible from the New gTLD webpage (http://www.icann.org/en/topics/new-gtld-program.htm
Anchor | ||||
---|---|---|---|---|
|
1.4.1.1 User Registration
TAS user registration requires submission of preliminary information, which will be used to validate the identity of the parties involved in the application. An overview of the information collected in the user registration process is below:
No. | Questions |
1 | Full legal name of Applicant |
2 | Principal business address |
3 | Phone number of Applicant |
4 | Fax number of Applicant |
5 | Website or URL, if applicable |
6 | Primary Contact: Name, Title, Address, Phone, Fax, Email |
7 | Secondary Contact: Name, Title, Address, Phone, Fax, Email |
8 | Proof of legal establishment |
9 | Trading, subsidiary, or joint venture information |
10 | Business ID, Tax ID, VAT registration number, or equivalent of Applicant |
11 | Applicant background: previous convictions, cybersquatting activities |
12(a) | Deposit payment confirmation |
A subset of identifying information will be collected from the entity performing the user registration, in addition to the applicant information listed above. The registered user could be, for example, an agent, representative, or employee who would be completing the application on behalf of the applicant.
The registration process will require the user to request the desired number of application slots. For example, a user intending to submit five gTLD applications would request five application slots, and the system would assign the user a unique ID number for each of the five applications.
Users will also be required to submit a deposit of USD 5,000 per application slot. This deposit amount will be credited against the evaluation fee for each application. The deposit requirement is in place to help reduce the risk of frivolous access to the application system.
After completing the registration, TAS users will receive access enabling them to enter the rest of the application information into the system. Application slots will be populated with the registration information provided by the applicant, which may not ordinarily be changed once slots have been assigned.
No new user registrations will be accepted after [date to be inserted in final version of Applicant Guidebook].
ICANN will take commercially reasonable steps to protect all applicant data submitted from unauthorized access, but cannot warrant against the malicious acts of third parties who may, through system corruption or other means, gain unauthorized access to such data.
1.4.1.2Application Form
Having obtained the requested application slots, the applicant will complete the remaining application questions. An overview of the areas and questions contained in the form is shown here:
No. | Application and String Information |
12(b) | Payment confirmation for remaining evaluation fee amount |
13 | Applied-for gTLD string |
14 | IDN string information, if applicable |
15 | IDN tables, if applicable |
16 | Mitigation of IDN operational or rendering problems, if applicable |
17 | Representation of string in International Phonetic Alphabet (Optional) |
18 | Mission/purpose of the TLD |
19 | Is the application for a community-based TLD? |
20 | If community based, describe elements of community and proposed policies |
21 | Is the application for a geographical name? If geographical, documents of support required |
22 | Measures for protection of geographical names at second level |
23 | Registry Services: name and full description of all registry services to be provided |
No. | Technical and Operational Questions (External) |
24 | Shared registration system (SRS) performance |
25 | EPP |
26 | Whois |
27 | Registration life cycle |
28 | Abuse prevention & mitigation |
29 | Rights protection mechanisms |
| Technical and Operational Questions (Internal) |
30 | Technical overview of proposed registry |
31 | Architecture |
32 | Database capabilities |
33 | Geographic diversity |
34 | DNS service compliance |
35 | Security |
36 | IPv6 reachability |
37 | Data backup policies and procedures |
38 | Escrow |
39 | Registry continuity |
40 | Registry transition |
41 | Failover testing |
42 | Monitoring and fault escalation processes |
43 | DNSSEC |
44 | IDNs (Optional) |
No. | Financial Questions |
45 | Financial statements |
46 | Projections template: costs and funding |
47 | Costs: setup and operating |
48 | Funding and revenue |
49 | Contingency planning: barriers, funds, volumes |
50 | Continuity: financial instrument |
1.4.2 Customer Support during the Application Process
TAS will also provide applicants with access to support mechanisms during the application process. A support link will be available in TAS where users can refer to reference documentation (such as FAQs or user guides), or contact customer support.
When contacting customer support, users can expect to receive a tracking ticket number for a support request, and a response within 48 hours. Support requests will be routed to the appropriate person, depending upon the nature of the request. For example, a technical support request would be directed to the personnel charged with resolving TAS technical issues, while a question concerning the nature of the required information or documentation would be directed to an appropriate contact. The response will be added to the reference documentation available for all applicants.
1.4.3Backup Application Process
If the online application system is not available, ICANN will provide alternative instructions for submitting applications.
1.5Fees and Payments
This section describes the fees to be paid by the applicant. Payment instructions are also included here.
1.5.1gTLD Evaluation Fee
The gTLD evaluation fee is required from all applicants. This fee is in the amount of USD 185,000. The evaluation fee is payable in the form of a 5,000 deposit submitted at the time the user requests application slots within TAS, and a payment of the remaining 180,000 submitted with the full application. ICANN will not begin its evaluation of an application unless it has received the full gTLD evaluation fee by [time] UTC [date].
The gTLD evaluation fee is set to recover costs associated with the new gTLD program. The fee is set to ensure that the program is fully funded and revenue neutral and is not subsidized by existing contributions from ICANN funding sources, including generic TLD registries and registrars, ccTLD contributions and RIR contributions.
- The gTLD evaluation fee covers all required reviews in Initial Evaluation and, in most cases, any required reviews in Extended Evaluation. If an extended Registry Services review takes place, an additional fee will be incurred for this review (see section 1.5.2). There is no additional fee to the applicant for Extended Evaluation for geographical names, technical and operational, or financial reviews. The evaluation fee also covers community priority evaluation fees in cases where the applicant achieves a passing score.
Refunds -- In certain cases, refunds of a portion of the evaluation fee may be available for applications that are withdrawn before the evaluation process is complete. An applicant may request a refund at any time until it has executed a registry agreement with ICANN. The amount of the refund will depend on the point in the process at which the withdrawal is made, as follows:
Refund Available to Applicant | Percentage of Evaluation Fee | Amount of Refund |
After posting of applications until posting of Initial Evaluation results | 70% | USD 130,000 |
After posting Initial Evaluation results | 35% | USD 65,000 |
After the applicant has completed Dispute Resolution, Extended Evaluation, or String Contention Resolution(s) | 20% | USD 37,000 |
After the applicant has entered into a registry agreement with ICANN |
| None |
Thus, any applicant that has not been successful is eligible for at least a 20% refund of the evaluation fee if it withdraws its application.
An applicant that wishes to withdraw an application must initiate the process through TAS and submit the required form to request a refund, including agreement to the terms and conditions for withdrawal. Refunds will only be issued to the organization that submitted the original payment. All refunds are paid by wire transfer. Any bank transfer or transaction fees incurred by ICANN will be deducted from the amount paid.
Note on 2000 proof-of-concept round applicants -- Participants in ICANN's proof-of-concept application process in 2000 may be eligible for a credit toward the evaluation fee. The credit is in the amount of USD 86,000 and is subject to:
- submission of documentary proof by the applicant that it is the same entity, a successor in interest to the same entity, or an affiliate of the same entity that applied previously;
- a confirmation that the applicant was not awarded any TLD string pursuant to the 2000 proof of concept application round and that the applicant has no legal claims arising from the 2000 proof-of-concept process; and
- submission of an application, which may be modified from the application originally submitted in 2000, for the same TLD string that such entity applied for in the 2000 proof-of-concept application round.
Each participant in the 2000 proof-of-concept application process is eligible for at most one credit. A maximum of one credit may be claimed for any new gTLD application submitted according to the process in this guidebook. Eligibility for this credit is determined by ICANN.
1.5.2Fees Required in Some Cases
Applicants may be required to pay additional fees in certain cases where specialized process steps are applicable. Those possible additional fees include:
- Registry Services Review Fee – If applicable, this fee is payable for additional costs incurred in referring an application to the Registry Services Technical Evaluation Panel (RSTEP) for an extended review. Applicants will be notified if such a fee is due. The fee for a three-member RSTEP review team is anticipated to be USD 50,000. In some cases, five-member panels might be required, or there might be increased scrutiny at a greater cost. In every case, the applicant will be advised of the cost before initiation of the review. Refer to subsection 2.2.3 of Module 2 on Registry Services review.
- Dispute Resolution Filing Fee – This amount must accompany any filing of a formal objection and any response that an applicant files to an objection. This fee is payable directly to the applicable dispute resolution service provider in accordance with the provider's payment instructions. ICANN estimates that filing fees could range from approximately USD 1,000 to USD 5,000 (or more) per party per proceeding. Refer to the appropriate provider for the relevant amount. Refer to Module 3 for dispute resolution procedures.
- Advance Payment of Costs – In the event of a formal objection, this amount is payable directly to the applicable dispute resolution service provider in accordance with that provider's procedures and schedule of costs. Ordinarily, both parties in the dispute resolution proceeding will be required to submit an advance payment of costs in an estimated amount to cover the entire cost of the proceeding. This may be either an hourly fee based on the estimated number of hours the panelists will spend on the case (including review of submissions, facilitation of a hearing, if allowed, and preparation of a decision), or a fixed amount. In cases where disputes are consolidated and there are more than two parties involved, the advance payment will occur according to the dispute resolution service provider's rules.
The prevailing party in a dispute resolution proceeding will have its advance payment refunded, while the non-prevailing party will not receive a refund and thus will bear the cost of the proceeding. In cases where disputes are consolidated and there are more than two parties involved, the refund of fees will occur according to the dispute resolution service provider's rules.
ICANN estimates that adjudication fees for a proceeding involving a fixed amount could range from USD 2,000 to USD 8,000 (or more) per proceeding. ICANN further estimates that an hourly rate based proceeding with a one-member panel could range from USD 32,000 to USD 56,000 (or more) and with a three-member panel it could range from USD 70,000 to USD 122,000 (or more). These estimates may be lower if the panel does not call for written submissions beyond the objection and response, and does not allow a hearing. Please refer to the appropriate provider for the relevant amounts or fee structures.
- Community Priority Evaluation Fee – In the event that the applicant participates in a community priority evaluation, this fee is payable as a deposit in an amount to cover the cost of the panel's review of that application (currently estimated at USD 10,000). The deposit is payable to the provider appointed to handle community priority evaluations. Applicants will be notified if such a fee is due. Refer to Section 4.2 of Module 4 for circumstances in which a community priority evaluation may take place. An applicant who scores at or above the threshold for the community priority evaluation will have its deposit refunded.
ICANN will notify the applicants of due dates for payment in respect of additional fees (if applicable). This list does not include fees (annual registry fees) that will be payable to ICANN following execution of a registry agreement.
1.5.3Payment Methods
Payments to ICANN should be submitted by wire transfer. Instructions for making a payment by wire transfer will be available in TAS. Wire transfer is the preferred method of payment as it offers a globally accessible and dependable means for international transfer of funds. This enables ICANN to receive the fee and begin processing applications as quickly as possible.
Payments to Dispute Resolution Service Providers should be submitted in accordance with the provider's instructions.
1.5.4Requesting a Remittance Form
The TAS interface allows applicants to request issuance of a remittance form for any of the fees payable to ICANN. This service is for the convenience of applicants that require an invoice to process payments.
1.6Questions about this Applicant Guidebook
For assistance and questions an applicant may have in the process of completing the application form, applicants should use the customer support resources available through TAS. Applicants who are unsure of the information being sought in a question or the parameters for acceptable documentation are encouraged to communicate these questions through the appropriate support channels before the application is submitted. This helps avoid the need for exchanges with evaluators to clarify information, which extends the timeframe associated with the application.
Questions may be submitted via the TAS support link. To provide all applicants equitable access to information, ICANN will make all questions and answers publicly available.
All requests to ICANN for information about the process or issues surrounding preparation of an application must be submitted in writing via the designated support channels. ICANN will not grant requests from applicants for personal or telephone consultations regarding the preparation of an application. Applicants that contact ICANN for clarification about aspects of the application will be referred to the dedicated online question and answer area.
Answers to inquiries will only provide clarification about the application forms and procedures. ICANN will not provide consulting, financial, or legal advice.