Accountability Framework Assistance Project: Recommendations Regarding Accountability

23 August 2002

As noted in its 15 July 2002 Status Report, the ICANN Committee on Evolution and Reform has asked Becky Burr to provide recommendations for implementing several specific aspects of the Blueprint dealing with accountability. These include suggestions for the charter of the Office of Ombudsman, the independent review arbitration process for alleged bylaw violations, and appropriate modifications of the Reconsideration Policy of ICANN. The following document describes her recommendations in response to that request. The Evolution and Reform Committee thanks Ms. Burr for this very helpful contribution.

Accountability Framework Assistance Project (Becky Burr)
Recommendations Regarding Accountability

23 August 2002

Contents

I. Introduction and Background

II. The Blueprint

III. Preliminary Framework and ERC Commentary

IV. Ombudsman

V. Public Participation

VI. Reconsideration

VII. Bylaw Amendments and Alleged Infringements

VIII. Additional Recommendations and Observations

I. Introduction and Background

"ICANN: A Blueprint for Reform" (the "Blueprint") was drafted by ICANN's Committee on Evolution and Reform ("ERC"), and adopted by the Board of Directors at the ICANN meeting in Bucharest, Romania. The Blueprint articulated ICANN’s "core values" – including the commitment to "remain accountable to the Internet community through mechanisms that enhance ICANN's effectiveness." The ERC asked me to provide recommendations for implementing several specific aspects of the Blueprint dealing with accountability including suggestions for the charter of the Office of Ombudsman, the non-binding arbitration process for alleged bylaw violations, appropriate modifications of the Reconsideration Policy of ICANN, and the role of a proposed staff member designated by ICANN to manage and enhance public participation in the ICANN process.

My recommendations are based on the core values laid out both by the ERC in the Blueprint and by the ICANN Board, in its action on June 28 in Bucharest, Romania accepting and endorsing the Blueprint. These values require ICANN to operate under processes that: (i) encourage bottom-up policy development by affected groups, (ii) encourage broad, informed participation of affected parties reflecting the functional, geographic, and cultural diversity of the Internet; (iii) are open and transparent; (iv) ensure that ICANN is accountable to those entities most affected by its decisions; and (v) ensure the neutral and objective application of documented policies. This report also contains recommendations regarding (i) improvements to current processes to advance ICANN’s core values of openness and transparency and (ii) improvements to ICANN's structure and appeal processes to ensure fairness while limiting frivolous claims.

In developing these recommendations, I also considered the comments of the U.S. Department of Commerce and the Government Advisory Committee that ICANN clarify and limit ICANN's mission and responsibilities, and reform its decision-making processes to provide for transparency and accountability and to permit the views of all Internet stakeholders to be heard. Finally, I have considered the recommendations and adopted some of the vocabulary contained in the report of the Policy Development Process Assistance Group, chaired by Rita Rodin.

I initially asked several individuals, representing different backgrounds, perspectives, and expertise, to assist me in this undertaking. For a variety of reasons, largely related to time constraints, these recommendations reflect my views only. Recognizing that ICANN reform cannot be accomplished overnight, these recommendations address the limited scope of the ERC's request for assistance, and should not be viewed as a statement of support for the adequacy of the accountability mechanisms detailed in the Blueprint. The Board has indicated that it will consider additional suggestions to "strengthen ICANN’s capacity to fulfill its mission." Accordingly, I conclude with general observations about ICANN’s "next steps" on the road to accountability.

II. The Blueprint

The ERC recognized that ICANN's decision making process must be perceived as unbiased (Core Values 7 and 8), bottom-up (Core Values 2, 3, 4, and 5), and adequately documented (Core Value 8). To enhance these core values, the ERC recommended mechanisms to facilitate (a) public understanding of ICANN's work; (b) public participation in ICANN's policy development process; and (c) review of Board and staff decisions where appropriate.

