ICANN | First Interim Implementation Report

First Interim Implementation Report
Posted: 1 August 2002

Committee on ICANN Evolution and Reform
First Interim Implementation Report
1 August 2002

On 28 June 2002, the ICANN Board adopted and endorsed the Blueprint for Reform that had been recommended by the Board’s Evolution and Reform Committee (ERC). It directed the ERC to "oversee further detailed implementation and transition work based on the Blueprint for Reform."

The ERC has subsequently released two Status Reports on Implementation, dated 15 July and 24 July 2002. As noted in those reports, it has engaged three separate assistance groups to help it formulate implementation recommendations, dealing with accountability issues, the names-policy-development process, and the creation of an At Large Advisory Committee. It has received and posted initial reports from the assistance groups on accountability issues and the names-policy-development process.

The implementation schedule is extremely compact. For the Board to take final action at its meeting in Shanghai on 27-31 October 2002, and for there to be sufficient time for community review of and input on its recommendations, the ERC must publish those recommendations on or about 1 October 2002. The approximately 60 days between now and then must be used effectively if we are to reach that goal.

In this First Interim Implementation Report, we will offer our current thinking on several specific aspects of the reform process. Obviously, this Report does not cover the full range of implementation topics; other issues will be dealt with in subsequent documents. We welcome community reaction on these issues, and we urge that you communicate to the ERC and the community as a whole any thoughts and suggestions as quickly as possible, so that they can be taken into account in arriving at final recommendations and decisions. All comments should be directed to reform-comments@icann.org (Forum closed 18 August 2003), and will be posted at the ICANN forum website. We anticipate that we will produce a Second Interim Implementation Report on or about 1 September 2002 that will take account of community comments on this Report, and the final input of the various assistance groups noted above, and final recommendations on or about 1 October 2002.

1. Mission and Core Values

The Statement on ICANN Reform issued by the Governmental Advisory Committee in Bucharest recommended a number of slight changes to the language on Mission and Core Values included in the Blueprint. We have reviewed those suggestions, and in the main are likely to recommend to the Board that they be adopted. A possible exception is Core Value Eleven, where we will likely propose a slight rewording of that language. We thank the GAC for its constructive suggestions.

We do want to raise one concern about the Mission Statement as included in the Blueprint, based on our further review and various comments received. The Blueprint includes, as subsection c. in the ICANN Mission Statement, the following language:

c. Coordinates policy-development as necessary to perform these functions.

The GAC suggested the addition of the qualifier "technical" be inserted before the word "functions," and we agree this is a useful suggestion. But we do want to raise for community discussion the use of the word "necessary" in this subsection and elsewhere. The rationale for the addition of this language was the desire, shared we believe by all, to put appropriate limitations on ICANN’s policymaking scope. Nevertheless, on reflection we are concerned that the use of the word "necessary" may be unwise. If this were simply guidance for ICANN’s Board, perhaps this language would serve as a useful restraint on inappropriately wide-ranging ICANN action. But we contemplate the incorporation, in some appropriate way, of this Mission Statement and Core Values in ICANN’s constitutional documents. Thus, we assume that this articulation may be referenced in various ways in both contractual and other criteria for review of certain ICANN decisions. It is not clear to us that “necessary” is sufficiently flexible to include, for example, such apparently desirable ICANN actions as the adoption of the Uniform Dispute Resolution Policy, or possible actions requiring conformance with particular standards for the use of internationalized domain names. While these may well be highly desirable, and consistent with ICANN's core mission goals, it is at least arguable that they are not "necessary to perform these technical functions."

We admit to great difficulty in finding a single phrase that is both sufficiently limiting and sufficiently flexible to permit those actions that ICANN should reasonably be expected to take in carrying out its core responsibilities, which is why we developed the Core Values. The Core Values are an attempt to create appropriate limitations without relying on a single phrase or collection of words – and indeed were created because we could not find a workable single phrase or collection of words.

Still, we recognize the general view, which we share, that ICANN should be limited to only those policy development activities that are appropriately connected to core technical coordination mission. We note that in various other places in the Core Values, the GAC suggested the addition of the word "appropriate," which we find both acceptable and an improvement over the previous language. Therefore, we offer for public comment the following alternative formulation to that contemplated by the Blueprint or suggested by the GAC:

