ICANN Logo

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

Click here to read comments on these recommendations.

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.1

Proposed Board resolution for Ombudsman

Therefore, it is resolved [02.xx] that the General Counsel of ICANN is authorized to post for public comment a Charter for the Office of Ombudsman that includes the following elements:

ICANN OFFICE OF OMBUDSMAN
CHARTER

Mission

The mission of the ICANN Ombudsman is to act as a neutral dispute resolution practitioner whose principal function is to provide independent, confidential and informal assistance to members of the ICANN community who believe that the ICANN staff or Board has treated them unfairly in some sense. The Ombudsman is not an advocate for any individual or for ICANN, but rather serves as an advocate for fairness who researches reported complaints regarding ICANN from the ICANN community and explores options to achieve equitable solutions to perceived unfairness. If the Ombudsman becomes aware, in attempting to resolve complaints, of systematic problems or procedural flaws that generate particular kinds of community complaints, the Ombudsman should bring these to the attention of the Board, along with recommendations for ways to improve ICANN operations and communication to reduce such complaints. The Ombudsman facilitates resolutions of problems and complaints as a neutral party by bringing the other parties together and clarifying the issues to help them explore options for solutions. The Ombudsman uses conflict resolution tools such as negotiation, facilitation, and shuttle diplomacy to achieve these results. The Ombudsman may also brings concerns and suggestions for policy changes to the ICANN Board of Directors and the public for their consideration and action.

General terms

The Ombudsman must be a respected, senior person known for his or her judgment, integrity and persuasiveness. The ICANN Ombudsman is a full-time position, with salary and benefits commensurate with senior ICANN management. Salary, benefits, and office budget will be determined by an independent panel designated by the Board. The Board will explore the creation of an endowment to maintain the ICANN Office of the Ombudsman. The ICANN Ombudsman will be appointed by the ICANN Board of Trustees for an initial term of two years, subject to renewal by the Board.2 Recommendations for candidates will be solicited by the Board from the ICANN community and from relevant professional associations, and a search committee of the Board will make a nomination to the full Board for their approval. The Ombudsman should be subject to dismissal by the Board for material errors of judgment, undisclosed conflicts of interest, unlawful activity, or failure to perform his or her duties. This is a new position, and the Board must retain some flexibility with respect to the services of the Ombudsman. At the same time, however, the Ombudsman should have adequate job security to be viewed by the community as a true neutral.

Duties

The ICANN Ombudsman shall:

1. facilitate the fair, impartial, and timely resolution of problems and complaints that affected members of the ICANN community may have with specific, unfair actions or failures to act by ICANN Board or staff;
2. exercise discretion to accept or decline to act on a complaint or question;
3. provide periodic feedback to the ICANN Board of Directors based on analysis of complaints made to the office and contact with ICANN community (such feedback should be made available publicly to the extent possible);
4. exercise discretion to make public statements about disputes and investigations to the extent permitted by the complainant, subject to appropriate confidentiality protections including ICANN's confidentiality policy, and without oversight by the Board;
5. heighten awareness of the Ombudsman program and functions through routine interaction with ICANN community, published office hours and online availability;
6. maintain neutrality and independence, and have no bias or personal stake in an outcome;
7. comply with the ICANN conflict policy regarding investments and relationships to safeguard against any conflict of interest with the mission of the office;
8. respond to community concerns regarding the Board's response to new policy processes;
9. establish and publicize procedures to dispose of complaints that are insufficiently concrete or insufficiently related to ICANN's interactions with the community so as to be inappropriate subject matters for the Ombudsman to act on (e.g., internal administrative matters, human resources policy, etc.).

Responsibilities of ICANN Staff and Board

All ICANN employees will cooperate with the ICANN Ombudsman so that the Ombudsman may carry out its mandate. To that end:

1. ICANN employees and Board Members shall:

a. assist and cooperate fully as appropriate with the Ombudsman in the performance of his or her official duties;
b. provide information and records reasonably requested by the Ombudsman and subject to appropriate confidentiality protections, including the ICANN confidentiality policy, in connection with an inquiry related to official matters;
c. respect decisions of the Ombudsman to protect the confidentiality of complainants or investigations; and
d. publicize the existence and purpose of the Office of Ombudsman and refer ICANN community complaints and/or related matters to the Ombudsman as appropriate; and
e. facilitate the effectiveness of the Ombudsman with appropriate support and leadership.

2. No ICANN employee or Board member shall prevent or impede the Ombudsman's contact with the ICANN community. ICANN employees and Board members shall encourage members of the ICANN community who voice problems, concerns, or complaints about ICANN to contact the Ombudsman regarding such problems, concerns, or complaints.

