AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Public Comment CloseStatement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

02 April 2018

Draft Procedure for Community gTLD Change Requests

VOTE

Justine Chew

04 April 2018

05 April 2018

06 April 2018

11 April 2018

06 April 2018

Amanda Fessenden
amanda.fessenden@icann.org

Hide the information below, please click here 

Brief Overview

Purpose: The ICANN organization is seeking comments on a draft procedure [PDF, 327 KB] for ICANN to consider changes to Specification 12 of Community generic Top Level Domain (gTLD) Registry Agreements requested by community gTLD registry operators. The guiding principles of the procedure would 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. This draft procedure is the result of collaboration between the Community gTLD Change Request Process Working Group and the ICANNorganization, with input provided by members of the Registries Stakeholder Group.

Current Status: Following discussion at the GNSO Council meeting held on 1 November 2017, the Council guided [PDF, 245 KB] the Community gTLD Change Request Process Working Group to address comments from the ICANN organization on a previous draft and to solicit public comments on the revised draft procedure.

Next Steps: The ICANN organization and the working group will consider comments received in the summary and analysis of comments. Following the guidance from the GNSO Council, the ICANN organization and the working group will submit the summary and analysis of comments to the GNSO Council to ensure it does not raise policy issues before moving toward implementation of a procedure.

Section I: Description and Explanation

As part of the New gTLD Program application process, applicants for community-based gTLDs were required to provide a description of the community they intended to serve, the proposed registration policies for the gTLD, and specific information related to defining the community and relationship between the applicant and the community. The Applicant Guidebook stated that responses to this question would be "regarded as firm commitments to the specified community and reflected in the Registry Agreement provided the application is successful." For successful applicants, these commitments were adopted into Specification 12 (Community Registration Policies) of the New gTLD Registry Agreement.

The ICANN org has deferred several registry operator requests for changes to Specification 12 of the Registry Agreement due to the lack of clear guidance about whether criteria to process proposed changes are a matter of policy discussions or implementation. The Applicant Guidebook states, "material changes to the contract, including changes to the community-based nature of the gTLD and any associated provisions, may only be made with ICANN's approval." The guidebook also states, "proposed criteria for approving such changes are the subject of policy discussions." However, there have been no discussions or subsequent work on this topic that resulted in a process by which ICANN org can approve or deny change requests to Specification 12 of the Registry Agreement.

While the guidebook points to policy discussions to determine criteria, the community gTLDRegistry Agreement states the registry operator is capable of modifying policies and practices for the TLD. Section 2.19 of the community gTLD Registry Agreement (Obligations of Registry Operator to TLD Community) requires a registry operator 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."

Identifying the need for a process and criteria to enable community gTLD registry operators to evolve their registration policies with the changing needs of a TLD community, the Community gTLD Change Request Process Working Group formed in 2016. This group is comprised of community gTLD registry operators and other stakeholders. The goal of the working group is to develop a process with the necessary criteria to enable community gTLD registry operators to request changes to their 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.

As a result of collaboration between the working group and the ICANN org, with input from members of the Registries Stakeholder Group (RySG), the ICANN org and the working group have developed a draft procedure [PDF, 327 KB] for Community gTLD Change Requests. The ICANN org and the working group are seeking community input on the proposed procedure.

The ICANN org and the working group would like to highlight certain rationale applied in development of this proposed procedure for the community's consideration:

  • Guiding principles to establish eligibility: the working group incorporated guiding principles in its development of the draft procedure to clearly state its goal and limitations in the introductory paragraph of the procedure. These limitations are a mechanism to prevent gaming of such a procedure that could result in a community gTLD registry operator removing its Community Registration Policies.
  • A single process for all change requests: the working group and the ICANN org developed a single set of potential standards for considering a proposed change provided the change request meets the guiding principles of the draft procedure. The working group considered whether a separate procedure was necessary for those community gTLDs that prevailed during the application process as a result of a successful Community Priority Evaluation or Community Objection proceeding. However, the resulting community gTLD Registry Agreement does not treat these community gTLD registry operators differently from those who did not. Furthermore, the ICANN org highlighted concerns that a process with multiple decision points that trigger specific reviews dependent upon whether a community gTLD went through CPE or won objections would add time, complexity, and opportunities for disputes or disagreements (either by the registry operator or others in the ICANN community).
  • Community gTLD Change Request Form: use of this proposed mandatory form would require the registry operator to justify how the Change Request fits within the scope of the process and to provide essential information for consideration by the ICANN org as well as the community during the Change Request Comment Period. Under the proposed procedure, submitted forms would be published for community review.
  • Required outreach to the TLD Community: the working group and the ICANN org propose that the registry operator's preparatory work for a Change Request should include consultation with the relevant TLD Community and collection of documentation of support from key participants within the TLD community. This aligns with the mission of a community gTLD registry operator to "operate the TLD in a manner that allows the TLDcommunity to discuss and participate in the development and modification of policies and practices for the TLD" (Section 2.19 of the community gTLD Registry Agreement).
  • Change Request Comment Period: the draft procedure includes a comment period. This step would provide a mechanism for the Internet community to provide input on a Community gTLD Change Request for the ICANN org to consider in its analysis of the Change Request. This comment period is similar to ICANN's processes for requests from registry operators to add Specification 13 (.BRAND) or the Code of Conduct Exemption (Specification 9) to their registry agreements.
  • Approval Criteria: the ICANN org and the working group are proposing to include approval or rejection criteria (Section 3.1, ICANN Review) to provide transparency in how ICANN would make a determination. The proposed criteria incorporate consideration of specific responses from the registry operator in the Community gTLD Change Request Form, evidence of TLD Community outreach and support, and analysis of any concerns raised during the comment period.