c. Coordinates policy-development reasonably and appropriately related to its technical functions.

We are not at all certain that this formulation is optimal, and it may well be that the original notion – to set forth in the Core Values sufficiently clear guidance to properly constrain ICANN’s policy role, rather than to try to find some particular limiting word or phrase – is the preferable course. This same analysis would apply to the first change suggested by the GAC under the heading "Policy Implications."

We invite comment and reaction on these issues.

2. Accountability Issues

A principal focus for the ICANN reform process is the structuring of workable and appropriate mechanisms to permit adequate public input into the ICANN process, while ensuring that those mechanisms are consistent with an effective and workable ICANN. It is also important that appropriate ways be found to ensure that ICANN’s actions remain within the relatively narrow boundaries of its responsibility. While these are slightly different concerns, they both fit under the general rubric of "accountability," although it is also fair to say that most of ICANN's organizational and procedural mechanisms would generally fall under this heading as well. Certainly such aspects as the Nominating Committee process for selecting a majority of Board members, and the efforts to explore the creation of an At Large Advisory Committee, are aimed at exactly this same point.

There are two, somewhat competing, values at stake here. One is the important right of all affected and legitimately interested parties to have the opportunity to participate appropriately in the work of ICANN. The second is the need to ensure that ICANN's processes are workable – that is, that they in fact produce decisions on matters within the scope of ICANN's responsibility in a timely manner, and based on a proper understanding of the views of all interested parties. The former requires mechanisms for input, for dispute resolution, and for appropriate oversight; the latter requires procedures and rules that generate the necessary record within a reasonable timeframe and permits timely action by ICANN when action is required. There is inevitably some tension between these two objectives, but they can and should be balanced to serve both goals simultaneously.

This balance is what underlies the Blueprint's call for the creation of an Office of Ombudsman, a Manager of Public Participation (or whatever title is ultimately chosen), and appropriate reconsideration and independent-review policies. We recognize that there is a wide range of opinions on how these efforts should be balanced against the effort to create a structured policy-development process, and we have no illusions that our final recommendations will inevitably receive uniform applause. Nevertheless, we intend to attempt to find the best balance we can between these objectives, with the goal an open, transparent, inclusive and effective ICANN.

The ERC asked for assistance in the implementation of three specific aspects of the Blueprint for Reform: the Manager of Public Participation, the Ombudsman function, and the independent review process. The initial suggestions of that assistance group have been posted on the ICANN web site. We offer the following reactions to that posting:

1. In general, we agree with the assumptions set forth by the group. We might use a different set of words in some cases; for example, we may not see the responsibilities of the Manager of Public Participation as quite as broad as the assumptions seem to anticipate. Still, as general assumptions on which to base more particular specific recommendations, these seem fine to us. We do want to note that, while we have asked this group to help us map out the mechanics of implementing the skeleton set forth in the Blueprint, these and others are free, of course, to suggest additional steps they think would be useful. We will certainly consider any such suggestions, consistent with the Board's instructions in resolution 02-79 that "any further opportunities for strengthening ICANN's capacity to fulfill its mission that develop or are identified during the implementation process should be carefully reviewed and utilized as appropriate." Any such suggestions should, as this language indicates, advance the goals set forth in the Blueprint and be consistent with the structure set out in the Blueprint.

2. Along these lines, it may be useful to set forth our current thinking on some of these issues. In our view, the Ombudsman should be a person to whom those who believe they have been treated unfairly in the context of ICANN processes can turn to for an independent evaluation and, potentially, facilitation of a resolution if the complaint is determined to be well founded. We believe the Ombudsman should be an advocate for fairness in the ICANN process. But we also believe that the Ombudsman, to be effective in this role, cannot have a roving mandate with no limits. The Ombudsman as we contemplate this office is someone who can evaluate complaints objectively, because he or she had nothing to do with the decision or action being complained about. This means that the Ombudsman should be able to (1) determine the facts relating to a complaint, (2) reach a conclusion about whether the complaint is well-founded, (3) if so, seek to facilitate a mutually satisfactory resolution, and (4) report to the Board and the community on his work.

