Advisory Committee

An Advisory Committee (AC) of ICANN is a formal advisory body, composed of representatives from the Internet community with expertise or interest in a particular issue or policy area. Advisory Committees are not authorized to take action on behalf of ICANN. Their primary responsibility is to report their findings and recommendations to the ICANN Board. The role of the Advisory Committees and the scope of their advice is described in Article 12 of the current ICANN Bylaws.

History

The original ICANN Bylaws specified three advisory committees in Article VII - the GAC, the RSSAC, and an Advisory Committee on Membership, whose role was to recommend a process by which At Large members of the board would be nominated. Acknowledging that there was not yet an established Independent Review Process, the board amended Article VII two weeks later to include an Advisory Committee on Independent Review. Both ad hoc advisory committees were removed from the Bylaws in the October 1999 revision. Article VII remained unchanged through February 2002.

The 2002 Evolution and Reform Process involved a complete overhaul of ICANN's bylaws, organizational structure, and operations. The process formalized a roster of four advisory committees, and provided far greater detail regarding the activities and responsibilities of each AC:

• Governmental Advisory Committee - Provides advice to ICANN regarding government issues, policies, laws, regulations, and international agreements.
• Security and Stability Advisory Committee - Provides advice to ICANN on internet security, particularly regarding the internet naming address and allocation system.
• Root Server System Advisory Committee - Its main responsibility is to examine the security aspects of the root name serves of the Domain Name System (DNS) and advise ICANN regarding the issues affecting it, such as its operational requirements.
• At-Large Advisory Committee - Provides advice regarding the activities of ICANN that have a direct impact on the interests of individual Internet users.

These four advisory committees remain in operation today. The SSAC, RSSAC, and ALAC are each reviewed subject to ICANN's Bylaws regarding Organizational Reviews. Under the same provisions, the GAC is responsible for conducting its own review of its operations and effectiveness.

Provision of Advice

Since the adoption of the original Bylaws, ACs have been tasked with "report[ing] their findings and recommendations to the Board." The original Bylaws did not prescribe any particular method of reporting. The Bylaws adopted as part of the 2002 Evolution and Reform Process provided more detail regarding the structure and remit of each modern-day AC, but did not set any procedural or structural expectations for the delivery of advice.

The Bylaws adopted as part of the IANA Transition relocated the Advisory Committees to (no longer Roman) Article 12, and added prescriptive language regarding the provision of advice: advice is to be delivered through the submission of "clear and unambiguous written statement[s]," including a rationale for the provision of the advice. The current Bylaws maintain this language, noting that the ACs exist to advise the ICANN Community and Board on topics within each AC's purview. The Board's obligations regarding advice are also unchanged from the 2016 amended Bylaws: "The Board will respond in a timely manner to formal advice from all Advisory Committees explaining what action it took and the rationale for doing so" (Section 12.3 of the current Article 12; emphasis added). Although there is no definition of "formal advice," the inferred definition is advice submitted in written form as described in Section 12.3.

This leaves open the question of how, if at all, ACs may interject in other conversations that impact their constituencies. The First Accountability and Transparency Review recommended that the board seek methods of soliciting and incorporating advice into its decision making process in a more defined and transparent manner:

6. The Board should clarify, as soon as possible but no later than June 2011 the distinction between issues that are properly subject to ICANN’s policy development processes and those matters that are properly within the executive functions performed by the ICANN staff and Board and, as soon as practicable, develop complementary mechanisms for consultation in appropriate circumstances with the relevant SOs and ACs on administrative and executive issues that will be addressed at Board level.

While more broadly addressing transparency in issue identification and decision making by the board, the recommendation spurred an examination of the board's engagement with the community, and the timing and evaluation of advice from the ACs. The board identified three primary decision making processes that it engages in: review and approval of policy development processes; "Organizational Administrative Functions" that often "require or [benefit] from" public comment or AC advice; and Organizational Administrative Functions where no comment is sought (human resources matters, approval of minutes, appointment of board committee members and leaders, etc.). the board identified the current models for receiving inputs in the first two categories of decision making, and instructed the Board Governance Committee to seek further input from the community regarding how to improve or expand those models. Notably, the BGC distinguished these engagement efforts from "formal advice" given under the Bylaws and each AC's procedures:

ICANN’s Advisory Committees also have internal processes for provision of advice to the ICANN Board. However, there may be topics or issues for which the Board requests community input or advice that are not suitable or required to be addressed through PDPs and/or formal advice mechanisms.
There is no formal procedure in place whereby the ICANN Board can request this type of input or advice from the broader ICANN community. To date, the Board has made these requests through Board resolution or by letter, but neither process is sufficiently formal to ensure that the relevant SOs or ACs are fully aware of the request or address/provide the input or advice requested. This raises the question whether it would be beneficial to develop a more formalized process for requesting and developing community advice or input that does not require the implementation of a formal PDP and for which the public comment mechanism is not sufficient.