As outlined below, the ERC identified three accountability mechanisms, the Ombudsman, the Reconsideration Process, and a non-binding arbitration process to review allegations that the Board has acted in conflict with ICANN's bylaws. As defined by the ERC, these three mechanisms serve important and distinguishable purposes. The Ombudsman is designed to serve as a neutral, informal advocate of fairness within the ICANN process concerning both Board and staff actions. By contrast, the formal Reconsideration Process is run by a subcommittee of the ICANN Board rather than a neutral, is public at all levels, and concerns itself with fixing "erroneous" decisions only. And the non-binding arbitration is designed as a more formal process to review allegations that the Board has acted in conflict with ICANN's Bylaws. All of these processes can contribute to the sense that disputes with ICANN's Board and staff are aired and resolved fairly and efficiently.

On August 1, 2002, the ERC posted its First Interim Implementation Report (the "First ERC Report"), in which it expanded on the accountability discussion contained in the Blueprint:

• the First ERC Report characterizes the Ombudsman as an "advocate for fairness" in the ICANN process:
  • The First ERC Report foresees a limited role for the Ombudsman, which involves (1) determining the facts relating to a complaint, (2) reaching a conclusion about whether the complaint is well-founded, (3) if so, seeking to facilitate a mutually satisfactory resolution, and (4) reporting to the Board and the community on his work.
  • The ERC also recognizes that the Ombudsman is a potential source of suggestions on how to improve ICANN procedures and processes to reduce complaints, but does not consider this one of the Ombudsman's primary responsibilities.
• The ERC believes that the principal responsibility of the staff-level Manager of Public Participation ("MPP") is to ensure that the mechanisms for receiving and considering public input on ICANN decisions are effective.
  • Specifically, the ERC envisions that the MPP will be responsible for ICANN’s website, for e-mail or other forums managed by ICANN, and perhaps for providing or overseeing ICANN staff support for any specific mechanisms (such as the At Large Advisory Committee currently under consideration) designed to facilitate general public involvement in ICANN.
• The ERC believes that the ICANN Reconsideration Process should be limited to (1) situations in which the ICANN staff is alleged to have acted erroneously (without authority, inconsistent with existing policy and the like), and (2) situations in which the Board is alleged to have made an error because of incorrect or inadequate information, or otherwise.
• Under the ERC proposal, non-binding arbitration will be available exclusively to address allegations that the Board has acted in conflict with ICANN's bylaws.
  • ERC considers the ICANN Mission Statement and Core Values contained in the Blueprint a workable and appropriate set of constraining principles against which a particular ICANN action can properly be tested.
  • The ERC considers that expanding the range of issues appropriate for independent review will create a costly, unworkable Supreme Court or "Super Board" with the ability to nullify decisions reached by the ICANN Board.
  • To the extent that this view of the appropriate role for independent review is inconsistent with many of ICANN’s existing agreements, the ERC believes that those agreements can and should be conformed to this standard.

III. Preliminary Framework and ERC Commentary

On July 29, 2002, I submitted a Preliminary Framework for accountability mechanisms that articulated the assumptions on which my work would proceed:

• No single mechanism will ensure that ICANN is accountable to parties affected by its decisions.
• Accountability requires clear processes for facilitating public understanding of ICANN’s work and appropriate public participation in ICANN's policy development and other decision-making efforts.
• The role of the Manager of Public Participation is to prevent disputes with ICANN staff and the Board by increasing public understanding of and enhancing public participation in ICANN's work.
• The remaining accountability mechanisms should be designed to air and resolve disputes with ICANN's Board and staff fairly and efficiently.
• The accountability mechanisms identified in the Blueprint (Ombudsman, Reconsideration, and Independent Review) provide accountability under different circumstances and should be individually tailored to those circumstances.
• At the same time, the accountability mechanisms should, collectively, ensure that all persons materially affected by ICANN decisions have meaningful access to an appeals process that ensures fairness while limiting frivolous claims.

