ICANN: A Blueprint for Reform
Committee on ICANN Evolution and Reform
This Blueprint summarizes the recommendations of the Evolution and Reform Committee (ERC) to the ICANN Board of Directors.
In developing these recommendations, the ERC has listened carefully to comments and suggestions of all segments of the ICANN community both written and verbal statements, most of them public. We have considered and evaluated all of the many constructive suggestions received by the ERC. We have posted several documents of our own to stimulate response from and to engage in a structured and focused dialog with the community. We appreciate all of the considerable effort that has gone into so much thinking, dialog, and feedback from so many segments of the community and so many individuals. It is a tribute to the ICANN community that so many people care enough to participate in this important dialog.
There are many opinions across the ICANN spectrum, and the recommendations in this Blueprint will not be consistent with the full range of opinions. But it is time to make choices to reach decisions that will best serve the interests of the full set of ICANN stakeholders. This Blueprint represents our best judgment on those choices.
We urge the Board to use this document and its recommendations as a Blueprint for Action, a directional document for framing the details of transition that will need to be developed and implemented over the coming months leading to ICANN's meeting in Shanghai, China, in October 2002.
The springboard for this very constructive dialog was the paper "ICANN: A Case for Reform" posted by ICANN President Stuart Lynn in February 2002. We have found there to be general sympathy and understanding for the key problems that were identified in that document, problems that if left unsolved would hinder if not prevent future progress by ICANN. Some see certain problems as less critical or urgent than others; some advocate a more cautious, evolutionary approach; while others advocate dramatic change. In many cases, the approach cautious or radical change is very much determined by the position and interests of those advocating it. But almost all seem to agree that these problems are real and serious and must be addressed.
"The Case for Reform" was more controversial in some of its recommendations, less so in others. Some of the ideas in that document have been refined and carried forward in this Blueprint; others have been modified; others have been discarded, at least for now. In sum, however, we believe that the Blueprint we offer preserves the essence of the rationale for "The Case for Reform", namely, an ICANN that is:
Mission and Core Values: In the course of its work, the ERC carefully examined ICANN's Mission and Core Values, and received input on this subject from the broader community. After all, it is impossible to consider ICANN's future without a clear understanding of Mission we seek to accomplish. This has been a valuable undertaking, the results of which are included in this Blueprint.
One cannot discuss the Mission of ICANN without entering debates about "thick ICANNs" and "thin ICANNs". The ERC does not find these terms particularly useful because they mean different things to different people. Ironically, combining everyone's definition of thin leads in fact to a very thick ICANN.
Therefore, the ERC made an analysis of what ICANN needs and has been striving to achieve, and compared it with what ICANN currently does (a staff paper on this subject was very helpful, and it was enriched by community discussions). The ERC then asked for views on what should and should not be included, and from these analyses and the responses to them synthesized a refined statement of Mission and Core Values, as presented below.
The essence of the debate over ICANN's Mission lies in the nexus between ICANN's technical coordination role, its operational role, and its policy role. There are some who see ICANN as merely an agent to carry out technical, operational instructions. The ERC does not support this view because it leaves unanswered the question of responsibility for the policy-development work necessary to provide answers to precisely what instructions should be followed, that is, answering the question: "if not ICANN, then who?". We have not found any credible answers to that question offered by those who favor a purely technical operational ICANN, other than transferring such responsibilities to some international treaty organization, a direction that is viewed with disfavor throughout most of the community (as judged by the comments we received), or to a constellation of organizations that would again beg the question of who will coordinate these organizations.
In this sense, the ERC went back to a clear description widespread in the early days of ICANN's foundation: the technical coordination role need be performed by making decisions, and in order to avoid arbitrariness or an excessive ad-hoc approach, these decisions need be based on general policies. It is ICANN's task both to perform the technical coordination, and to obtain the policy guidance for it. Derived from this, also some operational activities are required.
ICANN, today, inevitably has a global policy role. That is quite different than the halcyon early days of the Internet before commercialization. And it may be quite different at some point in the future. And it is certainly true that much of the controversy that dogs ICANN derives from the inevitable clash of opposing viewpoints on many of these complex policy questions. But this is reality and cannot be wished away. ICANN provides a forum where policy development can occur through a process that strives to achieve reasonable consensus wherever it can, and move forward in instances where the consensus process is deadlocked. And that forum is necessary.
In the view of the ERC, there is not any more a legitimate debate over whether ICANN has a role in policy development and implementation. It does. We also believe that role should be limited to those policy areas that are reasonably related to ICANN's technical mission. The dividing line will not always be clear. For example, it may be obvious to most that ICANN should not develop policy in areas that require judgment about content. It is not our job. But there may be more differences of view as to when ICANN is outside its Mission parameters when it comes to matters such as promoting competition.
The ERC does not attempt in this Blueprint to define those boundaries precisely. There is much room for follow-on work in this regard. But we do emphatically reject the notion that ICANN should not be involved with policy development at all, or that its Mission boundaries are limited to policies that only address narrow technical operational issues. For example, ICANN responsibility for coordinating unique parameters can lead to the granting of exclusive control over an Internet resource, namely a top-level domain. It is reasonable to ask under what conditions such exclusive control should be granted, for how long, under what constraints, and with what degree of oversight. Even an extreme answer that none of these questions should be addressed is a policy decision in itself. And, again, if ICANN through its policy-development processes does not answer these questions, then who does?
What is critical is that ICANN addresses these questions with the full participation of those affected by its decisions in a manner that is reflective of those interests and the public interest. The ERC believes that the structures and processes proposed in this Blueprint will lead in that direction.
Moving Forward: We commend this Blueprint for Action to the ICANN Board and recommend that it be acted on in Bucharest. We also recommend that the Board appoint a Transition Team to work through the many details of implementation between now and ICANN's annual meeting in Shanghai. It is time to close this debate. ICANN must now move forward with dispatch.
ICANN Evolution and Reform Committee1:
June 20, 2002
The statement of Mission and Core Values recommended in this document tracks closely what was posted by the Committee on Evolution & Reform for public comment in the Working Paper on ICANN Mission and Core Values. It has been modified to reflect comments received as appropriate.
The Internet Corporation for Assigned Names and Numbers (ICANN) is the private-sector body2 responsible for coordinating the global Internet's systems of unique identifiers.
The mission of ICANN is to coordinate the stable operation of the Internet's unique identifier systems. In particular, ICANN:
In performing its mission, ICANN adheres to these core values and principles:
ICANN should engage in policy3 development to the extent and only to the extent as is reasonable to enable ICANN to fulfill its mission in conformance with its core values. A full discussion of the implications of ICANN's mission in this regard can be found in the Working Paper on ICANN Mission and Core Values.
The recommended structure tracks in principle what was posted by the Committee on Evolution and Reform in its Working Paper on the ICANN Structure and the Nominating Committee Concept. However, there are a number of changes reflecting the comments received and further considerations. The proposed composition of the Board of Directors has been changed. The notions that the Board would have the power to ratify selections of the Nominating Committee and to appoint the chairs of the policy development organizations have been eliminated. The composition of the Nominating Committee has been established to be representative of both particular interest groups and the broader public interest. The structure of the GNSO has been more clearly stated, and the role of the TAC more clearly described. Government involvement has been strengthened in various respects to reflect the public interest but without sacrificing the essential private sector nature of ICANN.
There should be three supporting organizations: the GNSO (Generic Names Supporting Organization), the CNSO (Country Names Supporting Organization), and the ASO (Addressing Supporting Organization). In the new structure, there would be no Protocol Supporting Organization (PSO).
There should also be four standing advisory committees of the Board: the GAC (Government Advisory Committee), the TAC (Technical Advisory Committee), the RSSAC (the DNS Root Server System Advisory Committee) and the SAC (Security Advisory Committee).
All Supporting Organizations and advisory committees would be appropriately staffed to facilitate effective performance.
The ASO performs well as a whole and through each of its members, and its structure should remain unchanged from its current structure. For consistency, a non-voting GAC liaison should be added. The name and functions of the Address Council and the ASO General Assembly would remain unchanged.
The ICANN Board of Directors is ICANN's ultimate decision-making body. It and it alone has the legal responsibility to make and be legally accountable for all policy and other decisions. It is ultimately responsible for the management of the policy development process. Therefore, while it is highly desirable to seek and wherever possible find consensus, it does not follow that even proposals that enjoy consensus support should receive uncritical Board approval. The Board has a fiduciary responsibility to make decisions on the basis of good faith judgment in furthering the public interest.
"Policy" is a term that does not apply to every action that ICANN takes, through its Board or otherwise. To qualify as a policy decision, a matter brought before the Board for Board action should exhibit some or all of the following characteristics:
Many, if not most, decisions made by the Board do not fit within this meaning of a policy decision. They may, for example, be decisions regarding a single one-off situation that has no foreseeable future applicability, or they may be administrative decisions. To the extent possible, however, other decisions made by ICANN should be made within the framework of already developed policies. Certainly, specific decisions may stimulate the need to develop broad policies.
Policy development through bottom-up consensus processes should be encouraged. To be presumptively binding, any policy developed must reflect a true consensus, that is, a policy acceptable to the great majority of those affected, with no strong and reasoned opposition. Any such policy recommended to the ICANN Board, if not acceptable to the Board, should be returned to the policy development body with a clear statement of the Board's concerns. If and when such a recommendation is returned to the Board as a true consensus policy recommendation, the Board may reject or modify such a recommendation only by a 2/3 vote. In the absence of true consensus being achievable, the Board will act according to its own best judgment accounting for community principles, needs, and desires as best it can interpret them.
In contrast, any recommendations made by ICANN's policy development bodies on matters other than policy as defined above should have only whatever persuasive merit is inherent in the recommendation.
A bottom-up, consensus-driven approach to policy development is preferable wherever such approaches do not prevent the Board from carrying out it's ultimate responsibility for ensuring policies are developed, approved, and implemented as necessary to accomplish ICANN's mission. That is, wherever practical, the development or modification of policies would benefit from undergoing policy development in the appropriate policy development body acting with appropriate community review and input.
New policy development or revisions to existing policies (collectively called "policy development") may be initiated by the Board or by the appropriate policy development body. Any policy development process, particularly when initiated by the Board, should have most of the following characteristics:
These general principles must be adapted by the Board to different circumstances. Emergency circumstances may be addressed by implementing temporary policies to be modified if necessary in follow-up work. The key elements are that in every situation there be a policy development plan including a timescale for completion, a process for receiving public input and other advice, and a process for seeking consensus where possible. To the extent feasible these plans should be developed before initiating the policy development process.
As indicated elsewhere, staff support must be provided to the policy development groups to ensure they can perform their work in a timely manner.
None of the above is intended to inhibit the Board from making policy decisions as appropriate in the absence of the ability of the community to reach consensus.
As part of the transition process, a task force composed of representatives from the broad ICANN community should be established to recommend a specific set of policy development procedures and timetables. The task force should complete its work before August 31, 2002, so that its recommendations can be posted for public comment prior to ICANN's meeting in Shanghai.
The Board makes other decisions besides policy decisions, as already mentioned. In so doing it should strive to make decisions fairly and equitably within the framework of existing policy decisions. It should also strive to receive advice from appropriate quarters to inform those decisions. To the extent that the Board is obligated to make decisions in the absence of existing policy, it should consider whether such situations that arise should trigger a new policy development process to provide guidance for analogous future situations.
This section on "Accountability" recommends improvements to current processes to advance ICANN's core values of openness and transparency. It also recommends ways to improve ICANN's structure and appeal processes to ensure fairness while limiting frivolous claims.
ICANN should create 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 should establish 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 ICANN Reconsideration Process should be amended 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.
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.
To strengthen the GAC's integration into ICANN and to strengthen representation of the public interest, the GAC should appoint (a) a non-voting liaison to the Board (b) one delegate to the Nominating Committee, and (c) non-voting liaisons to each of the SO Councils and to the RSSAC, the TAC, and the SAC. The GAC would decide whether or not any or all of these liaisons are members of the GAC. In each case, the liaisons should have sufficient expertise to participate effectively in each of these bodies.
The GAC should be requested to appoint a contact individual to coordinate when necessary between the IANA and particular government officials when there are delegations or redelegations pending, and to provide a focus for advice and information to other government officials. The GAC should be requested to participate in a dialog with ICANN and the ccTLD community to understand what steps might be taken to facilitate the consummation of agreements between ICANN and the ccTLDs that provide a framework of accountability, and other aspects of integration of the ccTLD community in ways that reflect its global diversity (see ccTLD Agreements above under the CNSO heading).
As and when needed to address specific issues and to help the Board arrive at specific decisions, Expert Advisory Panels or existing expert bodies should be established or consulted by the Board for independent expert advice on particular public policy matters relevant to those specific issues. Such panels or bodies could provide expert advice in such areas as competition, privacy, trademarks, etc. The advice received from such Advisory Panels would not be binding, but would add to the record available to the Board or policy development bodies as appropriate.
The core funding of ICANN should come from those registries and registrars with whom ICANN has an agreement. Today, these primarily are the gTLD registries and registrars. ICANN's base funding requirements should derive from these sources.
Other sources today include those name ccTLD registries and RIRs with whom ICANN does not now have a signed agreement. Care should be taken to ensure that discretion can be exercised to align expenditures within the framework of uncertainty deriving from these voluntary contributions.
The Board should pursue a funding mechanism that requires those registries and registrars with whom ICANN has an agreement to forward to ICANN a per-name fee (estimated to be about $0.25) adequate to meet the needs of ICANN as reformed, including the building of adequate reserves. This fee is collected by registrars and/or registries as appropriate on behalf of all beneficiaries of the ICANN process.
The funds generated by this process could be spent only pursuant to the public annual budget development and approval process with full public review and comment. Any funds generated that exceed the requirements of this budget would be used to build financial reserves to an appropriate level. If and when reserves reach the appropriate level, the amount of the beneficiary fee should be re-examined and reduced if appropriate.
The technical/operational IANA functions that ICANN continues to manage should be organizationally and financially segregated to the extent practicable from its policy and other support functions. External advisory bodies that do not interfere with existing arrangements (such as the IAB and other expert oversight of the IANA protocol numbering services) should be considered to provide user input on performance standards. The ERC sees no value at this time to separating the technical and policy functions into separate organizations, since it would only complicate the agreement structure that would need to be developed and add unnecessary bureaucracy and overhead to a lean structure. However, the ERC does recommend that the interface between policy and technical operations should be more clearly defined over the coming years.
1. Prior to his resignation, former ICANN Director Phil Davidson was also a member of the ERC during the formative stages of the Committee. His positive contributions and initial thrust are gladly acknowledged.
3. See Section 4 for a clarification of what is meant by "policy" in this context.
4. This IETF liaison should not be considered the sole source of IETF-related technical insight, but rather act as a conduit, allowing the IETF to bring appropriate experts to bear on a case by case basis.
5. Since the President is an ex officio Director,
there is no definite term. Any given individual serves for so long as
s/he is President. The office of President, however, is subject to re-election
by the Board at each annual meeting of the Corporation.
6. We recognize that ccTLDs involve more than country
names, but draw on country codes from the ISO 3166 list that is broader
in scope. We feel it important, however, to distinguish the CNSO as being
broader in scope than the ccTLD constituency.