Following the conclusion of this Public Comment period on the draft procedure, the ICANN org and the working group will consider comments received and publish a summary and analysis of comments. Following guidance from the GNSO Council, the ICANN org and the working group will submit the summary and analysis of comments to the GNSO Council to ensure it does not raise policy issues before moving toward implementation of a procedure.

Section II: Background

The topic of a community gTLD registry operator changing its Community Registration Policies (Specification 12) dates back to the development of the New gTLD Program. In 2011, ICANNorg published an explanatory memo [PDF, 105 KB] intended to facilitate GNSO discussions of a potential procedure to consider change requests of Community Registration Policies. However, there have been no discussions or subsequent work on this topic that resulted in a process by which ICANN org can approve or deny change requests to Specification 12 of the Registry Agreement.

In a good faith effort to find a mutually agreeable solution, the working group initiated high-level discussions with the ICANN org in late 2016. The working group circulated its initial draft procedure with the RySG then submitted [PDF, 213 KB] this draft to the ICANN org in July 2017. The ICANN org provided feedback to the working group, published [PDF, 219 KB] on 22 September 2017on ICANN's Correspondence webpage, and has since held several calls with the working group. These efforts resulted in alignment on the version of the draft procedure published in this Public Comment proceeding.

In parallel to these efforts on the draft procedure, the ICANN org encouraged the working group to collaborate within the ICANN community to achieve clarity and transparency on whether this work needed additional policy guidance or could proceed as implementation. Accordingly, the working group presented to the GNSO Council on 20 September and 12 October 2017. From this consultation, the GNSO Council agreed [PDF, 245 KB] in its 1 November 2017 meeting that the proposed draft procedure should be published for Public Comment after the working group addresses comments from the ICANN org.

The proposed draft procedure is the outcome of many working group calls and communications between January and July 2017, numerous consultations with the RySG, and several engagements with the ICANN org between October 2016 and January 2018.

Section III: Relevant Resources



Section IV: Additional Information


Section V: Reports

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 


FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

The ALAC thanks the ICANN organization for the extended opportunity to provide comments to the the Draft Procedure for Community gTLD Change Requests of 31 January 2018 ("Draft Procedure") for ICANN to consider changes to Specification 12 of Community generic Top Level Domain (gTLD) Registry Agreements requested by community gTLD registry operators. Community TLDs are of crucial importance to At-Large.

The ALAC notes that this said draft procedure was developed by ICANN org in collaboration with the Community gTLD Change Request Process Working Group and with input from RySG members and the ALAC is supportive of the guiding principles for a procedure which is consistent with Section 2.19 of Community gTLD Registry Agreements and one which would prevent Community gTLD Registry Operators from seeking to modify the Community Registration Policies enumerated in the Specification 12 of their respective Community gTLD Registry Agreements, that would remove those Community Registration Policies, excessively broaden or narrow registrant eligibility and/or name selection requirements, or result in significant negative impact to the TLD Community.

The ALAC supports the Draft Procedure (including the proposed Community gTLD Change Request Form), subject to three provisos touching on the following areas:-

(1) Required outreach to the TLD Community

The ALAC notes that each "TLD Community" would be unique to what a Community gTLD Registry Operator has described within its Specification 12 and we understand that a change in circumstances may lead a Community gTLD Registry Operator to seek a Community gTLD Change Request.

While we are supportive of the requirement for consultation with and inclusion of documentation of support by the TLD Community, we would like to clarify that under section 2.1 of the Draft Procedure, where there has been a departure in the description of the TLD Community originally provided for by the Community gTLD Registry Operator in their Specification 12, the nature and reason(s) for this departure must clearly be included in the Community gTLD Change Request submitted by the Community gTLD Registry Operator.

