Skip to main content

New gTLD Application Change Request Process and Criteria

Overview
Determination Criteria
How to Submit a Change Request
Change Request Process
Change Requests That Do Not Require A 30-day Comment Window
How Change Requests Impact Other New gTLD Program Processes
Statistics
Resources

News & Views

Announcement: 30 September 2014 – ICANN Updates Application Change Request Process

Announcement: 30 September 2014 – Change Request Advisory

Change Request Overview

Per section 1.2.7 of the Applicant Guidebook:

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.

This section of the Applicant Guidebook further states:

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.

The Application Change Request ("ACR") process was created during the application window in order to allow applicants to notify ICANN of changes to application materials.

Change Request Determination Criteria

Determination of whether changes will be approved will balance the following factors:

  1. Explanation – Is a reasonable explanation provided?
  2. Evidence that original submission was in error – Are there indicia to support an assertion that the change merely corrects an error?
  3. Other third parties affected – Does the change affect other third parties materially?
  4. Precedents – Is the change similar to others that have already been approved? Could the change lead others to request similar changes that could affect third parties or result in undesirable effects on the program?
  5. Fairness to applicants – Would allowing the change be construed as fair to the general community? Would disallowing the change be construed as unfair?
  6. Materiality – Would the change affect the evaluation score or require re-evaluation of some or all of the application? Would the change affect string contention or community priority consideration?
  7. Timing – Does the timing interfere with the evaluation process in some way? 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. (AGB §1.2.7.)

These criteria were carefully developed to enable applicants to make necessary changes to their applications while ensuring a fair and equitable process for all applicants.

In evaluating each change request, all available information is considered against the seven criteria above. The weight of each criterion may vary on a case-by-case basis, depending on the facts and circumstances surrounding the change request, the application, and the string.

Explanation – This criterion requires that the applicant provide an explanation for the requested changes. If an explanation is not provided, the applicant is given an opportunity to remediate. As such, this criterion is always met and does not bear as much weight as the other criteria.

Evidence that original submission was in error – This criterion is applicable in cases where the applicant requests a change to correct an error. In this case, the criterion requires that the applicant provide adequate information to support the request. There are few cases of change requests to correct an error. However, when such a case is submitted, this criterion is heavily weighted.

Other third parties affected – This criterion evaluates whether the change request materially impacts other third parties, particularly other applicants. In cases where a change to application material has the potential to materially impact the status of another applicant's application, this criterion is heavily weighted.

Precedents – This criterion assesses whether approval of the change request would create a new precedent, or if it would be in-line with other similar requests that have been approved. At this stage of the New gTLD Program, it is unlikely that a change request that would create a new precedent would be approved.

Fairness to applicants – This criterion evaluates whether approving a change request would put the applicant in a position of advantage or disadvantage compared to other applicants. This criterion is related to the "Other third parties affected" criterion, and if a change request is found to materially impact other third parties, it will likely be found to cause issues of unfairness.

Materiality – This criterion assesses how the change request will impact the status of the application and its competing applications, the string, the contention set, and any additional Program processes that it or its competing applications must complete such as Community Priority Evaluation ("CPE"). A change that is determined to be material in and of itself will not cause a change request to be rejected. However, it will cause other criteria to weigh more when considered in conjunction with each other.

Timing – This criterion determines whether the timing of the change request impacts the materiality, fairness to applicants, and other third parties affected criteria. In cases where timing of the change request is found to impact these criteria, it will be heavily weighted.

How to Submit a Change Request

Requests for changes to application materials may be submitted to the Naming Services Portal (NSp) by following these 2 steps:

  1. Download and complete a gTLD Application Change Request Form [DOCX, 564 KB].
  2. Log into the NSp with the primary contact's credentials and submit the Form, along with redlines of the changes being requested. An example of a redline document can be viewed here.

The standard change request process requires that any change to the application, including changes to the Primary Contact, be initiated by the Primary Contact and submitted via the appropriate login in the NSp. If the Primary Contact is no longer available to initiate the change, then the Secondary Contact may contact the GSC at newgtld@icann.org to submit the change request.

Change Request Process

Below is a graphic depicting the change request process.

Change Request Process