In general, the First ERC Report agreed with these assumptions. The ERC expressed its concern that they anticipated a broader set of responsibilities for the Manager of Public Participation than as described in the Blueprint. Finally, the ERC reiterated that the scope of the request for assistance on accountability was limited to mapping out the mechanics of implementing the skeleton set forth in the Blueprint. The Board noted, however, that it would, as directed by the Board in resolution 02-79, carefully review and consider additional suggestions "for strengthening ICANN's capacity to fulfill its mission" to the extent that they advance the goals set forth in the Blueprint and are consistent with the structure set out in the Blueprint.

IV. Ombudsman

The ERC Blueprint called for the creation within ICANN of:

an Office of Ombudsman, headed by an Ombudsman hired by and reporting directly to the ICANN Board. The Office should have its own budget, directly authorized by the Board (but administered for reasons of financial control and other purposes by the President/CEO). The Office should operate under a charter adopted by the Board after public notice and comment.

ICANN's Ombudsman should be a designated neutral or impartial dispute resolution practitioner. The Ombudsman should not be an advocate for any individual or ICANN but, rather, should serve as an advocate for fairness who assists in the resolution of concerns and critical situations. The Ombudsman will complement other ICANN accountability mechanisms such as the Reconsideration process and the arbitration panel (as described below).

While the role of the Ombudsman must be somewhat flexible, it should be clear that the sphere of his or her duties will be directed outward, focused on actions or inactions by the ICANN Board or staff that affect members of the ICANN community. Matters that relate only to the internal management and administration of ICANN (hiring, firing, human resources policies, relationships with vendors, etc.) should not be within the scope of the Ombudsman.

Given that the Ombudsman needs to be impartial in fact and in appearance, it will be important that the selection process inspire confidence on the part of the ICANN community. The power to appoint the Ombudsman should be vested with the ICANN Board of Directors. A Board-appointed position would send an appropriate signal, both to the community and to ICANN staff, about the stature of the position. The Board should create a search committee for the position and solicit nominations from the ICANN community as well as from relevant professional associations.¹

V. Public Participation

The Blueprint calls for the creation of

a staff position (working title: Manager of Public Participation) responsible for developing mechanisms to encourage full public participation in ICANN, and to facilitate the receipt and analysis of all public comments received on a given proposed action by the ICANN Board. This position would also be responsible for the design and content of other relevant outreach activities, including the ICANN website, public forums and mailing lists, and other options for public comment and participation.

The Manager of Public Participation (MPP) should work in close tandem with the Board, Staff Manager (as defined in the recommendations of the Policy Development Process Assistance Group) and each Supporting Organization to ensure that procedures are in place to facilitate public comment on policies that are in development or with regard to other issues on which public comment is otherwise appropriate and/or sought by the Board. The MPP should also, to the maximum extent possible, involve himself or herself in ensuring that public commentary on and information about the work of ICANN is presented in a variety of user-friendly, accessible fashions through web pages, public forums, and other mechanisms. The MPP, in consultation with the Staff Manager, should report to the Board at regular intervals on the status of public participation and outreach, the usability of ICANN's web resources, the status of Board decisions on which public commentary or advice has been sought, and the status of any policy development process.

The MPP should ensure that appropriate procedures are in place to facilitate the development of consensus by working with the Board and the Supporting Organizations (including especially, if created, the At Large Advisory Committee) to assist the Staff Manager engaged in a Policy Development Process.³

The MPP should work with Staff Managers to create a web-accessible docket system for all policies in development, and should track the progress of formal policy development processes within the relevant Supporting Organization and at the Board level. The MPP should also make available tracking information concerning other decisions on which the Board has sought advice or input.

The MPP should work closely with the ALAC, if established, to ensure that public participation in ICANN activities is meaningful.

The job description for the Manager of Public Participation should include the following elements:

1. The Manager of Public Policy should be a respected person known for his or her judgment, efficient work habits, and technical ability.

2. The position of MPP should be a full-time job.

3. Functions to be performed by the MPP, shall include (but not be limited to):

