Difference between revisions of "Advisory Committee"

From ICANNWiki
Jump to navigation Jump to search
Line 35: Line 35:
 
* The [[RSSAC]]'s RSSAC037 document, "A Proposed Governance Model for the Root Server System,"<ref>[https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf RSSAC037 - A Proposed Governance Model for the Root Server System], June 15, 2018</ref> was a critical update to and reference point for management of the DNS root server system.  
 
* The [[RSSAC]]'s RSSAC037 document, "A Proposed Governance Model for the Root Server System,"<ref>[https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf RSSAC037 - A Proposed Governance Model for the Root Server System], June 15, 2018</ref> 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]].
 
* 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:
 +
<blockquote>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.<ref>[https://73.schedule.icann.org/meetings/zEse3bALxXMxoi2rz ICANN 73 Archive - Joint Session: ICANN Board and GAC], March 9, 2022 (registration/login required)</ref></blockquote>
  
 
==References==
 
==References==

Revision as of 18:30, 28 March 2022

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.[1] 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.[2] 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.[3] Both ad hoc advisory committees were removed from the Bylaws in the October 1999 revision.[4] 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.

Procedure and Process

Procedures

The bylaws grant each Advisory Committee the power to establish its own procedural rules, quorum, chairman, and members.[1] 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.[1]

Advice Process

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.[5]

  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,"[6] 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.[7]

References