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

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

ADOPTED

13Y, 0N, 0A

Justine Chew

04 April 2018

05 April 2018

09 April 2018

12 April 2018

06 April 2018

Amanda Fessenden
amanda.fessenden@icann.org

AL-ALAC-ST-0418-01-01-EN

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.

14 Comments

  1. Justine Chew

    There are only 2 points which I would seek clarity on in respect of the Draft Procedure for Community gTLD Change Requests (Jan 2018) [PDF, 327 KB]. These are:-


    1. Reference to TLD Community

    It could be that the composition of the TLD Community would change in context of or under the circumstances leading to the Community gTLD Change Request, so it might be useful to know whether the TLD Community from which a Registry Operator is mandated to to seek documentation of support for a Community gTLD Change Request includes all or an absolute majority (or even just a simple majority) of the communities (i.e. the established institutions representing the community the RO had named) which had provided documentation of support for the Registry Operator's community-based application to begin with. And if not, why not? This would at least alert us/ICANN in the first instance as to whether the RO is still engaging with the (original) communities and whether there is data indicating if these communities believe that their rights have been positively or negatively affected or not by virtue of the Community gTLD Change Request.

    Note: that Russ Weinstein had written (Letter from Russ Weinstein to Craig Schwartz [PDF, 219 KB] (22 September 2017)) to suggest that ICANN Org be allowed to evaluate an RO's Community gTLD Change Request without needing to make a determination of whether the RO's consultation with the TLD Community was adequate, given that all Community gTLD Change Requests are to be posted for public comment.

    Note: 1.3 The TLD Community is defined by the eligibility requirements outlined in Specification 12 of the RA with ICANN, so each is obviously specific to each delegated Community gTLD.


    2. References to number of days with respect to ICANN Determinations

    Minor point. Whether the target timeframes of 30 days mentioned in 3.2.1 and 3.2.2 of the draft procedure ought be amended to read as "... within 30 days of the determination or..." for avoidance of doubt and consistency with the rest of the draft.


    All other parts of the Draft Procedure including Annex A seem reasonable to me.


    Justine

  2. Alan Greenberg

    I agree with the refereice point for the 30 day limit.

    With regard to the community, the scope of the community (and whether it is the full community) was a major sticking point in the Community Priority Evaluation (CPE) process  in the first round. However, if a TLD string was not contested, the appiication never went through CPE and the definition of the community is whatever the applicant said it was. So it is too late now to apply new rules.

    My only other concern is that the 30 day comment period be a formal ICANN Public Comment so that it is very visible and not likely to be missed (such as the comment period for other registry changes - RSEP).


    Justtine, are you  in a position to draft something quickly on these two points?

    Alan

  3. Alan Greenberg

    We have a 3 day extension on this comment.

  4. Justine Chew

    Hi Alan,

    Here is my draft comment for further input/consideration:

    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.

    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.


    Thanks,

    Justine

    1. Alan Greenberg

      Thanks Justine, That looks good.

      I suggest one more small change, and that is to note that Community TLDs have been of great importance to At-Large. I will incorporate.

      I will post it as the first draft and send messages giving the community until 23:59 UTC on Thursday to further comment.



      1. Justine Chew

        Excellent. Thank you for the change and your prompt.

  5. Daniel Khauka Nanghaka

    I agree with the changes especially the 30 days period for feedback and the feedback can come before or after

  6. Abdulkarim Ayopo Oloyede

    Hi, Please I want to understand what is meant by  " determination " There is a difference between 30 days limit and 30 days after the determination. 

     The determination period is it after the initial 5 days for  deficiencies or the 10 days of the comment period 

    1. Justine Chew

      Neither, determination here refers strictly to ICANN's determination in approving or rejecting the Request. In other words. ICANN is to notify the Registry Operator within 30 days of either approving or rejecting the Request, or provide written explanation and an indication of the new deadline in case more than 30 days is required to complete the notification.

  7. Krishna Seeburn

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


    --- Shall also describe clearly in written any method of appeal in place (I think it is important to put that in place depending on the domain name request )

    1. Justine Chew

      Kris,

      Considering that all Change Requests (assuming they pass the completeness check by ICANN) would undergo preliminary review and then have to be posted for comment (and we are asking that these be via ICANN's formal public comment process) I did not think an additional avenue for appeal would be necessary.

      If ICANN org rejects a Request notwithstanding support for the Request has clearly been established for it vide the public comment process, then ICANN org should be held accountable for its decision through a formal intervention by the community, if not the Board. 

      Plus we have also asked for "the opportunity to understand and comment on any other approval or rejection criteria" to be applied by ICANN org in determining Change Requests.

      While I am not opposed to including a proposed method of appeal, the more important question is who should be charged to act as the body of appeal? Would you like to suggest something more concrete in term of criteria (per your "depending on the domain name request" remark), procedure and appeals body?

      Thanks,

      Justine

  8. Krishna Seeburn

    I suggested the appeal bit because i personally feel it becomes important. To ease legal matters for nothing. May be a specialised WG could be the answer. But unfortunately many can be biased as well. A special committee could be put as an adhoc one, if ever an appeal comes in for any reason. At this stage i cannot think of its composition but am sure something easy can be thought of. It could and should be independent so that ICANN org  does not fall in a cat and mouse game. Its a suggestion to be contemplated. 

    1. Alan Greenberg

      I note that if a Registry felt that an appeal process was necessary as part of this process, they had ample opportunity to suggest one.

  9. Justine Chew

    I draw your attention to the following published in the information section of this wikipage:  

    The     ICANN org provided feedback to the working group, published [PDF, 219 KB] on 22 September 2017 on 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.

    The discussion draft of 22 Sep 2017 included the following text in respect of Reconsideration:

    "4. Reconsideration

    gTLD registry operators or other parties affected by an ICANN decision may use the existing Reconsideration processes in the ICANN bylaws.

    The authoritative source for information on the Reconsideration process is the ICANN bylaws (see Article IV: Section 2 http://www.icann.org/general/bylaws.htm#IV). The reconsideration applies to staff actions that contradict an ICANN policy, or to an ICANN Board action taken without consideration of material information. Information on past reconsideration processes is available at http://www.icann.org/committees/reconsideration."


    I suggest we do not propose to create another layer of appeal process but instead ask for the above stated Reconsideration policy to be clearly represented to and be applicable to any Community gTLD Registry Operator that has had its Community gTLD Change Request rejected by ICANN.