a. involving himself or herself in ensuring that public commentary on and information about the work of ICANN is presented in a user-friendly, accessible fashion through web pages, public forums, and other mechanisms;
b. reporting periodically to the Board and the ICANN community on the status of public participation and outreach, the usability of ICANN's web resources, and the status of any policy development process tracking mechanisms;
c. working with the ICANN Board, staff, advisory committees, task forces, and supporting organzations to ensure meaningful public participation in the ICANN process; and
d. creation of a web-accessible docket system for all policies in development to enable public tracking of all draft policies within the relevant Supporting Organization and at the Board level.

VI. Reconsideration

The ERC Blueprint recommends the existing Reconsideration policy:

to apply to (a) actions by staff alleged to contradict established Board policy or to be inconsistent with known facts, or (b) actions by the Board alleged to be based on error or lack of relevant information. The Reconsideration Process should require that the Board consider any reconsideration request no later than the second Board meeting following receipt of the request.

The Blueprint's proposed recommendations narrow the subject matter of complaints for which reconsideration may be requested to (1) situations in which the ICANN staff is alleged to have acted without authority or in a manner that is inconsistent with existing policy, and (2) situations in which the Board is alleged to have made an error because of incorrect or inadequate information, or otherwise.

The second recommendation of the Blueprint is that the Board should "consider any reconsideration request no later than the second Board meeting following receipt of the request."

The current Reconsideration Policy allows a petitioner to request a temporary stay. In such situations, the petitioner must "identify what harms will result if the action is not stayed." Because the Blueprint is silent on this point, I assume that the Board intends to retain the stay policy, and will endeavor to give complainants a quick response to stay requests. Additionally, the Board should continue its practice of publishing the submitted requests and the Committee's responses to them.

VII. Bylaw Amendments and Alleged Infringements

The Blueprint addresses this issue as follows:

Amendments to the ICANN Bylaws should continue to require a 2/3 majority of all voting Directors. The Board should create a process to require non-binding arbitration by an international arbitration body to review any allegation that the Board has acted in conflict with ICANN's Bylaws. The costs for such arbitration would be borne by ICANN should the review favor the person making the allegation, and vice-versa.

With respect to the requirement that Bylaw amendments must be supported by a 2/3 majority of all voting Directors, no additional implementation details are needed.

As the ERC Blueprint proposes, an "international arbitration body" can address, in a non-binding manner, claims that the Board has acted in violation of the Bylaws. For ease of reference, this panel of arbitrators playing these roles is referred to as the independent arbitration panel ("IAP").⁵

The IAP will need to be funded, and individual panelists will need to be paid. Just as funding is needed for proper staff for ICANN, funding is needed for proper staff for the institutions that will increase ICANN's accountability. Thus, complainants and ICANN should, in general, share the cost of IAP proceedings. However, the arbitration of frivolous claims should not be funded by ICANN. The ERC Blueprint propose to achieve this by creating a system, used in a number of countries today, whereby the losing party pay the costs.⁶

All filings before the IAP, and all IAP decisions, should be public. The IAP's decisions will be nonbinding, because the Board will retain final decision-making authority (as set forth in the Blueprint). But the IAP's decisions should have persuasive public power – and can only have this power if they are easily available.

VIII. Additional Recommendations and Observations

The ERC Blueprint begins but does not complete the job of providing accountability mechanisms to ensure important aspects of some of the most important core values that it has identified. The ERC Blueprint identifies several mechanisms for enhancing ICANN's accountability to the Internet community it serves and begins the work of building a strong accountability framework, but I remain concerned that the Blueprint framework will ultimately prove inadequate precisely because, as the ERC acknowledges, today ICANN must play a global policy role.

While reform of ICANN will not occur overnight, and the ERC may be wise to recommend a manageable set of initial tasks, I believe that the ERC should, on a priority basis, consider the need to develop mechanisms to assign responsibility for and ensure meaningful accountability with respect to three important issues:

Mission Creep

Because Bylaws can be changed, flexible protection against perceived ICANN "mission creep" is needed. There will always be a large set of cases in which the policy questions being decided by ICANN are closely enough related to sound operation of the registration market (or optimal operation of the Internet) that they ought to be within ICANN's mission as reflected by the Bylaws, but also as to which there are differing views about what is the best global rule to adopt. The ERC Blueprint lacks a mechanism for providing accountability with respect to by-law revisions that expand the scope of ICANN's mission.

