Skip to main content

Change Requests

New gTLD Advisory
Advisory number: R1-A01-CR
Publication date: 5 September 2014

Change Request Criteria

As per the change request process posted at, ICANN evaluates change requests against 7 criteria:

  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.

Implications on Community Applications

ICANN has received inquiries regarding why requested changes to community definition and registration policies are deferred until after the completion of CPE.

In considering these types of change requests, the most relevant criteria are criteria three through seven. Criteria three, five, six, and seven are related and are considered together.

A change to update a community's definition and registration policies prior to contracting is material because: (1) other parties' decisions on whether to file an community objection to the application were made on the basis of what was in the application at the time of the objection window; (2) the community definition and registration policies serve as the basis for determining the merits of a community objection; and (3) they are evaluated during CPE.

Approval of a change request to update a community definition and registration policies would allow a CPE applicant to update its application based on learnings from previously posted CPE results. This causes issues of unfairness to the first applicants that went through CPE and did not have the benefit of learning from others. Allowing such a change request would also improve the CPE applicant's chances to prevail in CPE, negatively impacting the other applicants in the same contention set. Therefore, although viewed as necessary from the CPE applicant's perspective to maximize its ability to pass CPE, approval of a change request to update a community's definition and registration policies prior to the completion of CPE would cause issues of unfairness to other applicants in the same contention set.

As ICANN's responsibilities are to ensure fair and equitable treatment for all applicants, all change requests of these types have been deferred until after CPE. If an applicant successfully prevails in CPE and enters into contracting, ICANN will consider approving a change request to update the community definition and registration policies prior to execution of the Registry Agreement, provided there are no pending issues impacting the application (i.e., a pending accountability mechanism triggered on the string).

Implications on Exclusive-Generic Applications

On 28 September 2013, the New gTLD Program Committee ("NGPC") passed a resolution directing ICANN staff "to move forward with the contracting process for applicants for strings identified in the Category 2 Safeguard Advice that are prepared to enter into the Registry Agreement as approved." On 9 October 2013, ICANN announced an implementation plan per the NGPC's direction. Applicants subjected to Category 2 Safeguard Advice were asked to provide responses to the following three questions:

  1. Will the TLD be operated as an exclusive access registry?
  2. Does the current applicant state that the TLD will be operated as an exclusive registry?
  3. Does the applicant have a pending change request regarding exclusive access?

Some applicants answered "No" to question one, "Yes" to question two, and "No" to question three, which means that although their applications state that the applied-for TLDs will be operated as exclusive access registries they will not operate them as such. For these applicants, the implementation plan allows for them to submit change requests to align their applications with their intent. Once the change requests complete processing, these applications may move forward to contracting if all other eligibility criteria are met. Allowing applicants to change from being an exclusive to a non-exclusive registry does not create unfairness because exclusiveness is not an evaluation criterion and has no bearing on contention resolution.

In line with the announced GAC Category 2 implementation plan, ICANN has approved change requests from applicants wishing to address GAC Category 2 Advice by making their applications non-exclusive access registries and will continue to do so.