Public Comment CloseStatement



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

14 February 2020


15Y, 0N, 0A

20 January 2020

12 February 2020

13 February 2020

18 February 2020

13 February 2020


Hide the information below, please click here 


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


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


Proposed Final Report of the New gTLD Auction Proceeds Cross-Community Working Group

The ALAC appreciates the opportunity to comment on the second report on the gTLD Auction Proceeds.  ALAC participants have been following this issue closely and have discussed these issues internally prior to the issuance of this report.  We discussed each of these mechanisms among the participants and member of this working group resulting in the following positions.

  • Do you support the CCWG's recommendation in relation to the preferred mechanism(s)? If no, please provide your rationale for why not.


During much of the CCWG Auction Proceeds duration, the ALAC Members and Participants have taken widely disparate positions on which mechanism to select, with support for Mechanisms A, B and C. Ultimately, those in favor of Mechanism C shifted to Mechanism B.

There was significant debate on which to finally select. Among the issues noted were:

  • Mechanism B required outsourcing but did not specify exactly what functions would be outsourced (over and above the requirement for all Mechanisms to utilize an independent Evaluation Panel). Moreover over the course of the CCWG discussions, different Members had expressed varying beliefs as to what functions would be outsourced.
  • Mechanism A allows outsourcing if viewed as advantageous, and in fact ICANN often outsources parts of its responsibilities which are not core to overseeing its Bylaw-mandated responsibilities. Thus Mechanism A could end up being comparable to Mechanism B, but provided more management flexibility in deciding how the varying aspects of the project would be carried out.

ALAC Decision

While several Members of the ALAC Auction Proceeds team originally preferred Mechanism B where ICANN worked with a non-profit organisation already adept in the evaluation, selection and the allocation and distribution of grant funds, CONSENSUS WAS ARRIVED AT FOR Mechanism A. The ALAC notes that presumption of the independent panel, with no connection to or control by either ICANN Org or the ICANN Board (preferably contracted to a suitable non-profit or a set of experts in the field of grant selection and allocation) is a CRITICAL part of this decision and the ALAC would strongly object and withdraw support if that condition changes. 

  • Do you have any concerns about the updates the CCWG has made, as listed above, in response to the Public Comment forum? If yes, please specify what changes concern you and why?

At Large agrees with the CCWG-Auction Proceeds decision on Recommendation #2. As we strongly believe that there needs to be an Independent Project Applications Evaluation Panel to review and evaluate all proposals. The Panel’s responsibility will be to evaluate and select project applications. We are in strong agreement that neither the Board nor Staff will be making decisions on individual applications. Members of the Independent Project Applications Evaluation Panel will not be selected based on their affiliation or representation but will be selected based on their grant-making expertise, ability to demonstrate independence over time, and relevant knowledge.

We are also in support of Recommendation #3 and agree with how the CCWG-Auction Proceeds has defined the objectives of new gTLD Auction Proceeds fund allocation. 

  • Benefit the development, distribution, evolution and structures/projects that support the Internet's unique identifier systems;
  • Benefit capacity building and underserved populations, or;
  • Benefit the open and interoperable Internet (see Annex C of the report for the complete definition of this statement

At Large also supports recommendations 4 through 6 and recommendations 9-12. 

On recommendation 7, we believe it should read “Must not have access” instead of “should not have access” we are requesting this change because, in practice, ICANN ORG generally adheres to IETF RFC 2119 which states that the word “Must” or the terms "Required" or "Shall", mean that the definition is an absolute requirement of the specification. However, “Should” or the adjective "Recommended", mean that there may exist valid reasons to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

On Recommendation 8, we do not believe that ICANN ORG should be able to participate in Auction Proceeds but we are not as clear on whether one of the representative bodies within one of the ICANN Constituencies, if they are legal entities in their own right, or whether an ALS which exists in its own right as a legal entity can submit a request provided that all applications meet the stipulated conditions and requirements, including legal and fiduciary requirements. 

  • Is there any further information you think the CCWG should consider, that it hasn't considered previously, in order to finalize its report for submission to the Chartering Organizations?




The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).


  1. I have made what I believe are a number of significant critical comments to the Google Doc on behalf of me and Sebastien.

    1. I would like to confirm that I support Alan inputs.

      I would like to add:

      I support mechanism A for the following reasons

      1. Icann need to decrease it complexity
      2. ALAC is in charge of culture, trust and silos

      1/ Icann need to decrease it complexity
      It is obvious that ICANN is more and more complicated and each time we add a new process we add complexity.
      Complexity is one of the items that we will need to take into account in prioritization of all the recommendations that are on ICANN table.
      Mechanism A is less complex to implement and give more flexibility to staff to find the right balance between permanente staff and outside help.

      2/ ALAC is in charge of culture, trust and silo in the Evolution of Multistakeholder model project
      Let’s start by trusting staff to do the right think.

      We can advice that ICANN org. need to consider implementing as and if needed a like mechanism B and that we (At-Large) are ready to help.

  2. Maureen drafted a new "Decision" section that was agreed to by all CCWG Members selected by the ALAC. She asked me to redraft the associated discussion which I have done (and which received her approval).

    It is now posted as the statement to be approved by the ALAC.

  3. I have also supported mechanism A during my participation in the CCWG work, mechanism A is more flexible and mechanism B has no clear advantage over it.