Abuse of the Policy Development Process

The decision to treat a particular decision as "policy" subject to the policy development process and about which a supermajority vote (as described in the Recommendations of the Policy Development Process Assistance Group) is required is a fundamental aspect of ICANN's operations. It is a decision that can be manipulated or abused by the ICANN Board, the ICANN staff, or ICANN supporting organizations and other policy development bodies to the detriment of various stakeholders. Although the Recommendations of the Policy Development Process Assistance Project articulate a standard for determining whether or not an issue is properly the subject of policy development, ICANN lacks an accountability mechanism to check misuse of authority to determine whether or not a particular action would constitute or require the development of policy.

Standard of Review

Accountability mechanisms will fail to serve their purpose in the absence of a workable standard of review against which ICANN actions can be measured. The standard of review implicitly adopted in the Blueprint, and more explicitly articulated in the Recommendations of the Policy Development Process Assistance Group, requires that when making controversial decisions, a super-majority of the ICANN Board must exercise reasonable judgment about the best interests of the ICANN community. This standard may be adequate for many of the issues ICANN must resolve. But in some circumstances, especially those involving challenges to policies that impose constraints or obligations on commercial actors, that standard may prove a slender thread on which to hang ICANN's long term effectiveness. Although the development of accountability mechanisms relevant to ICANN's contractual obligations with registries and registrars is outside the scope of the ERC request for assistance, ICANN will need to address that issue as a priority matter. A workable standard of review in this context is one that eliminates existing disincentives to hold out and reassures businesses obligated to follow ICANN policies (as well as their investors) that they can operate their businesses within reasonable parameters.

Notes:

1. A recent ombudsman salary survey found that corporate ombudsman salaries in 2001 averaged $124,000, with the median salary at $109,500. The range of salaries for ombuds in the U.S. government in 2001 ranged from the upper $60,000 to $150,000, with an average salary of $102,000.

2. It may be desirable to lengthen this term after ICANN has acquired experience with the ombudsman mechanism.

3. The Recommendation of the Policy Development Assistance Group contemplates ICANN’s designation of a Staff Manager with various responsibilities designed to facilitate ICANN’s policy and development process. Some of these responsibilities overlap with recommendations contained herein regarding the MPP (e.g., maintaining an electronic docket on policy development activities and creating an electronic template for electronic submissions of public input. The roles of the MPP and the Staff Manager clearly require some further clarifications to avoid duplication. As the Blueprint is implemented, ICANN should consider how these two positions should relate to each other, and whether some sort of reporting relationship would enhance ICANN’s accountability by concentrating rather than diffusing ultimate staff responsibility (subject, of course, to supervision by the president and the Board) for participation in policy debates.

4. "Policy" is defined in the Recommendation of the Policy Development Assistance Group as an ICANN Board action having the following characteristics: (a) it is within ICANN’s mission statement; (b) it is broadly applicable to multiple situations or organizations; (c) is likely to have lasting value or applicability; (d) will establish a guide or framework for future decision-making; or (e) implicates or affects an existing ICANN policy.

5. We note that the current contracts call for certain ICANN actions to be subject to review by an “independent review panel.” Consistent with the approach taken by the Policy Development Process Assistance Group, these recommendations do not address ICANN’s obligations under its contracts with registries and registrars, and are not intended to be a substitute for or implementation of those obligations.

6. An alternative, which would discourage frivolous claims but is more likely to result in a public airing of “close calls,” would be to have ICANN bear the costs, or split the costs between the parties, subject to a "quick look" by the IAP. If, within a short period of its receipt of the claim, the IAP decides that the claim is frivolous or brought in bad faith, but the complainant persists and loses, the complainant should bear all costs.

7. The Bylaws of the Corporation should be amended to require the Board to act on the IAP's declaration at its next meeting or within 30 days, whichever is sooner.

Page updated 20-Aug-2003
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.