ICANN: A Blueprint for Reform
Posted: 20 June 2002
Committee on ICANN Evolution and Reform
ICANN: A Blueprint for 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:
- More effective in fulfilling its mission;
- Constrained by streamlined processes that encourage full participation by the community yet unburdened by time-consuming procedures that impede effectiveness;
- Led by a credible Board of Directors that places public over private interest while being responsive to the latter;
- Responsive to the interests of those affected most by its decisions;
- Supported by an organizational structure that can seek consensus where possible in the policy development process, and do so in a timely and effective manner;
- Able to act appropriately even when widespread consensus is not forthcoming;
- Able to deliver services effectively and efficiently;
- Able to embrace individual and other forms of participation in meaningful ways;
- Adequately funded to fulfill its mission;
- Continuing to operate openly and transparently in the public interest.
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:
Alejandro Pisanty, Chair
Lyman Chapin
Hans Kraaijenbrink
Nii Quaynor
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:
a. Coordinates the allocation and assignment of three sets of unique identifiers for the Internet;
- Domain names (forming a system referred to as "DNS");
- Internet protocol (IP) addresses and autonomous system (AS) numbers; and
- Protocol port and parameter numbers.
b. Coordinates the operation and evolution of the DNS's root name server system.
c. Coordinates policy-development as necessary to perform these functions.
In performing its mission, ICANN adheres to these core values and principles:
1. Preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet.
2. Respect the creativity and innovation made possible by the Internet by limiting ICANN's activities to those matters within ICANN's mission requiring or significantly benefiting from global coordination.
3. To the extent feasible, delegate coordination functions to responsible entities that reflect the balance of interests of affected parties.
4. Seek and support broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet, at all levels of policy development and decision-making.
5. Where feasible, depend on market mechanisms to promote and sustain a competitive environment.
6. Introduce and promote competition in the registration of domain names where practicable and beneficial in the public interest.
7. Employ open and transparent policy development mechanisms that (a) promote well-informed decisions based on expert advice, and (b) ensure that those entities most affected can assist in the policy development process.
8. Make decisions by applying documented policies neutrally and objectively, with integrity and fairness.
9. Act with a speed that is responsive to the needs of the Internet while, as part of the decision-making process, obtaining informed input from those entities most affected.
10. Remain accountable to the Internet community through mechanisms that enhance ICANN's effectiveness.
11. Act with sensitivity to the public interest and related governmental concerns, so that the need for direct governmental action is minimized.
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.
Purpose
The Board of Directors of a public-benefit corporation (as ICANN is chartered in the State of California in the U.S.A.) has a fiduciary responsibility to act in the best interests of the corporation in furthering the public interest. It and it alone has the legal responsibility to make and be legally accountable for all policy and other decisions. Directors may be selected by various means, but once they serve on the Board, they are required to act and vote in the public interest, including the interests of all Internet users.
Because of the global nature of ICANN and because of the considerable interest in its decisions evidenced by so many individuals, organizations, businesses, and governments it is also critical that ICANN have and be seen to have a Board of Directors composed of individuals of the highest caliber, expertise, and integrity, acting cohesively as a group, able to act promptly and effectively as necessary.
Having carefully considered all the arguments for and against different ways of selecting Directors, therefore, the Committee on Evolution and Reform has concluded that the best way to achieve this goal is to select voting Directors through (a) employing the concept of a broadly-based Nominating Committee chosen to reflect public, private, institutional and individual interests, and (b) providing for the proposed policy development Supporting Organizations to appoint a certain number of Directors. Keeping in mind the overall goal of furthering the public interest, the Committee affirms that the number of Directors selected by the first approach should exceed those selected by the second approach.
Composition and Selection
The Board shall be composed of 15 voting Directors. Additionally there shall be 5 non-voting Liaisons as specified below who may participate in Board discussions and deliberations like Directors but shall not cast votes (and as such, do not count towards quorum counts of the Board)
The 15 voting Directors shall be selected as follows:
- 8 Directors selected by the Nominating Committee (NomCom)
- 2 Directors selected from each of the three Supporting Organizations
- The President of ICANN
The 5 non-voting Liaisons shall be selected as follows:
- 1 by the TAC
- 1 by the IAB/IETF4
- 1 by the RSSAC
- 1 by the SAC
- 1 by the GAC
Terms
Terms of office for all Directors (other than the President5) shall be three years, staggered so that approximately one third of the Directors shall be newly selected or reappointed each year. Subject to reappointment every three years, a given individual may serve no more than three successive three-year terms as a Director. The terms of Board Liaisons shall also be three years and similarly staggered.
Qualifications
Directors selected by the NomCom should be chosen to ensure that the Board is composed of members that in the aggregate bring to the Board (1) broad functional diversity in the areas of expertise relevant to ICANN's mission (2) global geographic and cultural diversity (3) the capacity to understand the global effects of ICANN's mission and supporting decisions, and (4) ability to contribute to the overall credibility of ICANN's Board. Personal characteristics should include integrity, objectivity, intelligence, demonstrated capacity for thoughtful group decision-making, and willingness to fulfill the responsibilities of a Board member.
Directors representative of the SOs should also be selected by the SOs utilizing, as applicable, the same criteria and personal characteristics. The same criteria and characteristics shall also apply to other positions – as described in this Blueprint – selected by the NomCom.
Introduction
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.
Purpose
The GNSO (Generic Names Supporting Organization) should be a supporting organization for the purpose of engaging in activities relevant to generic top level domains, specifically (1) developing policy recommendations to the ICANN Board; and (2) nurturing consensus across the GNSO's constituencies.
Composition and Selection
Constituencies: The GNSO would initially be composed of the following six (6) voting (see below) constituencies:
Provider constituencies:
- The gTLD registries constituency
- The gTLD registrars constituency
- The ISP constituency
User constituencies:
- The business constituency
- The intellectual property constituency
- The non-commercial domain name holders constituency
The Board should remain open to the creation of additional constituencies upon showing that (a) the policy development process would be improved by the addition of the particular proposed new constituency, and (b) the constituency would be structured and operated so as to be reflective of a meaningful, distinct, and interested segment of the ICANN community. These criteria should remain flexible to enable the Board to retain maximum flexibility in this regard.
Interested groups of individuals or organizations should be encouraged to self-organize as provisional constituencies as a preliminary step on the road to becoming a full voting constituency. The establishment of provisional constituencies should be according to some relatively minimal criteria that should be developed as part of the transition process. Examples of possible groups that could choose to self-organize are:
- Academic and public entities
- Individual domain name holders
- Consumer and civil society organizations
- Large business users
- Small business users
GNSO Council: The business of the GNSO should be coordinated by a GNSO Council (for affectionate historical reasons this could also be called a Generic Names Council) composed of (initially):
- Six (6) voting members elected by the provider voting constituencies (2 each);
- Six (6) voting members elected by the user voting constituencies (2 each);
- Three (3) voting members elected by the NomCom (according to similar criteria as used to selected members of the Board).
- One non-voting liaison appointed by the GAC.
The Chair shall be selected by the voting members of the GNSO Council.
Although the size of the Council may change from time to time as new provisional constituencies become voting constituencies or some constituencies cease to be active, the overall balance among the three main groups should be approximately maintained, as well as equality of representation between the provider and user constituencies. This may require reallocation of the number of votes among the various constituencies within each group.
Each member of the GNSO Council, including those selected by the NomCom, shall serve for renewable two-year terms, with these terms staggered so that no more than approximately half of the membership turns over each year.
GNSO General Assembly
The GNSO General Assembly shall be a cross-constituency meeting place of both voting and provisional (see above) constituencies. A member of the GNSO Council appointed by that Council should chair it.
The GNSO GA exists for the exchange of information and ideas, the discussion of particular issues, and as a resource for the creation – under the direction of the GNSO Council – of working groups, drafting committees, and task forces. The GNSO GA is not a forum for making decisions or recommendations, or taking formal positions.
As such, the GNSO GA should take no votes, although working groups under the direction of the GNSO Council can provide advice as a group. To encourage informed discussion free from personal attacks and undue disruption, the GNSO GA shall only support moderated electronic discussion lists and forums (in which all interested individuals and groups can participate). Those interested in participating in unmoderated lists can do so in other fora, not under the auspices of the GNSO GA.
The GNSO Council is responsible for the GNSO GA and for ensuring that these purposes and requirements and purposes are fulfilled.
Review
The Board shall initiate a review – to be conducted by an entity independent of the GNSO or the GNSO Council, although certainly a self-assessment by the GNSO could feed into the review – of the proposed GNSO and GNSO Council after 12 months of experience with the new structure to assess performance and to initiate any appropriate changes that might be suggested by this review.
Purpose
The CNSO (Country6 Names Supporting Organization) is a supporting organization for the purpose of engaging in activities relevant to country-code top-level domains, specifically (1) developing policy recommendations to the ICANN Board; and (2) nurturing consensus across the CNSO's constituencies, including the name-related activities of ccTLDs.
The ERC acknowledges the intense discussion and work of the ccTLD community, in its diversity of positions and opinions, concerned with what are the responsibilities of the ccTLD administrators that fall strictly under the purview of national or otherwise local jurisdiction, and those that lead to the need for global harmonization and coordination. The CNSO is conceived as the forum where this distinction will be further understood and developed, and from which the global aspects will continuously emerge.
The ERC has concluded, after extensive – and still ongoing – analysis and dialog with members of the ccTLD community, that the global aspect is of extreme importance, that it cannot be solved by the sole sum of national jurisdictions, and that the interplay between policies concerning the ccTLD domain names and other identifiers whose global policy coordination ICANN is charged with, requires an intense interaction within the ICANN sphere.
Composition and Selection
The CNSO is not intended to be just an elevated ccTLD constituency, but is rather a policy-development body. As such, its voting membership (such as in voting for CNSO Council members – see below) should include representatives of those ccTLD registries – and only those ccTLD registries – committed to global policy development through the ICANN process (evidenced through signed agreements or by other means, such as full funding support).
CNSO Council: The business of the CNSO should be coordinated by a CNSO Council composed of (a) regionally elected members selected by and from among the voting ccTLDs as defined above; (b) several additional voting members selected and appointed by the NomCom in accordance with the criteria used to select Directors, but with emphasis on particular individuals who have a demonstrated interest in global names policy, and (c) a non-voting GAC liaison. The regionally elected members should comprise about two-thirds of the voting members.
The exact structure of the CNSO should await further developments, but it cannot be (1) a separately incorporated entity, or (2) a trade association for ccTLD administrators. Any such function can and should take place outside of the ICANN structure.
ccTLD Agreements
In the original Lynn document "ICANN: A Case for Reform", one problem that was highlighted was the challenge associated with consummating stakeholder agreements. This problem has not been addressed thus far in detail in the work of the Committee on Evolution and Reform. Nowhere is this problem more complex than in the case of reaching agreements with ccTLDs, although some progress has been made and more can be anticipated. ICANN operates within the framework of ICP-1.
As a step towards addressing this issue and possibly considering whether policy changes may be required, the Committee on Evolution and Reform recommends that the Board encourage the GAC and delegates from the global ccTLD community to explore possible paths to resolution of this problem.
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.
GAC
The GAC should remain a committee with its membership determined by its own bylaws. It is an advisory body to the Board.
The GAC should receive adequate notice and an opportunity to comment on all ICANN policy decisions before they are taken. Other comments on government involvement are discussed later in this Blueprint.
The ERC encourages the Board to invite the GAC to explore ways in which multi-way communication can be enhanced beyond the recommendations contained in this Blueprint.
RSSAC
For now, the RSSAC should be composed as it is today with the addition of a GAC liaison. The RSSAC should also appoint a non-voting liaison to the Board. A review of the RSSAC by ICANN, however, should be conducted as soon as possible to provide recommendations on how to improve both its effectiveness, particularly with regard to security planning, and the current relationship between ICANN and the root server operators.
The ERC does recognize that while prominent community members have expressed concerns that some aspects of the operation of the DNS root server system could benefit from further formalization, the present root name server operators enjoy community-wide approval.
SAC
The SAC should be chartered and composed as it is today with the addition of a GAC liaison. The SAC should also appoint a non-voting liaison to the Board.
TAC
The TAC should be available to provide technical advice and guidance to the Board and to other organizations within ICANN. It should serve both as a resource that can be called upon to pursue specific questions and as an active watchdog ensuring that technical issues that might otherwise be overlooked are brought to the attention of decision makers. It also serves as a meeting point for different parts of the technical community to come together to discuss global technical policy issues within the scope of ICANN's mission.
The TAC is in part a replacement for the PSO but with a different purpose. Its precise membership should be determined as part of the transition process, but should at a minimum include, should they wish to participate, two delegates from each of the four organizations that currently comprise the PSO (the IETF, the ITU, ETSI, and the W3C), and three members with a strong technical background appointed by the NomCom.
Purpose
The purpose of the Nominating Committee is to select Directors and other individuals as otherwise described in the applicable sections of this document, and who conform to the criteria in those sections. The purpose of NomCom selections is to balance the representative selection of other Directors and positions to ensure that ICANN can continue to benefit from participants in the ICANN process (Directors or otherwise) of the highest integrity and capability who place the public interest ahead of any particular special interests., but who are nevertheless knowledgeable about the environment in which ICANN operates.
This implies a NomCom composed both of persons deeply involved with the various constituencies of ICANN and also of persons knowledgeable but less directly involved. One of the underlying principles of the NomCom is that its very functional and geographic diversity would tend towards selection of Directors and persons filling other positions who are broad in outlook, individually and as a group, and not beholden to particular interests.
Composition
The NomCom would initially be a 19-member body composed of delegates (not representatives) appointed by the following constituencies:
- gTLD registries (1)
- gTLD registrars (1)
- ccTLD registries (1)
- Address registries (1)
- Internet service providers (1)
- Large business users (1)
- Small business users (1)
- IP organizations (1)
- Academic and other public entities (1)
- Consumer and civil society group[s (1)
- Individual domain name holders (1)
- IAB/IETF (1)
- TAC (1)
- GAC (1)
- Unaffiliated public interest persons (4)
In addition there would be a Chair appointed by the Board and 2 non-voting liaisons, one from each of the RSSAC and the SAC. The above represents a workable balance among providers, users, technical and public interests.
Selection
As indicated, all but the Chair of the NomCom would be appointed by the applicable constituency. In the cases where there is today no clearly defined constituency, the Board would initially appoint the delegates following consultation with bodies that can credibly be seen to speak for the affected groups. This process would be more clearly defined as part of the transition process, but the objective would be to qualify particular constituencies to appoint each NomCom delegate.
Other methods can be considered for selection of delegates from the At Large constituency or constituencies when the nascent At Large process matures to the point where there are viable and definable organizations that could carry out this function.
The ICANN Bylaws will need to ensure that, to the extent feasible, there is overall geographic and cultural diversity and balance across the Nominating Committee.
Terms
The initial NomCom delegates would be appointed for terms sufficient to allow for the selection of the new Board (and other relevant bodies as indicated in this document) as proposed. Once "steady-state" is achieved, NomCom members should serve non-renewable two-year terms that are staggered to ensure that half of the NomCom "turns over" each year. A NomCom member could, if selected, serve another two-year term provided there is at least a two-year hiatus in between. Members of the NomCom should be ineligible to serve as Directors of ICANN for at least one-year following their term of service on the NomCom.
Policy Responsibility of the ICANN Board
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:
- It should be broadly applicable to multiple situations or organizations (that is, not apply to just a single one-off situation);
- It should be expected to have lasting value or applicability, albeit with occasional updates;
- It should establish a guide or framework for future decision-making.
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:
- A clear assignment to the appropriate policy development body. If more than one such body has an appropriate interest, one body shall be assigned the lead responsibility for coordinating with the others;
- A defined timescale for completing the policy development leading to a recommendation to the Board, normally in the range of 60 days or less;
- A predefined process and timescale for collecting and evaluating community and public input;
- A recommendation to the Board that reflect the inputs received and corresponding reasons for the presence or absence of true consensus; the pros and cons of any recommendation; and summaries of supporters and opponents;
- An opportunity for the Board to receive advice from other bodies including Expert Advisory Panels or bodies (see below) and the GAC;
- A requirement that where practicable the Board publish a tentative decision that allows for a period of public comment and review by the assigned policy development body prior to making a final decision.
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.
Bylaw Amendments and Alleged Infringements
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.
2. ICANN is defined under California law as a "public benefit corporation." This means that it is a private, non-governmental corporation that is not-for-profit for a public or charitable purpose.
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.
Questions concerning the layout, construction and functionality
of this site
should be sent to webmaster@icann.org.
Page Updated
24-Aug-2002
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.