Skip to main content

Enhancing ICANN Accountability: Process and Next Steps

(Revised 10 October 2014)


On 14 March 2014 the National Telecommunications and Information Administration (NTIA) announced its intent to transition its stewardship of the Internet Assigned Numbers Authority (IANA) functions to the global multistakeholder community. NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN), as the IANA functions contractor and global coordinator for the Domain Name System (DNS), to convene a multistakeholder process to develop a proposal for the transition. This process is currently under way as further described here.

During discussions around the transition process, the community raised the broader topic of the impact of the change on ICANN's accountability given its historical contractual relationship with the United States and NTIA. Informed by community discussions held in March 2014 at ICANN's public meeting in Singapore, ICANN published a proposed process on Enhancing ICANN Accountability, with an opportunity for public dialogue and community feedback from 6 May – 27 June 2014, in addition to the comments received during the dedicated Enhancing ICANN Accountability session held on 26 June 2014 at the ICANN 50 meeting in London. In response to community requests for additional time to review proposals and post questions and comments, ICANN provided an additional 21-day comment period from 6-27 September 2014.

The proposed process defined the scope as ensuring ICANN remains accountable in the absence of its historical contractual relationship with the U.S. Government (USG), and the perceived backstop with regard to ICANN's organization-wide accountability provided by that role, such as the renewal process of the IANA functions contract. It called for an examination, from an organizational perspective, of how ICANN's broader accountability mechanisms should be strengthened to address the absence of its historical contractual relationship with the USG, including looking at strengthening existing accountability mechanisms (e.g., the ICANN Bylaws and the Affirmation of Commitments). The posting of the additional 21-day comment period reiterated that the process is intended to deal with focused systemic issues caused by the changing historical relationship with the United States, including for example, by stress testing against internal or external captures or takeovers, and safeguards against capture at all levels, which is a pre-condition of the IANA Stewardship Transition. Statements made by the NTIA since posting clarify that this process is limited to ensuring ICANN remains accountable in the absence of its contractual relationship with the USG. This process could potentially include an evolution of the AoC, but does not replace or duplicate existing ICANN accountability processes such as the Accountability and Transparency Reviews that deal with routine execution of tasks.

The original proposed process suggested the formation of an ICANN Accountability Working Group (WG) to lead community discussion; the method for selecting members of the WG with expertise in certain subject matter areas; the appointment of external subject matter experts by staff; the proposed output from the WG; and included a set of questions to collect community input to advance the work of the WG.

ICANN received a total of 49 comments submitted during the 6 May – 27 June 2014 online public comment period, in addition to the comments received during the dedicated Enhancing ICANN Accountability session held on 26 June 2014 at the ICANN 50 meeting in London. Those comments related to the development of the process have been considered in the refinement of the process. Many of the comments also addressed both issues for consideration for enhancements to ICANN accountability, or proposed solutions. Those issues and solutions are collected – without analysis – in a separate document for consideration by the community groups performing the work on Enhancing ICANN Accountability. Additionally, ICANN previewed several iterations of the proposed process and addressed comments, prior to the August posting.1

The next steps in the process as posted on 14 August included formation of a modified Accountability Working Group as proposed in the original proposal on 6 May. In an effort to address community feedback [PDF, 413 KB] the composition of the process was modified to include two groups:

  1. ICANN Accountability & Governance Cross Community Group (CCG); and

  2. ICANN Accountability & Governance Coordination Group (CG).

Following the community requested 21-day second round of comments, ICANN received 17 comments. Based on the input received from these comments, staff believes that the strong community comments in the second round of comments support integrating the originally proposed structure (CCG/Coordination Group) into establishing a Cross Community Working Group (CCWG) that incorporates some key elements that have arisen in the dialogues. Additionally, given the input over the course of the dialogue on this process, it's suggested that the CCWG has two work steams, one focused on accountability in view of ICANN's changing historical relationship with the USG, and the second, on the broader accountability issues the community would like to bring to the forefront.

The proposed process and next steps are outlined below.

ICANN Accountability and Governance Cross Community Working Group (CCWG)