Obviously, if in the course of this work the Ombudsman concludes that a change in procedure or other actions would reduce the chance for repeated concerns, he or she should be able to make that view known to the Board and the community. But we do not believe that the Ombudsman should be an alternative mechanism for policy development, or that the Ombudsman should have the freedom to offer his or her opinions on policy or other issues outside the process set forth above. The appropriate policy development bodies should deal with policy development and policy issues, and operational issues are the responsibility of the staff. The Ombudsman should be required to comply with relevant ICANN policies on conflicts, confidentiality, or similar policies. In sum, the Ombudsman as we envision it is an input mechanism for complaints, an independent voice in evaluating and resolving those complaints, and a potential source of suggestions on how to improve ICANN procedures and processes to reduce complaints.

3. The Manager of Public Participation (or whatever title is eventually chosen) will be an ICANN staff person whose entire focus is to facilitate the receipt and use of public input on ICANN decisions. Those who work within the ICANN process on a regular basis, including those active in the Supporting Organizations and Advisory Committees, have clear mechanisms for making their views known. While ICANN has always been open to input from the general public, the mechanisms for receiving that input and ensuring that it is available to those making decisions have not always been effective. While part of this problem has been limited resources, another part of the problem has been the lack of any ICANN staff charged specifically with this responsibility. The Manager of Public Participation will have this as his or her principal responsibility.

We envision that this person will be responsible for ICANN’s website, for any e-mail or other forums managed by ICANN, and in addition will likely be responsible for providing or overseeing the staff support for any specific mechanisms (such as the At Large Advisory Committee currently under consideration) designed to facilitate general public involvement in ICANN.

4. The ICANN Reconsideration Process has, in our view, been used mainly as a tool by those unhappy with Board decisions to seek re-argument on those issues. That was not its intended purpose; it is intended primarily to fix errors. We believe that the "new" ICANN Reconsideration Process should be limited to (1) situations in which the ICANN staff is alleged to have acted erroneously (without authority, inconsistent with existing policy and the like), and (2) situations in which the Board is alleged to have made an error because of incorrect or inadequate information, or otherwise. Issues relating to, for example, whether a Board action is consistent with the ICANN Bylaws should be heard through the independent review process. Thus, we continue to see a limited role for the Reconsideration Process.

5. The Blueprint lays out a narrow role for independent review – "any allegation that the Board has acted in conflict with ICANN’s bylaws.” We assume that ICANN’s bylaws will incorporate, in one way or another, the ICANN Mission Statement and Core Values discussed earlier. These provide, in our view, a workable and appropriate set of constraining principles, against which a particular ICANN action can properly be tested.

We do not believe that ICANN should have either a Supreme Court or a "Super Board" with the ability to nullify decisions reached by the ICANN Board, which will be the most broadly representative body within the ICANN structure. Nor do we believe that it is consistent with ICANN’s limited mission and financial structure to assume and facilitate a judicial review-like process under which all or most ICANN decisions could be subjected to costly, time-consuming delays. We do recognize that many of ICANN’s existing agreements contemplate an independent review process in order to require compliance by parties to those agreements in certain areas of ICANN policymaking, but we believe that the independent-review process called for by the Blueprint is either consistent with those agreements or that those agreements can and should be conformed to this standard.

Thus, while we understand that some members of the community feel that there should be a broader scope of review or appeal mechanisms, we remain quite skeptical about the desirability or feasibility of any such approach, and thus how it could possibly be consistent with either the Blueprint or the Board resolutions relating to the Blueprint. We do not see how such an approach is compatible with the objective of creating a workable ICANN, for all the reasons noted above and in earlier discussions of this subject.

We invite comments and reactions on these issues, and we look forward to further contributions of the assistance group in this area..

3. Names-Policy-Development Process

The Blueprint provides general guidance as to certain critical elements of an effective names-policy-development process, but there are various implementing details that need to be developed. The names area is perhaps the most complex of the policy areas within ICANN, since it does not benefit from pre-existing organizations with a history of work in the area, such as the RIRs in the addressing area. In addition, it brings together providers and users, wholesalers and retailers, suppliers and customers – in other words, a variety of disparate interests.