Confidentiality

1. The Ombudsman will maintain confidentiality to the extent requested by any complainant and permitted by law and will take all reasonable steps to protect any records and files pertaining to confidential discussions from inspection by other persons, including ICANN management.

2. No inquiry, report, recommendation, or other action of the Ombudsman shall be subject to examination or review in court, unless the Ombudsman is subject to criminal investigation.

Contacting the ICANN Ombudsman; Notice

1. Contact may be made with the Ombudsman through any available means, such as in person or by telephone, mail, e-mail, or facsimile.

2. Persons reporting allegations or concerns to the Ombudsman may do so anonymously.

3. Contact with the Ombudsman shall not constitute notice to ICANN of any particular action or cause of action.

Effective Date

The provisions of this charter are effective upon adoption by the ICANN Board of Directors.

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.3

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.

Proposed Board Resolution on Reconsideration

Therefore, it is resolved [02.xx] that the General Counsel is authorized to post for public comment a Reconsideration Policy with the following elements to replace the policy adopted on March 4, 1999, pursuant to ICANN Bylaws, Art. III, Sec. 4(a):

RECONSIDERATION POLICY

1. Members of the ICANN community may submit a request for reconsideration of an ICANN decision ("Reconsideration Request") to the extent that they have been adversely affected by:

a. staff actions or inactions that

i. contradict established ICANN Policy4 or

ii. are inconsistent with recognized facts; or

b. actions of the ICANN Board that have been taken based on incorrect or inadequate information.

2. The Board will establish and maintain a Committee of the Board consisting of not less than three directors to review and consider any such requests ("Reconsideration Committee"). The Reconsideration Committee will have the authority to: (i) evaluate requests for review or reconsideration, (ii) determine whether a stay of the contested action pending resolution of the request is appropriate, (iii) conduct whatever factual investigation is deemed appropriate, (iv) request additional written submissions from the affected party, or from other parties, and (v) make a recommendation to the Board of Directors on the merits of the request.

3. ICANN will absorb the normal administrative costs of the reconsideration process. It reserves the right to recover from a party requesting review or reconsideration any costs which are deemed to be extraordinary in nature.

4. Reconsideration Requests must be submitted by email to the Boardís Reconsideration Committee (reconsider@icann.org) within thirty (30) days after:

a. the date on which information about Board action is first made public (in a public meeting of the Board or via published minutes of telephonic Board meetings) complained of; or

b. the date on which they become aware of the staff action complained of; or

c. in the case of either Board or staff inaction, the date on which the affected person reasonably concludes that necessary action will not be taken in a timely manner.

5. Reconsideration Requests must include at least the following information:

a. name, address, and contact information for the requesting party, including postal and email addresses;

b. the specific action (including a decision not to act) of ICANN for which review or reconsideration is sought;

c. the date of the action;

d. the manner by which the requesting party will be affected by the action;

e. the extent to which, in the opinion of the member of the ICANN community submitting the Request for Reconsideration, the action or inaction complained of adversely affects other members of the ICANN community;

f. whether a temporary stay of the action is requested;

g. the (i) established ICANN Policy contradicted by the complained of action or inaction or (ii) the inaccurate or inadequate information on which this action or inaction was allegedly based;

h. what specific steps the requesting party asks ICANN to take - i.e., whether and how the action should be reversed, cancelled, or modified;

i. the grounds on which the action should be reversed, cancelled, or modified;

j. if a temporary stay of the action is requested, the harms that will result if the action is not stayed; and

k. any documents the requesting party wishes to submit in support of its request.

6. The Reconsideration Committee will post all Reconsideration Requests received.

7. The Reconsideration Committee shall have authority to consider Reconsideration Requests from different parties in the same proceeding so long as (1) the requests involve the same general action or inaction and (2) the parties submitting Reconsideration Requests are similarly affected by such action or inaction.

8. The Reconsideration Committee will review Reconsideration Requests promptly upon receipt and announce its intention to decline to consider or proceed to consider a Reconsideration Request within thirty (30) days after receipt of the Request.

9. The Reconsideration Committee announcement of a decision not to hear a Reconsideration Request must contain an explanation of this decision, including its basis for determining that an ICANN Policy has not been violated or that a decision to act or not to act was not based on inadequate or erroneous information.

10. The Reconsideration Committee may request additional information or clarifications from the member of the ICANN community submitting the Request for Reconsideration.

11. The Reconsideration Committee may ask the ICANN staff for its views on the matter, which comments will be made publicly available on the ICANN web site.

