Procedure for Community gTLD Change Requests

Introduction

The Procedure for Community gTLD Change Requests was developed by the Community gTLD Change Request Process Working Group (working group) and the ICANN organization with input from the Registries Stakeholder Group and the ICANN Community. The guiding principles of this procedure permit a community gTLD registry operator to seek modifications to Specification 12 without removing the Community Registration Policies, excessively broadening or narrowing registrant eligibility and/or name selection requirements or resulting in significant negative impact to the TLD Community.

The ICANN org published the draft procedure for Public Comment in February 2018. After consideration of comments received, the ICANN org and the working group concluded that comments did not indicate the procedure is in conflict with existing policy and discussed updates to the procedure. Furthermore, on 26 April 2018 the GNSO Council agreed [PDF, 574 KB] that "ICANN org should continue to treat the Community gTLD Change Request process as a matter of implementation." This published version of the Procedure was agreed upon by the working group and the ICANN org in April 2018.

Procedure

Version: April 2018

Community gTLD Change Request

The Community gTLD Change Request (the "Request") is the procedure for a Community gTLD Registry Operator to seek approval from ICANN to modify the Community Registration Policies enumerated in Specification 12 to its Registry Agreement. Per Section 2.19 of Community gTLD Registry Agreements, "Registry Operator shall operate the TLD in a manner that allows the TLD community to discuss and participate in the development and modification of policies and practices for the TLD." The Registry Operator of a Community gTLD may not seek changes that would remove the Community Registration Policies, excessively broaden or narrow registrant eligibility and/or name selection requirements, or result in significant negative impact to the TLD Community.

As with all ICANN procedures, ICANN may review the effectiveness of this procedure on a periodic basis with input from relevant registry operators and constituencies.

1. Definitions

1.1 A Community gTLD is defined as a gTLD that has a Registry Agreement with ICANN that includes Specification 12 with the section title "Community Registration Policies" or "TLD Policies."

1.2 A Community gTLD Change is defined as a change to Specification 12 of the Registry Agreement with ICANN.

1.3 The TLD Community is defined by the eligibility requirements outlined in Specification 12 of the Registry Agreement with ICANN.

1.4 Registry Operator is defined as an entity with a Registry Agreement to administer a Community gTLD.

1.5 All references to days within this procedure are defined as calendar days.

2. Community gTLD Change Request Procedure

2.1 Registry Operator Submits a Community gTLD Change Request (the "Request")

Registry Operator may submit a Request at any time. The Request shall be submitted in writing to ICANN accompanied by a complete Community gTLD Change Request Questionnaire (see Annex A) [PDF, 38 KB], and must include documentation of support for the change by the TLD Community (including entities representing any proposed extension of the TLD Community, if applicable), as well as by the representative governing bodies, if applicable.

2.2 ICANN Preliminary Review of the Request

Upon receipt of a Request, ICANN will verify its completeness and notify the Registry Operator in writing of any deficiencies within 5 days. The Registry Operator may resubmit a revised Request to ICANN at any time for renewed handling. Provided all items in the Questionnaire have been addressed and supporting documents provided, the Request will be considered complete.

After the completeness check, ICANN will conduct a preliminary review and prepare the Request and draft amendment for the comment period within 10 days. If during the preliminary review ICANN determines the Request does not fall within the scope of this procedure or flags concerns that would likely result in rejection of the Request, ICANN may identify these concerns and initiate a consultation period with the Registry Operator prior to the comment period.

2.3 Change Request Comment Period

After ICANN's preliminary review of the Request, ICANN will post the Request and draft amendment for a comment period of 30 days.

2.4 Registry Operator Response Period

In the event questions are raised about the Request during the comment period, ICANN will initiate a consultation period with the Registry Operator and request their response to comments received within 15 days from ICANN's request. During this time, ICANN may also consult with Registry Operator to clarify comment(s) that may negatively impact approval of the Request and/or respond directly to comments received, if necessary.

3. ICANN Review and Determination

3.1 ICANN Review

ICANN shall analyze whether the Request should be approved or rejected and its assessment shall be based on the following criteria:

1. Description of TLD Community – Is there a clear description of the TLD's eligibility requirements and how they are impacted by the Request?
2. Evidence of TLD Community outreach and support – Is there reasonable evidence of outreach to the TLD Community showing efforts of the RO to "operate the TLD in a manner that allows the TLD Community to discuss and participate in the development and modification of policies and practices for the TLD"? Is there reasonable evidence of TLD Community support for the Request?
3. Benefits to TLD Community – Do the responses provided in 1.3 and 1.4 of the Change Request Questionnaire adequately explain how the Request would benefit the TLD Community? Would allowing the change result in detriment to the TLD Community?
4. Concerns raised during the comment period – Were significant concerns raised during the comment period that identified harm to the TLD Community or Internet community? Did the Registry Operator provide an adequate response to these concerns? An adequate response may include supporting evidence from the Registry Operator that (1) there will be no reputational damage to the community; (2) there is no interference with the core activities of the community; or (3) there is no economic damage to the community.

3.2 ICANN Determination

3.2.1 Approval

If ICANN determines the Request is approved, ICANN shall provide approval to the Registry Operator within a target timeframe of 30 days from the close of the comment period or from the Registry Operator's response to concerns raised during the comment period. In the case of delay, ICANN shall provide written explanation and indication of the new deadline.

Included with the approval, ICANN shall provide an amendment for execution. If necessary, ICANN may modify the amendment as necessary to implement the approved Request and provide to the Registry Operator for review prior to execution.

3.2.2 Rejection

If ICANN determines the Request is rejected, ICANN shall notify the Registry Operator of its rejection of the Change Request and clearly state its rationale for rejecting the Request within a target timeframe of 30 days from the close of the comment period or from the Registry Operator's response to concerns raised during the comment period. In the case of delay, ICANN shall provide written explanation and indication of the new deadline.

ANNEX A: Community gTLD Change Request Questionnaire [PDF, 38 KB]