As the CCWG framework is still under development by the community2 there is no base reference document with a framework of operating principles to which staff can point. However, based on our review of CCWG efforts and the current community dialogue to develop a framework of principles for CCWGs, staff understands that a CCWG typically includes the following characteristics:

  • Charter: Typically such a charter covers the following topics:

    • Purpose/Problem statement, goals & objectives and scope

    • Deliverables, timeframes & reporting to community on progress and public comment periods (Work Plan)

    • Membership, staffing and organization

    • Rules of engagement, including internal decision-making methodology, modification of the charter

    • Adoption of output problem/issue escalation and resolution processes in the effort

    The Charter typically is drafted by a Drafting Team (DT) that involves one or several of the (potential chartering) SO/ACs by reaching out to other SO/ACs to solicit their participation in the drafting team effort. However, others can be involved. Once the draft charter is completed, it is submitted by the chairs of the DT to each of the Supporting Organizations and Advisory Committees potentially interested in participating in the CCWG for their consideration.

    The unified Charter is normally adopted by SOs and ACs interested in participating in the effort, in accordance with their own rules and procedures. After adoption of the Charter, these SOs and ACs have become the chartering organizations. Other SOs and ACs, as well as those not associated with any SO/AC are encouraged to participate in the effort even if they are not in a position to formally adopt the Charter.

  • Membership: Each of the chartering organizations appoints members according to their own rules and procedures. Other participants may join the effort if this is specified in the Charter.

  • Meaningful opportunities for public comment and engagement of others. CCWGs follow standard practices regarding public comments and engagement with the broader community. This ensures that feedback and input are requested and received as broadly as possible, and also that the CCWG is required to demonstrate how the input received is considered and dealt with.

  • Endorsement of final report/final output of the CCWG by the chartering organizations before it is submitted to the ICANN Board. Each chartering organization, in accordance with their respective rules and procedures for approval, would adopt, endorse, or support the final output of the CCWG. Typically this is a Final Report. Furthermore, a CCWG Charter includes a mechanism to deal with cases in which one or more of the chartering organizations do not adopt the Final Report, should this occur.

Taking into account the above and also reflected in the comments received, in addition to the aforementioned characteristics a CCWG for Enhancing ICANN Accountability should reflect the following elements:

  • Participation open to all: The CCWG should allow for and encourage meaningful participation by anyone interested in this effort, including those who have already expressed an interest in engaging in the process through the originally proposed CCG, independent of association with a chartering SO/ACs, as other SO or AC, as newcomer or as someone who is not or does not want to be associated with a particular group at ICANN. For example, those who have already signed onto the CCG should be reached out to and included in discussions and next steps.

  • Scope of the accountability process – two work streams: The topic of accountability is important, and in the discussions around this process, areas and topics have been identified that are important to enhancing ICANN's accountability but not directly related to accountability in the context of the changing historical relationship with the USG.

    • To ensure that over time there's a mechanism to ensure coverage of all areas, including topics outside of the immediate scope of the process, a suggestion is that the CCWG establish two work streams or subgroups: one focused on the scope of the work on enhancing ICANN accountability in light of the changing relationship with the USG within the time frame of the transition (Work Stream 1); and a second focused on addressing topics on accountability outside the scope of Work Stream 1, which are longer term (and may include, for example, recommendations from the recent ATRT2 addressing current accountability mechanisms such as the Ombudsman, the Reconsideration process and the Independent Review process) (Work Stream 2). This could be reflected in the CCWG's Charter.

  • ICANN Staff: In addition to providing support to facilitate the workings of the CCWG, ICANN expects to be able to designate a staff representative to provide input into the deliberations and who is able to participate in this effort in the same way as other members of the CCWG. Should there be an issue of a consensus call, the staff representative would not participate in such a consensus call.

  • ICANN Board Liaison: The Board liaison should be an active member of the CCWG, bringing the voice of the Board and Board experience to activities and deliberations. Should there be an issue of a consensus call, the Board liaison would not participate in such a consensus call.

  • Advisors: The CCWG should integrate the Advisors appointed by the Public Experts Group (PEG) into its structure. The recommendations of the Advisors, if any, are expected to be documented in the CCWG's Final Report. The Advisors should contribute to the dialogue with other CCWG participants. Should there be an issue of a consensus call, the Advisors would not participate in such a consensus call.

  • ATRT Expert: The CCWG should integrate one ATRT past participant to bring perspective and avoid duplication of work. Should there be an issue of a consensus call, the ATRT Expert would not participate in such a consensus call. 

  • IANA Stewardship Transition Coordination Group linkage: ICANN suggests that a mechanism to liaise with work of the IANA Stewardship Transition Coordination Group (ICG) be established for Work Stream 1 of the Enhancing ICANN Accountability process, as the output of this is interconnected and part of the deliverable for the IANA Stewardship Transition proposal to NTIA.