12. The Reconsideration Committee may act on a Reconsideration Request on the basis of the public written record submitted by the member of the ICANN community submitting the complaint and the ICANN staff.

13. If the Reconsideration Committee requires additional information, it may elect to conduct a meeting by telephone or, if acceptable and convenient to the party requesting reconsideration, in person.

14. To protect against abuse of the reconsideration process, a request for reconsideration may be dismissed by the Reconsideration Committee where it is repetitive, frivolous, non-substantive, or otherwise abusive, or where the affected party had an opportunity, but was unwilling, to participate in the public comment period relating to the contested action, if applicable. Likewise, the Reconsideration Committee may dismiss a request when the requesting party has not shown that it will be "affected" by ICANN's action.

15. The Reconsideration Committee will make a final recommendation to the Board with respect to a Reconsideration Request within a period that is no more than (a) ninety (90) days, or (b) the second Board meeting following its receipt of the request, whichever comes first.

16. The Board will not be bound to follow the recommendations of the Reconsideration Committee. The final decision of the Board will be made public as part of the minutes of the Board meeting immediately following its receipt of the Reconsideration Committee's recommendation, and in any event no later than [20] days following the decision.

17. The Reconsideration Committee will submit a report to the Board on a quarterly basis containing at least the following information:

a. the number and general nature of Reconsideration Requests received in the preceding calendar quarter; the number of Reconsideration Requests on which the Committee has taken action during the quarter;

b. the number of Reconsideration Requests that remain pending and the average length of time for which such Reconsideration Requests have been pending;

c. a description of any Reconsideration Requests that have been pending for more than ninety (90) days and the reasons that the Committee has not taken action on them;

d. the number and nature of Reconsideration Requests that the Committee has declined to consider on the basis that they do not meet the criteria established in this policy;

e. based on information about such denied Reconsideration Requests, the extent to which other mechanisms are available to ensure that ICANN is accountable to persons materially affected by its decisions; and

f. whether or not, in the Committeeís view, the criteria for which reconsideration may be requested should be revised, or another process should be adopted or modified, to ensure that all persons materially affected by ICANN decisions have meaningful access to an appeals process that ensures fairness while limiting frivolous claims.

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").5

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.6

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.

Proposed Board resolution

Therefore, it is resolved [02.xx] that the General Counsel of ICANN is requested to draft an Independent Arbitration Policy including the following elements:

Mission of the IAP

The mission of the Independent Arbitration Panel ("IAP") is to compare contested actions of the ICANN Board to the Bylaws of ICANN, and to declare whether the ICANN Board has acted consistently with the provisions of those Bylaws.

Process

1. Requests for independent arbitration are referred to the IAP, which will be operated by the [name of international arbitration association] using arbitrators under contract with or nominated by [name of international arbitration association].

2. Subject to the approval of the ICANN Board, the [name of international arbitration association] providing arbitration services will draft and implement its own operating procedures.

3. Members of the ICANN community requesting arbitration may elect that the issue be arbitrated by either a one-member or a three-member panel of arbitrators.

4. The [name of international arbitration association] will determine a procedure for assigning arbitrators to individual panels.

5. The IAP has the authority to: (i) request additional written submissions from the party seeking arbitration, the Board, the Supporting Organizations, or from other parties; (ii) declare whether an action or inaction of the ICANN Board was contrary to the Corporation's Bylaws; and (iii) recommend that the ICANN Board stay any action or decision until such time as the Board reviews and acts upon the opinion of the IAP.7

6. Individuals holding an official position or office within the ICANN structure are not eligible to serve as IAP arbitrators.

7. In order to keep the costs and burdens of independent review as low as possible, the IAP should conduct its proceedings by e-mail and otherwise via the Internet. Where necessary, the IAP may hold meetings by telephone.

8. The IAP will adopt, make public, and adhere to a conflicts of interest policy to ensure that IAP decisions are free from the influence of financial or other conflicts of interest.

Standards for Arbitration

1. A request for arbitration may be filed on the ground that the Board has acted or failed to act in a manner contrary to the Corporation's Bylaws.

2. Any individual or entity may file a claim if that individual or entity has been materially affected by the contested action or failure to act by the ICANN Board.

3. The IAP will base its decision on the basis of the written documentation and supporting materials submitted by the parties.

Openness and Transparency

1. The IAP operating procedures, and all petitions, claims, decisions on claims, and the rationale for each decision made by the IAP will be made public via the Internet.

2. The IAP may, in its discretion, grant a party's request to keep certain information confidential, such as trade secrets.

Costs

The party losing the proceeding should bear the cost of IAP proceedings.

 

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.

Click here to read comments on these recommendations.

Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

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