We start from the proposition that one of the principal reasons for ICANN's existence is to seek consensus wherever possible on the issues within its mission. As is obvious from the experience of the last 3+ years, developing global consensus on almost any subject is a very difficult job indeed, given the diversity of interests and perspectives likely to want to participate in that process. As a result, names-policy development in ICANN has to date not been uniformly effective. There are no doubt a number of reasons for this, including importantly the lack of staff support for the volunteers who carry out this activity. But it is the strong view of the ERC, and we believe of the community as a whole, that another significant reason for the lack of effectiveness in this area is the absence of a structured policy-development process – with clear procedures, deadlines and expectations of final action in a timely manner.

The Blueprint for Reform treats with each of these issues – the first by concluding that there must be an appropriate level of staff support for the GNSO (and the other ICANN constituent bodies),¹ and the second by calling for the creation of a structured policy-development process that includes a predefined timetable, a predefined set of procedural steps, a requirement that any recommendation to the Board reflect all the inputs received, and a description of all responsible points of view, and the opportunity to seek input when appropriate from other expert panels and bodies, inside and outside ICANN. To expand on some of these general principles:

1. All interested persons should have the opportunity, but not the right, to influence ICANN's policy decisions. By this we mean that there should be effective mechanisms for input from all, both those directly affected by any particular decision, and others who might be less directly affected but nevertheless have a legitimate interest in the decision. These input mechanisms may be tailored to the particular source, or to the issue under discussion, but they must have the common characteristic of ensuring that all who want to do so have the opportunity to make their views known. Those views, once presented, may or may not be persuasive to others, but if the opportunity to present views is fair and open, the actual influence of the ideas advanced will depend on their merit.

2. In every case in which a policy issue is being discussed, it is the obligation of all participating to seek consensus if possible. The ICANN structure generally, and the names-policy-development process we will ultimately recommend for Board action, should be designed to promote the maximum opportunity for consensus policy development. This can only be effective if the vast majority of all those participating make a good faith effort to find a consensus position. Irrational or purely selfish arguments or strategies are not likely to promote this objective. Thus, in our view, those responsible for the policy-development process should make every effort to find a consensus solution, but if that is impossible because of the unreasonable or irrational refusal by one or more parties to seek consensus, that conclusion should be documented and given appropriate consideration in the final decision-making process.

3. The policy-development process must include clear timelines and procedures, so that the process is both understandable and predictable to all, both inside and outside ICANN. On timing, our final recommendations will include hard deadlines for (1) the initiation of a policy-development process once an issue has been properly presented for consideration; (2) the gathering of both information and the views of those who wish to have those views considered; (3) the period of discussion and potential consensus development by the GNSO Council, which is responsible for the recommendation to the Board in this area; (4) the date by which such recommendation must be made; and (5) the date by which the Board must take final action. While there should always be the opportunity for adjustments where the circumstances require, we will recommend that the burden of justifying any such extensions should be compelling. This standard will ensure that in the vast majority of situations the policy-development process will be predictable, understandable, and timely. While we understand that we cannot sacrifice the quality of the decision for speed, we also believe that a relatively short timeframe (our current thinking is 60-90 days from start to decision), and the proper staff support, can and will produce quality decisions in a timely manner.

On procedure, we believe that there must be very clear rules on how an issue is presented for possible inclusion in the policy-development process; exactly what steps are then taken to ensure that all interested persons' views are gathered and considered; the process that will be followed for seeking expert advice where appropriate, both from within ICANN and in appropriate instances outside ICANN; exactly how the GNSO Council intends to use this information once gathered to determine whether a consensus position can be developed; and what the exact procedure is once the GNSO Council has forwarded its recommendation to the ICANN Board.