Verification & Validation – In this step, ICANN verifies the applicant's credentials in order to ensure that only those authorized to make changes to the application are able to do so. Additionally, ICANN reviews the change request materials submitted by the applicant to ensure that a completed Change Request Form, appropriate redline documents, as well as all relevant supporting documentations are provided. This step is not counted in the 4-6 week Service Level Target ("SLT") for change requests, because the amount of time to complete this step is highly dependent upon the applicant providing the required information. ICANN's work during this step is minimal. ICANN typically performs its work within 2 business days of receiving the requests or information from the applicant. Submission of incomplete information, and non-response to ICANN's request for required information are typical causes of delay in this step. ICANN will inform the applicant once this step is completed.

ICANN Review – Once verification and validation of the change request is completed, ICANN reviews the change request materials against the seven criteria above. In the event that additional information is required before a determination can be made, ICANN will reach out to the applicant to request the information. The SLT for this step of the process is 2-4 weeks, depending on the complexity of the change request and whether additional information is required.

Notification of Determination – Once ICANN completes its review of the change request, the applicant will be informed of the determination. Possible determinations include approval of the change request, denial of the change request, or deferral of the change request to a later time. The SLT for this step is one week to account for the drafting of denial or deferral letters if the change request is denied or deferred.

Changes Made and Posted – In this step, ICANN makes the requested and approved changes to the application. Changes that require a 30-day comment window will be posted on the Application Status page of the New gTLD Microsite. Changes that do not require a 30-day comment window will not be posted. Refer to the "Change Requests Requiring 30-day Comment Window" section below for information on which changes will be posted for comments and which ones will not. Applicants will be notified once the changes are made. The notification will also inform applicants whether the changes are posted for comments, and whether application re-evaluation will be required.

Re-evaluation – This step is applicable to those change requests that require re-evaluation of the application. Once ICANN notifies the applicant that the changes are made and that re-evaluation is required, the change request case will be closed and a new re-evaluation case will be opened to assist the applicant through the re-evaluation process. Under the re-evaluation step, the applicant will be sent an invoice for the re-evaluation fee. Once payment is made, ICANN will proceed with the re-evaluation of the application. The re-evaluation will follow the same process and timelines as Extended Evaluation:

  • 3 weeks: evaluators review the updated application, and issue Clarifying Questions if required.
  • 6 weeks: applicants respond to Clarifying Questions.
  • 2 weeks: evaluators review response to Clarifying Questions and deliver results to ICANN.
  • 1 week: ICANN reviews and processes the results for publication. Note that if the re-evaluation results in any scoring changes, ICANN will update either the Initial or Extended Evaluation report and post it on the Application Status page of the New gTLD Microsite. If the re-evaluation does not result in any scoring changes, no updates will be made.

Change Requests That Do Not Require A 30-day Comment Window

In the interest of allowing applicants to expeditiously move forward in the New gTLD Program, effective 1 October 2014, the following types of change requests will generally not be posted for comments for 30 days:

  • Changes to confidential portions of the application
  • Changes to primary and secondary contacts of the application
  • Changes to the applicant's contact information (address, phone, fax, web address)
  • Changes to applicant's stock symbol
  • Changes to applicant's business/tax ID
  • Changes to applicant's officers/directors
  • Changes to name of applying entity*
  • Changes to parent entity

Although these types of change requests generally will not be posted for comments, ICANN reserves the right to make exceptions in ICANN's discretion.

* This item refers to a simple name change of the applying entity only. It does not apply to changes in the applying entity itself such as the case of the application being assigned from a parent entity to a wholly-owned subsidiary.

How Change Requests Impact Other New gTLD Program Processes

Contracting – If an applicant is eligible to be invited to Contracting, but there is a pending change request on the application, the applicant will not be invited until the change request completes processing. If the applicant has been invited to contracting and is progressing through the contracting process, a pending change request will cause delays and may impact the applicant's ability to execute the Registry Agreement in a timely manner. If the applicant anticipates not being able to execute the Registry Agreement by the Registry Agreement execution deadline, ICANN recommends that the applicant submit an extension request [DOCX, 565 KB] in order to avoid missing the Registry Agreement execution deadline. Applicants will not receive a Registry Agreement until the change request completes processing, and the 30-comment window (if required) has concluded.

Contention Resolution – For Community Priority Evaluation, the applicant will only be invited once the change request completes processing and the 30-day comment window (if required) has concluded. For Auction, a pending change request will not prevent an Auction from being scheduled, but in some circumstances, the Auction may be delayed.

Statistics

Below are quarterly change request statistics (as of December 2019).

ACR Posting of Year-to-Date Change Requests

Resources