A requirement for this declaration would immediately assist in flagging a question of whether the interests of the TLD Community originally described by the Community gTLD Registry Operator in their Specification 12 are impacted on and how so, and if those members of the TLD Community so affected have been consulted as part of their Community gTLD Registry Operator's Community gTLD Change Request, and if not, why not.

We believe this requirement would also add value to ICANN's performance of reviewing evidence of gTLD Community outreach and support as specified under section 3.1(b) of the Draft Procedure.

(2) Change Request Comment Period

The ALAC recommends that the commenting process referred to under section 2.3 of the Draft Procedure be specified as a formal ICANN Public Comment which follows the regular ICANN Operational Consultations process.

(3) Approval Criteria

The ALAC recommends that the target timeframes of 30 days mentioned in sections 3.2.1 and 3.2.2 of the Draft Procedure be made clearer for avoidance of doubt and to maintain consistency with the rest of the Draft Procedure, and hence proposes that they be amended to read as follows:-

"3.2.1 Approval
If ICANN determines the Request is approved, ICANN shall provide approval to the Registry Operator within 30 days of the determination or shall provide written explanation and indication of the new deadline in case of delay. ........

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 30 days of the determination or shall provide written explanation and indication of the new deadline in case of delay."

We would also appreciate the opportunity to understand and comment on any other approval or rejection criteria that may be included in this Draft Procedure hereon.


FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.


The ALAC thanks the ICANN organization for the extended opportunity to provide comments to the the Draft Procedure for Community gTLD Change Requests of 31 January 2018 ("Draft Procedure") for ICANN to consider changes to Specification 12 of Community generic Top Level Domain (gTLD) Registry Agreements requested by community gTLD registry operators. Community TLDs are of crucial importance to At-Large.

The ALAC notes that this said draft procedure was developed by ICANN org in collaboration with the Community gTLD Change Request Process Working Group and with input from RySG members and the ALAC is supportive of the guiding principles for a procedure which is consistent with Section 2.19 of Community gTLD Registry Agreements and one which would prevent Community gTLD Registry Operators from seeking to modify the Community Registration Policies enumerated in the Specification 12 of their respective Community gTLD Registry Agreements, that would remove those Community Registration Policies, excessively broaden or narrow registrant eligibility and/or name selection requirements, or result in significant negative impact to the TLD Community.

The ALAC supports the Draft Procedure (including the proposed Community gTLD Change Request Form), subject to three provisos touching on the following areas:-

(1) Required outreach to the TLD Community

The ALAC notes that each "TLD Community" would be unique to what a Community gTLD Registry Operator has described within its Specification 12 and we understand that a change in circumstances may lead a Community gTLD Registry Operator to seek a Community gTLD Change Request.

While we are supportive of the requirement for consultation with and inclusion of documentation of support by the TLD Community, we would like to clarify that under section 2.1 of the Draft Procedure, where there has been a departure in the description of the TLD Community originally provided for by the Community gTLD Registry Operator in their Specification 12, the nature and reason(s) for this departure must clearly be included in the Community gTLD Change Request submitted by the Community gTLD Registry Operator.

A requirement for this declaration would immediately assist in flagging a question of whether the interests of the TLD Community originally described by the Community gTLD Registry Operator in their Specification 12 are impacted on and how so, and if those members of the TLD Community so affected have been consulted as part of their Community gTLD Registry Operator's Community gTLD Change Request, and if not, why not.

We believe this requirement would also add value to ICANN's performance of reviewing evidence of gTLD Community outreach and support as specified under section 3.1(b) of the Draft Procedure.

(2) Change Request Comment Period

The ALAC recommends that the commenting process referred to under section 2.3 of the Draft Procedure be specified as a formal ICANN Public Comment which follows the regular ICANN Operational Consultations process.

(3) Approval Criteria

The ALAC recommends that the target timeframes of 30 days mentioned in sections 3.2.1 and 3.2.2 of the Draft Procedure be made clearer for avoidance of doubt and to maintain consistency with the rest of the Draft Procedure, and hence proposes that they be amended to read as follows:-

"3.2.1 Approval
If ICANN determines the Request is approved, ICANN shall provide approval to the Registry Operator within 30 days of the determination or shall provide written explanation and indication of the new deadline in case of delay. ........

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 30 days of the determination or shall provide written explanation and indication of the new deadline in case of delay."

We would also appreciate the opportunity to understand and comment on any other approval or rejection criteria that may be included in this Draft Procedure hereon.

  • No labels