ATRT1 is also notable for a list of recommendations regarding how to improve communication between the ICANN Board and the GAC, and better define the process through which GAC advice is requested and received.

Procedure and Process

Procedures

The bylaws grant each Advisory Committee the power to establish its own procedural rules, quorum, chairman, and members. The chairman and members of the specific committees do not receive any compensation, however, the ICANN Board will reimburse the necessary expenses spent by the committee members while performing their obligations in connection with ICANN activities. Members serve in a committee until a successor is appointed, he or she resigns from duty or is no longer qualified to serve as a member.

Advice Process

Formal advice is processed through the Action Request Register (ARR), a centralized system for tracking and managing recommendations given to the board. There are five phases, from an acknowledgment of the advice to closure. Advice from SSAC can also be deferred at two points in the process: after step 3, Evaluate & Consider; and after step 4, Implement. In both cases, action on advice may be deferred "pending completion of external activities."

1. Receive & Acknowledge

   After advice is submitted to the ICANN Board, ICANN Organization logs it in the ARR and acknowledges receipt to the Advisory Committee.

2. Understand

   ICANN Org then reviews the advice and drafts a short summary of the perceived actionable item for the ICANN Board and/or org. This draft statement is sent to the Advisory Committee to confirm that it agrees with the understanding or provide feedback.

3. Evaluate & Consider

   Once the AC has agreed with the statement, ICANN org assesses what action is required, evaluates its feasibility, and develops preliminary implementation recommendations for Board consideration. Then the AC needs to confirm whether it agrees with the implementation recommendations.

4. Implement

   ICANN org develops an implementation plan and shares it with the Advisory Committee and Board. ICANN org then executes the plan and reports on the progress

5. Close

   Regardless of the outcome of ICANN org’s evaluation and implementation, ICANN org communicates the end result to the AC for feedback on the resolution of the advice. If the AC does not agree with the end result or a resolution is not possible, ICANN org informs the Board of the potential impasse.

Advice Outcomes

Advisory Committee input to the board has been instrumental in ICANN's history in a variety of ways.

• In 2004, the SSAC was brought into the spotlight during the fallout from Verisign's SiteFinder service.
• The GAC's Early Warning process during the New gTLD Program had substantial impacts on some applied-for strings. Notably, their advice regarding the delegation of .amazon was overturned after an Independent Review Process that determined that the ICANN board had given the GAC advice too much deference.
• The RSSAC's RSSAC037 document, "A Proposed Governance Model for the Root Server System," was a critical update to and reference point for management of the DNS root server system.
• The ALAC's advice regarding SSAD echoed other concerns within the ICANN community. The ALAC's broader critique of policy development processes that lead to unworkable proposals remains a salient topic in ICANN's ongoing conversations about its Prioritization Framework and the Evolution of the Multistakeholder Model.

In recent years, the ICANN Board's capacity to process advice from the ACs has been strained by the volume of inputs demanding the board's attention. At ICANN 73 the ACs registered disappointment that their advice was not receiving due attention. At the joint meeting of the GAC and the board, Jorge Cancio noted that some of that could be attributed to the timeframe in which advice is received:

The idea of a question, at least in my eyes, is when is the input from the GAC or from any other advisory committee, most opportune. Most efficient because if -- when it comes after the recommendations are finalized by the GNSO, for instance, and the decision is already before the Board, and the GAC or ALAC or some other advisory committee issues an advice on those recommendations, which would, for example, imply that some of the recommendations are adapted, if the Board's role in your understanding is not to change those recommendations, it's not possible to say okay, recommendation 6 says we will do A, B and C but ALAC and GAC say that we should also do D, so we ask the Board to decide that the final recommendation has to be A, B, C and D. If that is not your role, then this calls a little bit into question what is the affectivity, the efficiency of such advice, that moment this time.

Pending Action on Advice

As of March 2022, the ICANN Board was moving 151 advisory statements through its process. Thirty-one advisories had been closed within the twelve month period ending in March 2022. However, the method of counting advice in the ARR creates a challenge in understanding the volume of advice received. As an example, the ICANN website currently lists 53 advice submissions from the ALAC in processing stages. A closer look at those submissions reveals that 40 of the listed advisories are specific components of the ALAC's advice regarding the SUBPRO final report. Each recommendation contained with the ALAC advice is individually listed for tracking purposes. The table below treats each piece of advice submitted to the board as one whole, rather than multiple constituent parts.

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Root Server System Advisory Committee. Advises the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System (ICANN Bylaws).

At-Large Advisory Committee. Considers and provides advice on the activities of ICANN related to the interests of individual Internet users (ICANN Bylaws). Not to be confused with the Non-Commercial Stakeholder Group.

Governmental Advisory Committee. Considers and provides advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues (ICANN Bylaws).

Policy Development Process

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).