4. We want to be clear that, while the ICANN Board has overall responsibility for overseeing the policy-development process and ultimately for the decisions it takes, it is our view that the GNSO Council is responsible for the management of the policy-development process from the point where it is initiated with respect to a particular issue to the point where it makes a recommendation to the ICANN Board. The GNSO Council should have the flexibility to adjust its approach in particular instances to fit the particular circumstances, but these adjustments should not materially alter the ordinary-course time deadlines or input procedures, absent compelling reasons to do so. In other words, again absent compelling reasons to the contrary, the policy-development process should fit within a set schedule that will be included in our final recommendations, and adjustments to process and approach should not in most cases require or permit adjustments to that set schedule. This no doubt will require the GNSO Council to be both aggressive and decisive in particular circumstances, but any other approach would put our goal of timely and effective policy development efforts at serious risk.

The ERC asked for the assistance of several persons from the community in helping it craft specific implementation recommendations in this area; that group's first contribution to the ERC is posted on the ICANN web site. We find it helpful, and generally consistent with our present thinking, and we thank the persons involved for their continuing willingness to help the ERC in this area. We offer the following observations on the concepts included in that preliminary document:

1. We generally agree with the assumptions laid out in "I. High Level Topics." We would note that the details of GAC involvement in the policy-development process, and with other aspects of ICANN, require coordination with the GAC, and thus probably do not require additional detailed attention by this group.

2. With respect to "II. Basic Framework," we agree that it should be possible for any interested person to suggest that a particular issue should be subjected to the policy-development process. Since the initiation of a policy-development process will require serious resource and time allocation by many people, it is our current thinking that only the Board or the GNSO Council should be permitted to actually initiate a names-policy-development process. We solicit views on this general subject, and on whether the decision by either the Board or the GNSO Council should require a simple majority, or either more or less than a majority. For example, if as many as, say, 40% of one or both bodies believe that an issue is ripe for the policy-development process, should that be sufficient, or going to the other extreme, should initiating a policy-development process require a super-majority of one or both bodies, say 60%? In the reformed ICANN, policy development will be a labor-intensive process and short deadline process, requiring extensive time and effort from many volunteers and significant ICANN staff time. It should not be undertaken lightly. On the other hand, this is one of the principal tasks of ICANN – to develop consensus policies where necessary or appropriate – and there should certainly not be improperly high barriers to such efforts. We invite comments on this general subject.

3. As noted earlier, we do not believe that the general structure and timelines should be ad hoc, set individually for each process, but rather should be established by the Board and subject to change only for compelling reasons. In other words, we believe that the presumption ought to be that the policy-development process will last whatever time period is set from initiation to decision, and that any exceptions should have to be justified under a compelling reasons standard. Thus, we believe that the standard timelines established by the Board should be long enough to accommodate typical techniques that might be used (including such things as task forces), but short enough so that the decision on that particular policy issue is made in a timely manner. As noted, our current thinking is that this time period – from initiation to decision – should not exceed 60-90 days.

4. We strongly agree that the results of the policy-development process must be collected and presented to those making recommendations and decisions in such a way that it is clear what possible positions are favored or opposed by which persons or entities, what the pro and con arguments relating to those various positions are, and what are the recommendations and the rationale for those recommendations of those presenting this information, whether it be by a task force or other body to the GNSO Council, or by the Council to the Board. Only if a proper record is developed and presented can an intelligent judgment be made about the existence of a consensus or the reasons why such a consensus does not exist. And only after that is determined can the ICANN Board make a reasoned decision on the particular issue before it.

4. The Nominating Committee Process

In implementing the Blueprint, an essential element is the elaboration of the composition, functions, objectives, and procedures of the Nominating Committee (NomCom). The Blueprint calls for the NomCom to select 8 members of the Board, 3 members of the GNSO Council, several members of the CNSO, 3 members of the TAC

We are currently working on three areas: selection of NomCom members; criteria for nominations; and timeline and process for nominations.

a. Selection of NomCom Members.

Who chooses the members of the NomCom, and how? The Blueprint provides a categorical breakdown for its membership. Some of those categories correspond to existing bodies that can be asked to devise their own selection mechanisms:

Chair (1, non-voting, appointed by Board)
gTLD registries (1)
gTLD registrars (1)
ccTLD registries (1)
Address registries (1)
Internet service providers (1)
IP organizations
IAB/IETF (1)
TAC (1)
GAC (1)
SAC (1, non-voting)
RSSAC (1, non-voting)

