Recommendations for the Evolution and Reform of ICANN
Posted: 31 May 2002
Committee on ICANN Evolution and Reform
Recommendations for the Evolution and Reform of ICANN
IV. Nominating Committee Composition and Responsibility
V. Policy Development Structure
VI. Policy-Development Process
VII. Public Oversight and Participation Mechanisms
IX. Government Participation in ICANN
X. Utilization of Outside Resources
| Click here to read comments on these recommendations. |
Since 24 February 2002, when Stuart Lynn published his President's Report on ICANN Reform, there has been a very productive debate within the ICANN community on the issues raised in his report. ICANN is the embodiment of a complex idea, seeking to balance in a non-governmental entity widely diverse interests in a way that protects core values while maintaining the stability and interoperability of a critical global resource. The first period of over three years of its existence has seen some real accomplishments, accompanied by some wasted motion, false starts, and growing pains. Its accomplishments as a forum for global discussion and decisions on a limited set of concerns central to the operation of a global resource are real. But we also agree with Dr. Lynn that, in order for ICANN to be successful in the future, when it will face even more difficult challenges, it must evolve into a more effective entity.
Our charge was to receive input from the community on Dr. Lynn's Report, and to consider the suggestions contained in that Report along with the community reaction and any alternative suggestions that were advanced. We have diligently reviewed the extensive materials submitted to the Committee, and in addition have individually had many conversations with other members of the ICANN community. Board members and many others have brought to the Committee the views of many critical actors involved with the Internet.
We have now had the benefit of a two-day retreat with the other members of the Board at which we had the opportunity to further discuss and consider these issues, and assess the individual views of ICANN's Directors on many of them. In order for the entire community to have sufficient time to review and consider our recommendations prior to the Bucharest meeting in late June, we are posting this description of our current views as to how ICANN reform should be implemented. It includes specific issues on which we invite further community input as much prior to the Bucharest meeting as possible. We should emphasize that these recommendations are those of the Committee, not the Board. While our views have been informed by discussions with other Board members as well as many others, these recommendations are attributable only to the members of this Committee.
We expect that between now and the Bucharest meeting, and at that meeting, there will be considerable discussion of the merits of these recommendations. We will be prepared in Bucharest to react to the intervening debate, and we encourage all interested parties to make their views known on the specific details of the following recommendations as far in advance of the Bucharest meeting as is practicable. Substantive submissions may be sent by e-mail to reform-comments@icann.org (Forum closed 18 August 2003); they will be reviewed, sorted by subject, indexed, and posted on the ICANN forum web site. In this way, the discussion in Bucharest can be as informed as possible, and the Board will be as well prepared as possible to make some final decisions on the general outline of a reformed ICANN.
It is our strong recommendation that the Board should act in Bucharest to adopt a reform plan that will establish the broad outlines of an evolved ICANN and allow the community to focus on the details of implementation.
There has been much debate about "thick" and "thin" ICANNs. It appears that everyone wants a "thin" ICANN, so long as it includes the specific functions that they are interested in. We do not find this lexicon very useful. Of course, ICANN should engage in no activities that are not appropriate to its mission, but the only way to bring this discussion to a head is to focus on specifics, not slogans.
The Committee Working Paper on ICANN Mission and Core Values, in our view, properly and usefully describes both the specific objectives of ICANN and the values that it applies in carrying out those objectives. We have noted some minor editorial suggestions that have been made, but we have seen no serious opposition to this articulation. Further, we have received strong support for this Working Paper even from people who have strong opposition to other aspects of the reform documents.
It should be mentioned that, while not without some discussions about the particulars, there exists specific support for the sections of that Working Paper that explore the implications of its discussion of mission and core values. It is clear to us that, although significant parts of the community around ICANN have particular interest in ICANN's attention to its core operational functions, these and other groups and individuals appreciate the wider policy implications of decisions that must be made in the conduct of these core functions.
Therefore, we recommend the adoption of the contents of the Working Paper on ICANN Mission and Core Values by the ICANN Board at the Bucharest meeting.
The ICANN Board, in our view, must be responsible for managing the ICANN policy-development process. The amount of deference that the Board gives to the policy recommendations of its policy-development bodies should depend on the extent to which those recommendations establish that those bodies have engaged in an effective consensus-development process which has rationally considered all significant options and their implications in a thorough manner, and which further explain clearly the agreements arrived at and the degree and importance of dissent to the consensus proposal. This means that the Board must be composed of very high-quality members, who have the capacity, the temperament, and the necessary understanding of their responsibilities to effectively make these decisions. All Board members do not have to be technically proficient, but the Board as a body must have the technical capacity to understand and appreciate the technical implications of its actions.
In addition, if the Board is to manage the policy-development process effectively, it should have direct input from the various components of that process. The Board should be as small as possible, in order to function effectively, but large enough to fully incorporate and balance all relevant views. Finally, the Board must be, and must be seen to be, broadly representative of the whole range of public interests that are affected by its actions.
These general principles lead us to the following conclusions on Board composition:
- The following should be ex officio Board seats, meaning the
person who currently holds that position occupies an ICANN Board seat:
a. The CEO of ICANN
b. The Chair (or delegate) of the GNSO Steering Committee
c. The Chair (or delegate) of the ASO Council
d. The Chair (or delegate) of the CNSO Steering Committee
e. The Chair (or delegate) of the GAC
f. The Chair (or delegate) of the RSSAC
g. The Chair (or delegate) of the SAC
h. The Chair (or delegate) of the TAC if established, or if not, the Chair (or delegate) of the IAB.
- There should be [five to eleven] additional members of the Board, selected by a Nominating Committee pursuant to a process and criteria as discussed below. The terms of all non-ex officio seats should be three years staggered, so that roughly a third of these seats are filled every year. The Committee believes that it is impractical to reduce the size of the Board sufficiently to create a much more efficiently-sized Board, and thus does not believe that there is much practical difference between thirteen and nineteenmembers.
A Board selection process can only be developed once there is a clear understanding of the type of Board members that are desired. We agree with Dr. Lynn that, to date, the current Board selection process has produced good directors, but we also agree that this is not guaranteed in the future. In particular, we agree that, while there is value in a limited number of ex officio seats, as a general proposition it is undesirable that ICANN Board members be selected solely by special-interest constituencies. Thus, we strongly endorse the notion that a significant number of Board members should be selected by a properly constituted Nominating Committee, and that those members should be, actually and in the perception of the community, people who can properly reflect many significant perspectives responsive to the broad public interest in the activities of ICANN, without losing focus on ICANN's actual, limited scope of responsibilities.
The Committee feels that the ICANN Board must, in the aggregate, include persons who provide broad functional diversity in the areas of expertise relevant to ICANN's mission; geographic and cultural diversity; the capacity to understand the global impact of ICANN's actions; and the ability to contribute to the overall credibility of the ICANN Board. In addition, other relevant criteria should include integrity, objectivity, intelligence, evident capacity for thoughtful group decision-making, and evident willingness to fulfill the responsibilities that are accepted by a Board member.
IV. Nominating Committee Composition and Responsibility
Since this body, in our conception, will be responsible for selecting a significant portion of the Board, it should be a body that is broadly representative of the entire ICANN community. This is a challenge, of course: to create a broadly representative and diverse body that is small enough to function, likely to be able to locate the kind of people ICANN needs each time the selection is made, and able to persuade them to be willing to serve on the Board. The NomCom should particularly include people that know and have access to many other people who could potentially be productive Board members, since a major part of this job will be to persuade people who may not have otherwise considered the possibility of serving on the ICANN Board.
In our view, the NomCom must include both delegates (we use that word to reflect our view that, while they may come from a particular community, they have a broader responsibility and should not be subject solely to instructions from that community) from the various policy-development bodies and advisory committees of ICANN (including the GAC) and from other groups with interests in the information society and the Internet. It should draw from the technical community (especially those who have broad knowledge about the strengths and weaknesses of various members of the technical community), as well as from the various social communities interested in ICANN's work. It might include former Board members and others with direct knowledge of what skills are necessary to be an effective ICANN Board member. In our view, it should be chaired by a sitting Board member who is not up for reappointment; this Chair should be non-voting but responsible for managing the process to a successful conclusion in a timely manner.
There is a broad range of sizes proposed for the NomCom, as well as for the duration of terms for its members.
The NomCom would be open to recommendations from any and all sources, and would be expected to consult with all the various ICANN communities in arriving at an appropriate slate of new Board members. There have been some suggestions that either the final slate as a whole, or the individuals that make up that slate, should be ratified by the Board to ensure that the candidates selected in fact meet the needs of the Board at that time. We have not adopted this suggestion at this time, but it is worth further consideration.
In addition to the selection of Board members, the NomCom should be responsible
for the selection of those members of SO Steering Committees that are
not directly selected by the SO members or constituencies.
V. Policy Development Structure
The current ICANN structure consists of a Board, various intermediate policy-development bodies (the present Supporting Organizations – ASO, PSO, DNSO), advisory committees (GAC, RSSAC, SAC), and special-interest constituencies (non-commercial users, commercial users, gTLD registries, etc.). In the current structure, the SOs are charged with policy development, and the Board's role is generally assumed to be to ensure that the process has been effective in discovering consensus and dissent, and properly balancing the two. Not unusually, though, the Board has been forced to extend this process due to incompleteness, lack of information or balance, or other shortcomings or insufficiencies of the policy proposals before it, or in order to meet deadlines has been forced to exercise its judgment as to the appropriate decision. An improved structure and process should allow both for better policy development in the intermediate structures and for legitimate Board action beyond the results of the work of those structures.
Some have argued that a different structure, where there were no standing policy development bodies or advisory committees (with the possible exception of the GAC), would be more effective. In this conception, the Board would create issue-specific working groups or task forces as necessary to consider particular problems. In this structure, there would remain special-interest constituencies, but they would interact directly with the Board and any particular temporary bodies the Board created to deal with particular issues. In this structure, the Board would be the body responsible for directly managing the policy-development process.
Our view is that, in the current environment, a mixture of the two options is likely to produce a more effective ICANN. We believe that standing policy-development bodies, combined with proper staff support, a structured policy-development process, and time limits for action, are more likely to encourage consensus where possible than single-purpose working groups or task forces. [See the discussion of the Policy-Development Process below.] On the other hand, we agree that, in order to ensure that ICANN is an effective organization, the ICANN Board must be ultimately responsible for managing the policy-development process.
Therefore, we recommend that the broad outlines of the current ICANN structure remain, with the following changes:
- GNSO. The name of the Domain Name Supporting Organization
should be changed to the Generic Name Supporting Organization. This
organization should be concerned only with issues related to generic
domain names – i.e. not those related to ccTLDs, which would
be subject to a separate treatment. The GNSO should be the ICANN unit
charged with advising the Board on policy issues relating to gTLD names.
a. The GNSO should be composed of a fixed number of constituencies that appropriately represent the relevant groups with interests in this area. The number and identity of such constituencies should be subject to adjustment over time upon a showing that such adjustments are appropriate to ensure that all relevant interests are in fact able to participate in the GNSO processes.
b. The existing DNSO constituencies, not including the ccTLD Constituency, should form the basis of the GNSO constituencies. Additional constituencies, and possibly some reorganization of the present ones, may be necessary to guarantee there is a place for all interested voices to be heard in a balanced way.
c. Besides the constituencies that are established as permanent constituencies, some more fluid organizations, in the way that "forums" are proposed in Dr. Lynn's paper, should be able to express their views and be heard. As they become stable, and representative of defined and ample sectors or views, they could possibly aim to be established as permanent constituencies. New constituencies would be approved by the Board, subject to specific processes and criteria adopted after public comment.
d. The GNSO should be chaired by a neutral, non-voting Chair appointed by the ICANN Board after consultation with the GNSO Steering Committee described below.
e. The GNSO should have a Steering Committee composed of (1) one voting representative and one non-voting alternate representative of each of the GNSO constituencies, and (2) an appropriate number of other members selected by the ICANN Nominating Committee [see the discussion of the Nominating Committee Composition and Responsibility above].
f. The General Assembly of the DNSO was originally intended to be the discussion forum for all participants in the DNSO, with the Names Council merely the administrative unit. Over time, for a variety of reasons, the GA has essentially become a separate body from the rest of the DNSO, and has not served its intended function as the virtual collection of all DNSO participants and a meaningful cross-constituency forum. The GA should be returned to its original function as the virtual meeting place of all GNSO participants. In order to accomplish this, and to insure that it is properly integrated into the GNSO, the neutral Chair of the GNSO should serve as the Chair of both the GA and the Steering Committee.Given our view that the Board, and not the GNSO, must ultimately be responsible for managing the policy-development process, it follows that the exact number of constituencies should be less important than it is today. In addition, since the GNSO should not, in our view, have the responsibility for directly selecting Board members [see the discussions of the Board Composition and the Board Selection Process above], this further reduces the significance of the particular number of constituencies.
The Board should initiate a review of the GNSO approximately one year from the implementation of these changes to determine what, if any, additional steps are required at that time to improve GNSO performance.
- ASO. The Address Supporting Organization, which appears to
be functioning well, should remain unchanged, with the exception, as
discussed above, of the elimination of its current
role in directly selecting members of the ICANN Board. The ASO Chair
(or delegate) would hold an ex officio seat on the Board.
- PSO. The Protocol Supporting Organization should be dissolved.
The input it should provide on protocol parameters and related matters
is to be obtained through new channels described elsewhere in these
recommendations, and its current role in selecting Board members is
no longer necessary, for the reasons discussed above.
- CNSO. A Country-code Names Supporting Organization should be
established, composed of those ccTLD representatives committed to appropriate
global policy development in this area. The exact structure and operation
of the CNSO should await developments, but we believe (1) it should
include not only ccTLD administrators but others with legitimate interests
in the global policy issues relating to ccTLDs, and (2) if it is to
be a policy body within ICANN, it cannot simultaneously be a trade association
for ccTLD administrators. Therefore, we would not support a separately
incorporated entity serving as this body, nor would we support a body
made up solely of ccTLD administrators. The goal of this entity should
be to provide a place for representatives of the various ccTLD registries
and other relevant persons to play appropriate roles in developing ICANN
policies relating to ccTLDs.
With respect to issues that may relate directly to other parts of the ICANN community (for example in the introduction of Internationalized Domain Names), the CNSO would be expected to interact with the other relevant parts of the ICANN community. The Board in making decisions in such areas would take into account the views of the CNSO, as well as those of other ICANN entities.
A large fraction of the Board and a number of ccTLD administrators consider that there is a global side to policies in the ccTLD field, mostly oriented towards the responsibilities of ccTLDs towards the global Internet community. As a consequence, there ensues the view that the CNSO is required to include as many ccTLD administrators as possible, and must be based on the understanding that, to the extent that policies relating to global issues are developed through the ICANN process, the CNSO members agree to abide by them. This view is put forward asking for further, explicit, reasoned input about it and its consequences, including the way this CNSO must be organized and how issues pertaining to the local Internet communities of geographically defined entities should be handled.
- Advisory Committees. The Government
Advisory Committee, the Root Server
System Advisory Committee, and the Security
Advisory Committee should be permanent standing Advisory Committees
of ICANN. The membership and charter of the latter two Committees should
be reviewed and modified as appropriate once the basic ICANN structure
going forward is set.
- Technical Advisory Committee. Dr. Lynn's Report and our Working Papers assume that the PSO would be replaced by a Technical Advisory Committee. This could provide a useful forum to discuss and provide the Board with advice on various technical issues, according to the rationale of the paper. In this way, it would be comparable to the Security Advisory Committee. In addition, the TAC could be the body responsible for directly overseeing the technical operational activities of ICANN (largely but not exclusively the work of the IANA). [See the discussion of Internal ICANN Structure below.] On the other hand, such advice could, presumably, be sought on an ad hoc basis from the relevant technical bodies. The public nature of ICANN's work is bound to attract advice, even unsolicited, when needed, and therefore it could be argued that there is a minimal risk that ICANN may be in the situation where it tried something without sufficient technical knowledge and advice. Before making a final recommendation on this point, we would like to hear the views of the community, especially the individuals and entities that would logically be expected to be part of any TAC.
VI. Policy-Development Process
A critical part of an effective ICANN is an efficient policy-development process. As set forth in the Committee's Working Paper on the Policy-Development Process, we believe that, especially in the names area, there must be clear procedures established by the Board for asking for input when needed, receiving input, evaluating that input, and reporting the results of those efforts to the Board, along with any consensus recommendations that have been produced.
The exact parameters of that process are better left to the implementation phase of the reform effort, but they must be such as to (1) ensure that all voices are heard and recorded, (2) ensure that all particularly affected parties have had the opportunity to make their views known, (3) create the maximum opportunity for the location of consensus positions where they can be found, and (4) do so in a timely manner so that final decisions can be made and implemented as quickly as possible.
While we do not set forth specific recommendations, we do believe that this is a critical part of the ICANN reform process. A clear structure, with clear time lines and clear responsibilities for different stages of the process, will significantly improve the efficiency of the policy-development process. We envision the Board adopting, after full discussion within ICANN, an explicit set of rules for the policy-development process.
In addition, a critical part of any effective policy-development process is the staff support necessary to make it work. ICANN should provide sufficient staff support to any and all policy-development bodies or Advisory Committees that request such support. Because it is our view that the ICANN Board is responsible for the policy-development process, all such staff support should be ICANN employees. ICANN's funding must be adequate for this purpose.
VII. Public Oversight and Participation Mechanisms
An ICANN structured according to the above recommendations would be a broadly representative body, with all voices heard and able to seek to persuade the community as a whole of the merits of their vision. A reformed ICANN, with an appropriate mission, core values and commensurate bylaws, should be an effective body in devising community consensus where possible, and in making decisions based on the broad public interest where necessary. It would have multiple internal sources of checks and balances, and an inherent transparency of process.
Nonetheless, we suggest the following additional protections against possible overreaching by the Board or staff of ICANN:
- A process should be established whereby alleged violations of ICANN's
bylaws can be submitted to non-binding arbitration by a recognized international
arbitration body. The costs of such arbitration should be borne by ICANN
in those cases where the arbitration finds a bylaws violation, and by
those asserting the violation when that assertion is rejected.
We do not believe that a "super-Board" that has the power to reverse decisions of the Board is either appropriate or workable. The composition of that body would quickly become a matter of great debate, and we have already seen how difficult it is to find persons that are acceptable to the entire community. Thus, we opt for using existing neutral institutions as the vehicles for reviewing whether the Board or staff has acted in some way inconsistent with ICANN's bylaws.
- An Office of Ombudsman should be created and staffed. The Ombudsman
should be hired by the Board after an open search for qualified applicants,
and would be provided an appropriate budget for staff support. The Board
would adopt a charter to govern the activities of the Ombudsman, after
appropriate public notice and comment. Once the charter is adopted,
the Ombudsman would not be subject to direct management by either the
Board or the CEO (although the CEO would be responsible for providing
various support services). The role of the Ombudsman would be to receive
complaints and criticisms, to decide in his or her sole discretion which
of those to pursue, and to decide how to report to the Board and/or
the public on the results of his/her inquiries.
- There should be a Manager of Public Participation. This would be a staff position, under the management of the CEO, whose sole responsibility would be to take the actions necessary to enable effective public input into the ICANN policy-development process. This could include managing the ICANN Announce list and any other mailing lists or forums, having an appropriate role in overseeing the ICANN website, summarizing for the Board, staff and community the inputs received from the public on particular issues, and generally taking whatever actions are necessary to ensure that those members of the general public who wish to make their views known will be able to do so in an effective way.
To be effective, ICANN must be properly funded. We have not yet concluded how to combine various proposals in order best to achieve this. Proper funding includes both the amount and the methodology, and, therefore, the predictability and the degree of control or manageability associated to the funding. Today, ICANN is funded largely through contractual payments by registries and registrars.
The amount of ICANN's funding must be driven by its responsibilities and the funding required to carry them out, as determined in an open and transparent budget formulation process.
IX. Government Participation in ICANN
We agree with Dr. Lynn's conclusion that more active governmental participation in ICANN, to help ensure that ICANN's activities fully reflect the broader public interest, while preserving ICANN's essential character as a private-sector institution, would be desirable. If this is not to come in the forms suggested in the Lynn Report, then it is critical that we find other appropriate vehicles to more directly integrate the concerns of governments and, indirectly, a reflection of the public interest into ICANN's policy-development process. In general, the most likely effective way to accomplish this objective is to create more direct liaison relationships between the Government Advisory Committee and the various constituent entities that make up ICANN.
As noted above, we believe that the GAC Chair (or delegate) should have a seat on the ICANN Board. In addition, the GAC should have a direct liaison relationship with the Steering Committees of the GNSO and CNSO, with the Address Council, and with ICANN's various standing Advisory Committees. We also believe that any policy-development structure and procedures adopted by the Board for the guidance of the SOs should require consultation with the GAC and all other standing Advisory Committees during that process and before any recommendation is submitted to the Board for action.
Finally, we believe that the GAC Secretariat, like the staff functions of all the ICANN constituent bodies, must be enhanced, and that there should be regular interaction between ICANN staff and the GAC Secretariat.
We recognize that there must be an increase of the quality, frequency, and directness of the interactions between the GAC and the Board, and increased opportunities for both to consider input from each other and the broader community.
X. Utilization of Outside Resources
There has been a variety of suggestions that ICANN should rely, in various ways and in various degrees, on outside expert bodies. We do not accept the notion that, for those limited matters within ICANN's core responsibility, they could be delegated for final decisions to some other body. We do agree, however, that it would be advisable for ICANN to seek advice, where practicable, from recognized experts whose advice would be respected by all parties, including governments. This was in fact the pattern that produced the Uniform Dispute Resolution Policy; ICANN received recommendations from WIPO, and used those recommendations as the basis for the establishment of the policy.
When concerns appear about areas such as competition policy, intellectual and industrial property policy, consumer protection, and various economic issues (such as pricing) – to the extent that ICANN has any role in any of those areas – it would obviously be desirable to have the best inputs possible, including from outside expert bodies (private or public, local in different countries or international). Thus, any revised ICANN bylaws should institutionalize the right and ability of the ICANN Board to refer specific issues to recognized outside experts for their advice, as part of the Board's decision-making process.
At any rate, it should be underlined here that ICANN has no wish or intent to enter any areas where content regulation or policing are required. This is one of many boundaries that are to be kept clearly in mind during the remaining part of the reform process.
There has been a variety of comments and suggestions for separating in some way the technical operational responsibilities of ICANN (largely but not exclusively performed by the IANA) from its policy-making responsibilities. Some believe they could be entirely separate organizations; many (even including those with widely varying views on other issues) do not. Some believe – very mistakenly in our view – that there is no need for a policy-making organization or that the function should be left entirely to governments. In this view, what would be left would be a very "thin" ICANN that purely concentrates on technical operations issues.
The Committee believes that there is necessarily a close interaction between policy and technical operations for the reasons set forth in the Working Paper on Mission and Core Values. The interface between them is quite complex. Separating the technical "IANA Plus" operations into another organization would likely require complex agreements between that organization and the policy organization, as well as complex agreements between governments (especially in the current circumstances the US Government) and both organizations. There would also inevitably be duplication of overhead, and the possibility that a superstructure encompassing both would be have to be established later. At least at this time, we do not believe it makes sense to attempt to go down this path.
Nevertheless, it is obviously desirable to carry out operational responsibilities
as efficiently and effectively as possible, and to ensure that policy
debates do not interfere unnecessarily with those technical operations.
This has been the goal of ICANN from the beginning, but staff and funding
limitations, and the learning curve itself, have made the achievement
of that goal very challenging indeed. Therefore, an important part of
any reform and evolution of ICANN should be to insulate technical operations –
to the extent practicable – from ICANN's policy-making responsibilities
and to subject them to more ordinary management considerations.
To accomplish this would require three specific tasks:
1. Identification of ICANN's technical operational responsibilities. The What ICANN Does staff paper includes a list of the current operational tasks that ICANN undertakes, but a careful evaluation should be made of which of those tasks are appropriately allocated to ICANN and which could be subrogated or outsourced to other entities. For example, ICANN currently operates one of the root name servers; this has a variety of useful benefits to the ICANN role in overseeing the root server system, but it is not inevitable that this need or should continue in the future. ICANN is currently responsible for the operation of the .int TLD. This reflects the continuing use of parts of that TLD for infrastructure purposes, some of which have not yet been migrated to .arpa. Administration of .int is not an essential role for ICANN in the long term, but because of its importance to continued development efforts, any transition would need to be very carefully managed, assuming a more appropriate operator can be identified. These are but two illustrations of the issues that would need to be sorted out, with broad community input, in determining exactly what ICANN/IANA's continued operational responsibilities should be.
2. Creation of a separate internal structure to carry out those operational responsibilities. Once the specific continuing operational tasks are identified, these should be allocated into a separate and well-defined activity within the ICANN structure. Oversight of the technical operation of this activity might well be one of the tasks of a Technical Advisory Committee, as envisioned above. This structure is conceived as an evolution of the core IANA function, with increased focus on operations and prompt interaction with its "clients" and appropriate and delineated funding.
3. Clear definition of the interface or coupling between the policy part of ICANN and the operational part. As mentioned above, this has always been the goal of ICANN, but staff and funding limitations have resulted in people wearing multiple hats, and in the inability to always deliver the appropriate level of service to those relying on ICANN's operational activities. Once these structure and funding problems are solved, the remaining task will be to clearly set forth the rules for how the operational personnel get policy direction for carrying out their tasks.
Finally, we note the what must come out of the upcoming meeting in Bucharest is an outline that will need to be filled in over the ensuing few months. We believe that we should complete this filling-in process to the maximum extent possible between Bucharest and the Shanghai meeting in late October. Then there will inevitably be a transition process over some time period necessary to move from ICANN 1.0 to ICANN 2.0. We will be prepared at the appropriate time to make recommendations as to how that transition should be managed. Thus, we want it to be clear that the recommendations contained in this document look to the long-term future of ICANN, not the shorter-term transition process.
Committee on ICANN Evolution and Reform
31 May 2002
| Click here to read comments on these recommendations. |
Questions concerning the layout, construction and functionality
of this site
should be sent to webmaster@icann.org.
Page Updated
20-Aug-2003
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.