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
Recommendations Regarding Accountability
23 August 2002
I. Introduction and Background
II. The Blueprint
III. Preliminary Framework and ERC Commentary
V. Public Participation
VII. Bylaw Amendments and Alleged Infringements
VIII. Additional Recommendations and Observations
I. Introduction and Background
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
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
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
bottom-up (Core Values 2,
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
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
- 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
- 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,
- 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
- 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
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
- The accountability mechanisms identified in the Blueprint (Ombudsman,
Reconsideration, and Independent Review) provide accountability under
different circumstances and should be individually tailored to those
- 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.
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
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
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
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.
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.
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
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.
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.
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
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
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
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
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.
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
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):
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
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
4. Reconsideration Requests must be submitted by email to the Boardís
Reconsideration Committee (email@example.com) within thirty (30)
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
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
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
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,
i. the grounds on which the action should be reversed, cancelled,
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
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
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
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  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;
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
VII. Bylaw Amendments and Alleged
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
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.
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
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.
The party losing the proceeding should bear the cost of IAP proceedings.
VIII. Additional Recommendations
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:
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
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
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.
concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.