The remaining categories do not, however, correspond to single existing entities within the ICANN structure:

Large business users (1)
Small business users (1)
Academic and other public entities (1)
Consumer and civil society groups (1)
Individual domain name holders (1)
Unaffiliated public interest persons (4)

A central focus of the ERC's work over the coming month will be to give better definition to these categories, and to specify mechanisms by which those clusters of Internet stakeholders can select delegates. Two of these categories embrace business users of the Internet (large and small); two embrace non-commercial users (academic institutions and consumer/civil society groups); and one embraces individual domain name holders. The strong preference of the ERC is to look to existing institutions, associations, or bodies to make these selections, rather than attempting to fashion new entities within the ICANN umbrella. In the Blueprint, we noted the idea that "[i]n 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." While this mechanism might be necessary to achieve a workable NomCom in the short-term, we hope to push strongly to determine if appropriate, qualified bodies can be immediately identified and delegated the responsibility to select a NomCom delegate.

The ERC actively solicits input – particularly from the business and non-commercial DNSO constituencies, and from business, non-commercial, and individual users and associations – on the best way to achieve legitimate NomCom selections from these stakeholder communities.

In addition, the Blueprint calls for the inclusion in the NomCom of four "unaffiliated public interest persons." One possible source of some or all of those delegates would be an At Large Advisory Committee, should such a body eventually be created. We solicit comments on other possible sources of these delegates.

A key issue for the composition of the NomCom is geographic and cultural diversity. On their face, the defined categories of NomCom membership should assure balance and diversity of functional interests from across the Internet, including both user-side and provider-side stakeholders. But the categories embody a notion of decentralized, distributed selection procedures, which cannot alone guarantee geographic diversity. (Of course, we believe that the NomCom should be required to generate geographically diverse nominations, but the principle of geographic diversity must be vindicated where feasible at all levels of the ICANN process, including the composition of the NomCom itself). We can think of at least two options for addressing this need:

(a) Using the "unaffiliated public interest persons" as guarantors of geographic diversity, by specifying that each must come from a different region.

(b) Dormant seats, which would be created only if, when all the other NomCom seats have been filled, there is no NomCom member from a particular region. In other words, if the NomCom turned out to have no Latin American delegate, a Latin American seat would be created. That seat could be filled by any number of mechanisms: the Chair (upon advice from stakeholders in the region); the other NomCom members; the Board; the GAC members from that region; or perhaps some combination of the above.

There may well be other, more workable possibilities. We invite suggestions and comments on how best to assure reasonable geographic diversity on the NomCom itself.

b. Criteria for Nominations.

Given that the NomCom will introduce a new, significant mechanism into the ICANN environment, there will doubtless be considerable anxiety over its functioning and outputs. We think that an essential predicate to confidence in the NomCom is detailed elaboration of the criteria that the NomCom will be required to apply when making its nominations. Moreover, institutional design principles suggest that bodies that start with commonly agreed, well-defined standards and criteria for activities are more likely to promote good outcomes regardless of the personalities or qualities of the particular members

The following is the Blueprint language related to the criteria to be used for selections:

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.

We invite suggestions for how these general criteria can be modified or augmented to ensure that the NomCom has very clear directions for carrying out its important task.

c. Timeline and Process for Nominations.

Finally, the ERC is working to produce a timeline and basic set of procedures to guide the NomCom's work. Key questions include: How much time will the NomCom need to complete its nominations? With whom should the NomCom be required to consult? How should it take input and recommendations? Should all communications be treated as private? We have been examining the procedures of other nominating committees (such as the IETF, academic associations, and some intergovernmental bodies), but find that the proposed ICANN model is fairly unique in its conception and role. Accordingly, input, suggestions, and commentary on these issues is actively invited, particularly from individuals with experience serving on nominating committees in other contexts.

Committee on ICANN Evolution and Reform
1 August 2002

Note:

1. We assume in the discussion that follows that the GNSO will have the staff support necessary to carry out the tasks assigned to it.

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