Role of the Board

There were several comments relating to the role of the Board, in particular regarding the acceptance of recommendations from the process. This topic was also addressed in the 18 September 2014 letter [PDF, 500 KB] responding to the SO/AC/SG/C Leadership letter of 4 September. This is a matter for the Board to address, and the Board is considering how it can provide assurance to all stakeholders that it will seriously consider and respect the recommendations arising out of the review. More information on that issue will be forthcoming.

Role of the Advisors

Selected by the PEG, the Advisors provide additional supporting information and help contribute to the dialogue of the CCWG, including bringing additional expertise and best practices. While the Advisors can inform the dialogue or make recommendations, the Advisors will not participate in calls for consensus. However, the final report and recommendations should take into account input from the Advisors. The PEG, announced on 19 August 2014, consists of Mr. Brian Cute, Ms. Jeanette Hofmann, Amb. Janis Karklins, and Hon. Lawrence E. Strickling.

The areas identified for expertise include, for example:

  • Internet Technical Operations
  • International Organizational Reviews
  • Global Accountability Tools and Metrics
  • Jurisprudence / Accountability Mechanisms
  • Internet Consumer Protection (including privacy, human rights and property rights concerns)
  • Economics (Marketplace and Competition)
  • Global Ethics Frameworks
  • Operational, Finance and Process
  • Board Governance
  • Transparency
  • Risk Management
  • Governmental Engagement and Relations
  • Multistakeholder Governance

Output of the CCWG:

The CCWG is expected to prepare initial reports on Work Streams 1 and 2, including recommended timeframes for development of new or improved mechanisms, if any. Initial reports will be put out for public comment. This should occur for Work Streams 1 and 2, though given the deliverables, the timing of each report will be phased differently. The work of the CCWG should not reopen recommendations adopted for implementation by the ATRT processes but rather complement those and other initiatives underway. The CCWG work on Work Stream 2 could, for example, provide advice on the implementation of some of the ATRT2 recommendations.

Finalization of the full CCWG report and recommendations should include draft(s) having gone out for public comments and reflect the level of consensus.

Following public comment, the CCWG will submit its final report to the chartering organizations, which, following their process of endorsement, will submit it to the ICANN Board. The ICANN Board will review the report and recommendations.

Proposed Next Steps

Several stakeholders have already expressed an interest in the accountability process and the originally proposed Cross Community Group. These interested stakeholders should be able to participate in the proposed CCWG.

In order to hold a time and space should the community want to meet to begin discussions on next steps, there is time allotted during the ICANN51 meeting in Los Angeles, California that remains available for use by the community to begin working towards the development of the CCWG. The room is held for Monday, 13 October from 16:00 - 17:00 local time (see ICANN Accountability and Governance Cross Community Group Meeting).

The PEG will continue their deliberations to identify up to 7 Advisors to serve on the CCWG. Liaisons will be identified from the ICANN Board, and the ICANN Staff representative and the ATRT expert will also need to be identified via ATRT1 and ATRT2 participants.3

It is suggested that the CCWG formation process begin with the goal of convening its first virtual meeting in mid-November 2014.

It is expected that the CCWG will operate an open, transparent and inclusive process, primarily through remote participation opportunities4 that would include:

  • A website with a timeline of activities and events, all materials and communications from the CCWG and an archive of all content provided and evaluated throughout the process;
  • Multilingual participation will be facilitated;
  • Online tools of engagement to ensure anyone can remain involved in the activities and progress of the group;
  • Postings of transcripts and recordings, since all meetings and phone conferences will be open for stakeholders to observe;
  • Statements of Interest that participants in each process will be expected to maintain up-to-date during their duration of their CCWG membership.

1 See also 18 September 2014 Letter, and response to question 18.

2 See work of the CCWG for framework of CG principles (

3 See also 18 September letter [PDF, 500 KB], response to Question 5.

4 Consistent with other CCWGs, ICANN does not anticipate providing travel support to the CCWG membership.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."