Second
Interim Implementation Report
Posted: 2 September 2002
Committee
on ICANN Evolution and Reform
Second Interim Implementation Report
2 September 2002
1. Voting Members.
1. Sources of Nominating Committee Members.
2. Criteria for Selecting NomCom Delegates.
3. Criteria for Selection by NomCom.
4. Timeline.
1. Generic Names Supporting Organization.
b. General Assembly.
1. Governmental Advisory Committee.
2. Technical Advisory Committee.
3. Security Advisory Committee.
3. Public Input and Accountability.
4. Funding.
5. Bylaws.
6. Transition.
Appendix 1: Redrafted statement of ICANN's Mission and Core Values
Appendix 2: Tentative Timeline for the NomCom Process
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, and issued its First Interim Implementation Report on 1 August 2002. In this Second Interim Implementation Report, we lay out our tentative views on the majority of implementation details, and seek public comment on those views. We anticipate that we will make our "final" recommendations to the Board and the community on or about 1 October 2002. (We put "final" in quotation marks simply to make it clear that we may continue to refine those final recommendations in response to community feedback prior to or at the Shanghai meeting on 27-31 October 2002.)
We are prepared to make one final recommendation now: evolution and reform should be an ongoing process in ICANN. Each of the ICANN constituent entities, including the Supporting Organizations and the Advisory Committees, should be reviewed in some way at least every two years, with the objectives to determine whether (1) it has a continuing purpose in the ICANN structure, and (2) if so, whether any change in structure or operations is desirable to maximize its effectiveness. ICANN should be a living, breathing body, changing to meet evolving needs and circumstances. Thus, we recommend that approximately half of ICANN's constituent entities be subject to some form of independent scrutiny every year, and that the community and the Board should carefully consider any recommendations for changes arising from those reviews.
With this Report, we will have posted two Interim Implementation Reports, two earlier status reports, and the recommendations of three Assistance Groups. All have asked for community feedback, and we have received a large number of comments, both to the forum established for this purpose and in various other ways. This feedback has been essential to our work, as will be obvious from reading this Report, since many of the recommendations contained in it are the direct result of comments and suggestions from the community. As was the case in developing the Blueprint, the implementation work is an iterative process, and each succeeding document reflects the care and attention that many throughout the community have given to this subject.
As we reach the conclusion of our work, it is even more critical that all members of the community make their views known, so that we can take them into account in producing our "final" recommendations on or about 1 October. What follows in this Report is a statement of our current thinking and preliminary conclusions as to what to recommend on the issues discussed, so to the extent that there are strong reactions, pro or con, now is the time to present them. It would be unfortunate to have serious objections or new ideas raised first at the Shanghai meeting, when it will probably be too late to deal with them effectively. Now is the time for comments, ideas, reactions, and objections.
Attached as an appendix to this Report is a redrafted statement of ICANN's Mission and Core Values, taking account of both the suggestions from the GAC referenced in our First Interim Implementation Report and other comments received. We have incorporated most of the GAC editorial suggestions, and have dealt with the extent to which ICANN's mission includes policy development as outlined in our First Interim Implementation Report. Having properly formulated statements of mission (defining ICANN's scope) and core values (guiding how activities within the mission should be exercised) is a very important element of ICANN reform; we continue to seek comments and suggestions for improving this language.
The Blueprint describes a 15-member Board of Directors (with five non-voting liaisons), three Supporting Organizations, and four Advisory Committees. The Board instructed the ERC to examine the feasibility of creating an At Large Advisory Committee as a possible fifth Advisory Committee. The ERC established an Assistance Group to evaluate that possibility, made up of members of the community who had been active in the various At Large initiatives in the past. After considering various comments, and the recommendations of the Assistance Group, we have decided to recommend the creation of such an At Large Advisory Committee, thus increasing the number of Advisory Committees to five.
In addition, the Blueprint calls for a Nominating Committee, charged with selecting eight members of the ICANN Board and certain members of other ICANN bodies. We set forth our tentative conclusions on the implementation details of each of these elements below.
1. Voting Members. We have considered various comments and suggestions relating to the size and composition of the Board, and concluded that the Blueprint recommendation for a Board consisting of 15 voting members remains sound. The goal here was to balance the various interests in the community, while creating conditions that maximize the ability to attract high-quality persons to serve on the ICANN Board and reducing the Board size to enhance effectiveness. We believe that the selection of a majority of Board members by a broadly representative Nominating Committee, with the remainder of the Board (other than the President) selected by the ICANN policy development bodies, best meets these goals. Issues of geographical and functional diversity, critical to an effective ICANN Board, are better dealt with through the Nominating Committee process, rather than by expanding the number of Board seats selected by the Supporting Organizations.
2. Non-Voting Liaisons. The Blueprint proposed five non-voting liaisons to the Board – one from each of the four current or proposed Advisory Committees (the SAC, the GAC, the RSSAC and the TAC) and one from the IETF/IAB. As indicated above, we recommend that an At Large Advisory Committee be created; if that recommendation is accepted, we believe that it, like the other ICANN Advisory Committees, should also provide a non-voting liaison to the Board. This would increase the number of non-voting liaisons on the Board to six, and the total size of the Board, including non-voting liaisons, to 21.
The Blueprint also calls for the non-voting liaisons, like voting Board members, to serve three-year terms. On reflection, we believe it would be more appropriate for those bodies selecting non-voting liaisons to the Board to select them on an annual basis, subject to reappointment. This will provide those bodies with added flexibility in allocating the responsibilities of their various members.
1. Sources of Nominating Committee Members. The Blueprint called for a Nominating Committee (NomCom) of 19 delegates, a non-voting Chair appointed by the Board, and two non-voting liaisons – one each from the RSSAC and the SAC. It sought to create a broadly representative committee with a workable balance of delegates from the provider, user, technical, and public interest communities.
The Blueprint set out the following recommended composition of the NomCom:
- 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)
After further consideration, we suggest certain modifications to the Blueprint list, as described in the following text.
With some exceptions, delegates to the NomCom will be named by various ICANN constituencies, as detailed in the Blueprint and amplified here. There are three reasons for this: (1) to ensure that there are NomCom members familiar with the concerns of particular constituencies; (2) to ensure that the individual voices of the different ICANN constituencies are heard in the NomCom; and (3) to ensure that the widest possible net will be cast across and beyond the ICANN community to identify the best possible candidates for the various positions to be filled.
A number of the NomCom delegates identified in the Blueprint may be logically drawn from existing entities. For example, the gTLD registries and registrars are identifiable groups, with pre-existing representative bodies (the respective Constituencies of the GNSO). Thus, these positions on the NomCom can be filled from each of those respective Constituencies. Other delegates can also be named by pre-existing entities; these include the address registries (via the ASO Council), Internet service providers (the ISP Constituency), intellectual property interests (the IP Constituency), the IAB/IETF, and the GAC, as well as the non-voting liaisons to the NomCom from the RSSAC and the SAC.
With respect to the two delegates named by large and small business users, the Business Constituency has proposed that, since it consists of both large and small businesses and business organizations, it could reasonably be the source of both the large and small business delegates. We note that there are today no existing "Large" or "Small" Business Constituencies, just a "Business" Constituency. While we understand that some steps have been taken to begin organizing a "Small” Business Constituency, we also note that many of the business organizations that are members of the Business Constituency do claim to represent large numbers of both large and small businesses (both directly and through globally distributed association membership). Thus, while we encourage all efforts to expand the representation of businesses globally, we believe that an appropriate and practical short-term solution is to allow the existing Business Constituency to select two delegates to the Nominating Committee, one demonstrably reflecting large business interests and perspectives and the other those of small businesses. If and when any new constituencies are recognized by the ICANN Board (which would of course require a showing that they would adequately represent the interests globally of the entities they purport to represent), this issue can be revisited.
Since the TAC is intended principally to provide a mechanism for identifying resources from the various elements of the Internet technical community (see the discussion below), each TAC member body should select the TAC delegate to the NomCom in turn, so that the responsibility for selecting the delegate rotates among the TAC member bodies in the same way in which we propose that the selection of the TAC liaison to the Board rotate among the TAC member bodies (see below).
Detailed discussion of how the ccNSO (see discussion below on this name) delegate is selected should probably await the further efforts of the Assistance Group we intend to create on the subject of structuring the proposed Country-Code Names Supporting Organization. In general, however, the ccNSO delegate to the NomCom should be drawn from the community of ccTLD managers who participate in ICANN.
With respect to the two delegates from academic and other public entities and consumer and civil society groups, there is an existing Non-Commercial Domain Name Holders constituency that was originally established to map approximately to these categories. Some organizations of both groupings are at present affiliated with the existing Non-Commercial Domain Name Holders Constituency of the DNSO, but we note that very few academic entities are represented officially in the constituency. Given the composition of NCDNHC's active membership, we feel comfortable looking to that constituency for the consumer and civil society delegate to the NomCom, but we are somewhat reluctant to turn to it as a permanent (or even temporary) source of the academic and other public entities delegate. On the other hand, we are aware of no new constituency organization underway in this area. Thus, we solicit suggestions as to how to initially fill the NomCom delegate position for academic and other public entities.There is currently no obvious organized, globally recognized source for the four "unaffiliated public interest persons" in the Blueprint list. If our recommendation to establish an At Large Advisory Committee is accepted by the Board, and that advisory committee matures as expected, we believe that eventually it would be appropriate for the ALAC to select five delegates to the NomCom (one from each ICANN region, appointed by the regional councils envisaged in the ALAC proposal). This would ensure the NomCom has the benefit of geographically diverse perspectives drawn from the ALAC, and thereby promote the geographical diversity that is an important objective of ICANN. Under these circumstances, the five ALAC delegate positions could replace the four unaffiliated public interest persons and the individual domain name holder delegate positions included in the Blueprint list (since there is at present no existing individual domain name holder constituency; if and when such is recognized, this could be re-evaluated). We also recognize, however, that there is a considerable distance between drafting on paper and becoming truly functional, and it is unrealistic to expect an ALAC, even if launched in Shanghai, to become immediately effective. Thus, we invite the ALAC Assistance Group or other members of the community to propose how some or all of these delegates could be selected until such time as the ALAC is operational and has shown that it can function effectively.
If these recommendations were accepted, the NomCom would be composed of 18 voting delegates selected by the following groups:
- gTLD registries (1) (selected by the gTLD Constituency)
- gTLD registrars (1) (selected by the gTLD Registrar Constituency)
- ccTLD registries (1) (to be determined)
- Address registries (1) (selected by the ASO Council)
- Internet service providers (1) (selected by the ISP Constituency)
- Large business users (1) (selected by the Business Constituency)
- Small business users (1) (selected by the Business Constituency)
- IP organizations (1) (selected by the IP Constituency)
- At Large (5) (initial selection to be determined)
- Academic and other public organizations (1) (to be determined)
- Consumer and civil society groups (1) (to be determined)
- IAB/IETF (1) (selected by the IAB/IETF)
- TAC (1) (rotated among the TAC member entities)
- GAC (1) (selected by the GAC)
In addition, we believe that the previous year's NomCom Chair should also serve as a non-voting member of the NomCom, as one way to provide continuity to the function.
As described above, the NomCom would have five delegates selected by groups who provide services of various kinds, 10 delegates (eventually) selected by various user groups, two delegates selected by technical bodies, and a delegate selected by governments. In addition, there would be a non-voting Chair, last year's Chair, and two non-voting liaisons, with the latter selected by technical bodies. So the final mix of delegates, voting and non-voting, would be five from providers, 10 from users, four from the technical community, one from governments, and the Chair and previous year's Chair (selected by the Board). We are studying additional mechanisms to ensure and perfect the geographic diversity that has already been a highly successful element of ICANN; at a minimum, each delegate from a constituency or similar group should be succeeded by a delegate from a different region.
We welcome comments on these modifications to the Blueprint.
2. Criteria for Selecting NomCom Delegates. We believe that the Nominating Committee is one of the most important parts of a reformed ICANN. It must function effectively, or ICANN itself will not function effectively. Thus, while selections for NomCom delegates should be left in the hands of appropriately representative bodies, we feel strongly that all NomCom delegates should meet the following standards:
a. A NomCom delegate should be an accomplished person of integrity and intelligence, with a reputation for sound judgment and an open mind.
b. A NomCom delegate should be a person with wide contacts, broad experience in the Internet community, and a commitment to the success of ICANN.
c. A NomCom delegate should be a person whom the selecting body trusts to consult widely and accept input in doing his/her work on the NomCom.
d. A NomCom delegate should be neutral and objective, without any fixed personal commitments to particular individuals, organizations, or commercial objectives.
e. A NomCom delegate should be a volunteer, and not be compensated for service on the NomCom.
f. A NomCom delegate should have experience and be competent with collegial large-group decision-making.
g. A NomCom delegate should be able to work and communicate in written and spoken English. The ability to communicate in other languages is highly desirable, and it is expected that all NomCom delegates will tolerate and respect the fact that English will be a second language for most delegates.
h. A NomCom delegate must have the ability and capacity to communicate and network effectively and broadly (i.e., must have access to functioning communication channels including telephone, e-mail, and web access, particularly during the periods of intense NomCom activity).
We specifically did not list familiarity with ICANN, or with the DNS, IP addressing, or Internet protocols. While many delegates may have some or all of these attributes, we do not believe that they are essential to carrying out NomCom responsibilities. Nor do we believe that those with employment relationships with entities that could be affected by ICANN should be disqualified from service on the NomCom. This is not a policy-making body; to be broadly representative and effective in locating the most suitable people to fill the positions for which it is responsible, it must be able to access persons from the entire community. Since particular employment (other than by governments) is not disqualifying for a seat on the ICANN Board, it should also not affect the selection of delegates for the NomCom.
3. Criteria for Selection by NomCom. As set forth in the Blueprint, the NomCom will be responsible for selecting some members of the ICANN Board, the GNSO Council, the ccNSO Council, and the TAC. In addition, we recommend later in this Report that the NomCom also select a portion of the ALAC. Thus, the criteria for selection may vary to some extent, but there will be considerable overlap. We set forth below our views on the criteria to be used in NomCom selection of ICANN Board members, and we invite comments on specific different or additional criteria that should be used for other NomCom selections.
Criteria for Board Members. ICANN Board members selected by the NomCom should be chosen to ensure that the Board is composed of members that in the aggregate bring diversity in skills, experience, and perspective to the Board. They should meet all the relevant criteria set forth above for NomCom members, and in addition the following standards:
a. Commitment to the success of ICANN in carrying out its mission. Service on the ICANN Board is time-consuming, requires the willingness to absorb large amounts of information which may be technical, legal, or otherwise extremely specialized and marginal to an individual Board member's field, and can involve making difficult choices among competing positions, each of which may have merit. Service inevitably invites attention, some of it critical, and always carries with it the significant responsibility for oversight of a small but essential element of the Internet. The responsibilities of an ICANN Board member cannot be carried out effectively without a personal commitment to the ICANN mission.
b. Broad functional diversity in the areas of expertise relevant to ICANN's mission. This means that the NomCom should make selections that ensure that the ICANN Board has some members with personal familiarity with the operation of gTLD registries and registrars; with ccTLD registries; with IP address registries; with Internet technical standards and protocols, especially those defining the Internet's naming and addressing systems; with policy-development procedures, legal traditions, and the public interest; and with the broad range of business, individual, academic and non-commercial users of the Internet.
c. Global geographic and cultural diversity. The NomCom should should seek the broadest cultural and geographic diversity on the Board consistent with meeting other criteria. At a minimum, the NomCom should make selections that ensure that the ICANN Board has at least one member from each of ICANN's geographic regions, and that no more than half of its voting members are from any single region.
d. Understanding of ICANN's mission and its impact. The NomCom should ensure that the ICANN Board members it selects appreciate the limited but important scope of ICANN's mission, and are able to understand the implications and impact of ICANN decisions on the broad global Internet community.
e. Ability to contribute to the credibility of the ICANN Board. The ICANN Board makes decisions that can have widely varying impacts on various constituencies. These impacts may be positive, or in some circumstances could impose additional burdens. It is critical that ICANN Board members be perceived as persons of integrity, objectivity, intelligence, and demonstrated capacity for thoughtful group decision-making, which should ultimately result in credibility in carrying out their volunteer responsibilities on behalf of the Internet community.
We invite comments on these selection criteria, and how they should be modified to apply to selections for other than the ICANN Board. In addition, we invite comments as to whether and how these criteria should be applied to Board selections by Supporting Organizations. Our general view is that they should largely apply to those selections as well.
4. Timeline. We include in an appendix a tentative timeline for the NomCom process. We invite comments on this.
The Blueprint recommended three SOs – Generic Names, Country Names, and Address. We continue to believe this is the correct configuration. Each of the Supporting Organizations should be supported by an ICANN staff person whose primary responsibility is to support the SO's activities, under the direction of the SO Council.
1. Generic Names Supporting Organization.
a. Composition of Council. The Blueprint calls for a Council initially composed of six voting constituencies, equally divided between provider constituencies and user constituencies. Each was to select two voting members to the Council. We believed that this balance was important to create the maximum incentives for the creation of a consensus position. Without such balance, the majority side of an issue has the perverse incentive to not seek consensus; with such balance, and especially with the addition of three voting members of the Council selected by the NomCom to serve as the neutral tiebreakers, the incentives for compromise and consensus are considerably improved.
On further reflection, and after carefully considering feedback from the community, we believe that the proper balance to be sought on the GNSO Council is not so much between providers and users, but between those who are under contract to ICANN and those who are not. The former are the entities that will be compelled to implement the policies developed by ICANN, and who could be required to change, possibly substantially, their business operations because of decisions by ICANN. The GNSO is the policy-making body that originates policy recommendations ultimately acted on by the ICANN Board. Thus, applying the concept in the Blueprint calling for appropriate balance, we believe that the representatives of entities under contract to ICANN should have voting power on the GNSO Council equal to the representatives of entities that are not under contract to ICANN.
As we noted in the Blueprint, it is a challenge to develop a scheme for maintaining this balance, particularly one that allows for the possible addition of new constituencies (all or most of which would be likely to fall on the non-contract side of the balance). We believe that the best way to accomplish this balance is for the aggregate number of votes allocated to those constituencies representing entities under contract with ICANN to be equal to the aggregate number of votes allocated to constituencies associated with entities that are not under contract, and to remain so regardless of future changes in the number of constituencies. Today, this would mean that the gTLD registrar and registry constituencies would be allocated the same number of votes in aggregate as the four other constituencies collectively (Business, IP, ISP, NCDNHC). Initially, this could be accomplished by allocating 2 votes to each of the gTLD registry and registrar representatives, and 1 vote to each of the representatives of the other four constituencies, but these precise numbers could change as constituencies are added in the future. NomCom selected members would continue to have one vote, and thus be able to break any deadlock.
Moving now to the size of the Council, we have noted and carefully considered the resolution adopted by the current DNSO Names Council calling for reconsideration of the Blueprint recommendation that the GNSO Council consist of two members from each constituency and three members selected by the Nominating Committee. The Names Council unanimously recommended that there be three representatives from each constituency on the Council, arguing that this is necessary to share workload and to increase geographical diversity. The ERC has carefully considered this issue, and while noting and giving weight to the arguments in support of three members per constituency, continues to believe that the desirability of a smaller and more effective Council outweighs these arguments. Nevertheless, given the unanimous support on the existing Names Council for this adjustment from what was proposed by the ERC in the Blueprint, we are considering recommending to the Board a change in the Blueprint from two representatives per constituency to three representatives per constituency, at least for the first year. This approach would allow for a more orderly transition. (At the end of the first year, this and other aspects of the GNSO should be reviewed; absent compelling evidence to the contrary at that time, our view is that the number of representatives should be reduced to two per constituency.) Each constituency representative must come from a different region, regardless of whether there are two or three.
If this transition recommendation is followed, the GNSO Council would temporarily increase in size from 15 members (under the Blueprint) to 21 members. We doubt that this increase in size will be conducive to increased efficiency or effectiveness, and the possible addition of new constituencies would create an even more unwieldy size, but we understand and accept the desire for a workable transition model.
We invite comments from the community on the issues discussed above.
b. General Assembly. The Blueprint states that the "GNSO General Assembly should be a cross-constituency meeting place . . . ." It also notes that 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 Blueprint calls for the GA to support only moderated electronic discussion lists and forums in which all interested individuals and groups can participate, and to be chaired by a member of the GNSO Council appointed by that Council.
The ERC has given further consideration to this issue, taking into account various comments and suggestions received and certain other decisions subsequently made, such as the recommendation to create an At Large Advisory Committee. We found particularly useful the recommendations made by Thomas Roessler and Alexander Svensson, who productively condense many of the discussions of the present General Assembly. While we do not agree with all their suggestions, they were thoughtful and offered with supporting explanations, which is a particularly useful approach.
Our current thinking, on which we invite comments, is that the existence of an effectively functioning ALAC might eventually eliminate or significantly reduce the need for and utility of a General Assembly. In our view, an effective ALAC would operate properly moderated mailing lists and the like, thus allowing wide-ranging public discussion of ICANN-related issues. Given this, there may be no need for a separate General Assembly. We do take note of the long-standing discussion on the overlap or competing functions of a General Assembly concentrated on domain-name policy and an ALAC with a possibly wider range of concerns, which has been reactivated in the reform process, and we invite comments on this conclusion.
Since it will be some time, even if our recommendation to create it is accepted by the Board in Shanghai, before it is clear that the ALAC can in fact carry out this role, our current thinking is that the GNSO Council should maintain the operation of the current General Assembly discussion lists until such time as the ALAC has shown it can take over that responsibility, and at that time the responsibility for a general public discussion list on ICANN issues should be transferred to the ALAC. If this approach were followed, it would be unnecessary that there be such a thing as a General Assembly Chair. Of course, under this approach, the GNSO Council should have the power to designate the General Assembly list managers/moderators for the time it remains responsible for that list, and after that the ALAC would have this responsibility.
The disadvantage to this approach is that it would eliminate the General Assembly as a potential vehicle for cross-constituency dialogue. While we still believe this vehicle would be useful, that suggestion does not appear to have been enthusiastically received by GNSO participants, whose active participation is necessary to its success.
We agree with Roessler and Svensson that more participation by GNSO constituency members on whatever discussion lists are provided would be desirable, but we note that such participation is made less likely to the extent that the list moderation rules permit non-substantive or abusive postings. Therefore, we reiterate our recommendation that the General Assembly list, as with any discussion lists supported by the GNSO or ALAC, should be moderated to prevent non-substantive, abusive and off-subject postings. We recognize the potential burden that such moderation would impose, and suggest that the GNSO Council, as a first order of business, adopt practical moderation rules that adequately protect the usefulness of the GA list so long as it is the responsibility of the GNSO. In this respect, we find the suggestions of Roessler and Svensson particularly useful.
We invite comments on this discussion, especially from the GNSO constituencies on which this suggestion would have the most impact.
c. Generic Names Policy Development Process. We greatly appreciate the hard work of the Assistance Group on this subject, chaired by Rita Rodin. We have reviewed their recommendations, and we encourage further public comment on them. In general, we find the recommendations cogent and persuasive, and with some modifications are inclined to recommend their acceptance by the Board as part of the implementation process. We offer the following initial specific comments:
1. We accept the general timeline of 95 days from the initiation of a policy development process (PDP) to a recommendation to the Board. We recognize that this remains an aggressive schedule for an organization that depends on volunteers for most of its work, and appreciate that this schedule can only be met if those volunteers have adequate staff support. We also recognize that this timing may not be consistent in all cases with the desirability of seeking advice from outside expert panels or bodies. Nevertheless, we think there is great value in having a standard process and timeline, even if occasional exceptions are required, and we believe that the general process and timeline set forth by the Assistance Group is appropriate and workable. The review of the GNSO and its processes that is contemplated one year after it begins operations will be a good opportunity to assess the effectiveness of both the recommended process and the timelines.
2. We agree that there must be a clear understanding of which issues are truly policy issues and which are not, and of whether the Board is asking the GNSO or other SOs for policy recommendations or simply for advice. The principles set forth in the Blueprint were an initial effort to deal with the former, and we were pleased to see their incorporation in the PDP. We believe the modification suggested therein is appropriate, and we agree with the inclusion in the process of an opportunity for receiving a formal opinion from the General Counsel on this issue prior to the initiation of a PDP.
3. Those portions of the Assistance Group recommendations relating to the timing and constraints on the Board's action require further consideration before we are prepared to state our views on them. We appreciate that the Assistance Group provided cogent suggestions, and while Committee members are persuaded by many of the Assistance Group's arguments, some implications are still under discussion, and require further community input as well. We do generally agree that a consensus policy recommendation (described by the Assistance Group as one that receives a "supermajority" vote of the GNSO Council) should carry greater weight with the Board than a recommendation that does not reflect as broad a consensus, but how that should affect the ability of the Board to act is still under consideration. We invite comments from the community on these issues.
4. We find the suggestion of a status web page detailing the progress and current status of each PDP a good one, and we intend to recommend such be created.
Again, we thank the Group for its very considerable efforts, and we strongly encourage community feedback on the recommendations and these comments. We would anticipate including in our "final" recommendations specific suggestions on the policy development process, drawn heavily from these recommendations, but we would certainly be interested in additional community comment prior to that time.
2. Country-Code Names Supporting Organization (ccNSO).
We are persuaded by community feedback that using the word "Country" is inaccurate and misleading. While the term "country code" is equally incorrect technically, community familiarity and its well-established meaning make it an acceptable substitute. "Geographic" would probably be preferable, but that would result in acronym confusion with the Generic Names SO.
The ERC has engaged in several discussions with individual ccTLD managers and with groups of ccTLD managers and others on the general subject of a ccNSO. In those discussions, we have announced our intention to create an Assistance Group in the very near future to make recommendations relating to the ccNSO, including its membership, scope, and internal organization. We encourage input from the community on the appropriate implementation of the ccNSO to that Assistance Group once established.
3. Address Supporting Organization.
The Blueprint calls for no changes to the current ASO structure except for the addition of a GAC liaison to the Address Council, consistent with the approach throughout the organization. We have no additional comments to make at this time.
The Blueprint called for four advisory committees. We presently intend to recommend that there be a total of five – the four identified in the Blueprint and an At Large Advisory Committee. Each AC that requests it should be supported by ICANN staff, working under the direction of the AC Chair. In addition to the positions taken in the Blueprint, we currently contemplate making the following recommendations to the ICANN Board:
1. Governmental Advisory Committee.
The GAC should appoint a non-voting liaison to the ICANN Board. In addition, the GAC should have the right to appoint a non-voting liaison to SO Councils or Advisory Committees, to the extent that it believes such is both appropriate and useful.
2. Technical Advisory Committee.
The Technical Advisory Committee is intended to channel technical advice and guidance to the Board and to other organizations within ICANN. It will serve ICANN in two different but equally important roles: (1) as an entry point to a broad range of technical communities with expertise relevant to ICANN's mission, so that specific technical questions that arise in the course of ICANN's work can be referred to the people and/or organizations best qualified to answer them; and (2) as an active "watchdog" ensuring that technical issues that might otherwise be overlooked are brought to the attention of decision makers.
Reporting directly to the Board, the TAC should be chartered to undertake the following tasks:
- To connect the Board with appropriate sources of technical advice on specific matters of interest to the Board.
- To communicate on technical matters with a broad range of persons and organizations, including (1) the operators and managers of Internet naming and address allocation infrastructure services; (2) companies and individuals who implement the Internet naming and addressing standards; and (3) those bodies with direct responsibility for Internet naming and address allocation matters (including, in addition to the organizations represented on the TAC itself, the RIRs, name registries, registrars, etc). The TAC is expected to advise the Board of the relevance and progress of technical activities in any of these quarters that could affect Board decisions or other ICANN actions, and to draw attention to global technical standards issues that affect policy development within the scope of ICANN's mission.
- To report periodically to the Board on its activities.
The TAC is not chartered to provide policy advice to the Board, although organizations participating in the TAC may individually be asked by the Board to do so as the need arises in areas relevant to their individual charters. Neither is it intended to debate or otherwise coordinate technical issues across its participating organizations or to establish unified positions and thus it does not impose on them an additional, unnecessary layer of coordination for the development of technical standards. The TAC has no involvement, advisory or otherwise, with the IANA's work for the IAB/IETF/IRTF.
In order to fulfill this charter, the TAC should:
- consist of individuals with direct experience with technical standards issues relating to ICANN's activities;
- consist initially of 10 members selected by the ICANN Board based on nominations from ETSI, ITU-T, W3C, IETF, and IAB (two nominations from each organization), and three other persons with a strong technical background selected through the NomCom process, resulting in a total initial membership of 13;
- select its own chair for a one-year non-renewable term;
- appoint one non-voting liaison member to the ICANN Board, selected by each of the organizations represented on the TAC in turn on a rotating basis, for a one-year term; and
- appoint one delegate to the Nominating Committee, selected by each of the organizations represented on the TAC in turn on a rotating basis, for a one-year term.
The mechanism whereby the responsibility for selecting a NomCom delegate and a liaison to the Board rotates among the TAC member organizations should ensure that in any given year the selections are performed by different organizations.
Following the general procedure for all ICANN constituent entities, the Board will review the charter, structure, and operation of the TAC after one year of operation and every two years thereafter.
3. Security Advisory Committee.
The Security Advisory Committee should continued as a Board Advisory Committee, with its current charter modified to allow for a GAC liaison, and should appoint a non-voting liaison to both the ICANN Board and the Nominating Committee.
4. Root Server System Advisory Committee.
The RSSAC should continue as a Board Committee, with its current charter modified to allow for a GAC liaison, and should appoint a non-voting liaison to both the ICANN Board and the Nominating Committee.
5. At Large Advisory Committee.
We appreciate the hard work of the Assistance Group on this subject, led by Denise Michel and Esther Dyson. We welcome their recommendations, and we encourage broad public comment on them. The following are some initial specific comments on the Assistance Group recommendations:
1. We agree with the Assistance Group that the "establishment of an ALAC should be viewed as a critical first step towards structured involvement of the individual user community in ICANN and, in particular, towards a formalized role in ICANN's policy development process that ensures [individual] users' views are taken into account." This has always been a goal of the ICANN effort, and it remains one of the unfinished pieces of organizational business for ICANN. We recommend the creation of an ALAC as the most effective way to begin this process.
2. We note that the ALAC proposed by the Assistance Group is a somewhat complicated – but we believe achievable – undertaking. While we appreciate that some of the initial organizational work has already been done, there is a very long way to go from the presently available narrative and a diagram to a truly workable structure that can provide meaningful and informed input to the ICANN process. Thus, we believe that we should proceed with small steps rather than giant leaps, all the while with the understanding that what we begin with today will likely evolve into the finished product. Just as we have seen with the Supporting Organizations, which in the reformed ICANN will look (and perform) very differently from the original versions, the ALAC we start with will likely mature into a different structure. For that progress to be steady and positive, we should begin with manageable steps.
3. For these reasons, we will likely recommend that the initial ALAC be appointed by the Board, and that the members of the ALAC Assistance Group be included in those initial appointments. We are not as sanguine as the Assistance Group that this complicated structure can be functional immediately, and yet we do agree that there must be a focus for immediate and continued progress. Given the significant efforts to date by the Assistance Group, their appointment to an Interim ALAC seems suitable and appropriate. It may also be appropriate for the Board to augment that group with additional appointments, with an eye toward encouraging continued progress toward a stable permanent structure. We are open to other suggestions as to how to populate the initial ALAC without imposing cumbersome and time-consuming processes.
4. We will likely recommend that the ALAC appoint a liaison to the Board. Like other liaisons appointed by ICANN Advisory Committees, the ALAC liaison should initially be non-voting. By this, we do not mean to dismiss forever the possibility that the ALAC (or some other appropriate At Large entity) could eventually select voting members of the ICANN Board. As the ALAC matures, or if and when at-large elections become practicable, the appropriate vehicles for the expression of the views and interests of the general individual user segment of the community can be reconsidered.
5. As explained earlier, we also accept the recommendation that the ALAC, once properly organized and functioning, should select five delegates (one by each ICANN regional council, as proposed by the Assistance Group) to the Nominating Committee. Until these regional councils are functional and operative, we invite the ALAC Assistance Group or other members of the community to propose how some or all of these delegates could be selected until such time as the ALAC is operational and has shown that it can function effectively.
6. We are not persuaded that the ALAC should appoint liaisons to the Supporting Organization Councils or other Advisory Committees, at least at this time. We do not see the need or desirability for this added complication to the ICANN structure, nor is it consistent with the progressive build-up approach that we believe the evolution of the ALAC should follow. This can be reconsidered in the future.
7. We believe that the most critical step in creating a functioning and effective ALAC is establishing the criteria to be applied in admitting members to the ALAC, and in the processes for selecting members of the ALAC itself. We endorse the notion of local, self-supporting structures, and we remain interested in seeing how this notion will be implemented. We would also welcome additional community comments on this issue in particular.
8. While we believe we understand the rationale for the bottom-up structure suggested by the Assistance Group, the Board will no doubt be interested in seeing how this structure is implemented. We generally agree with the notion of using a MOU approach to the certification of the Regional At Large Organizations, and look forward to suggestions as to what that MOU should contain from both the members of the Assistance Group and the community at large. We also agree with the proposal of the Assistance Group that each Regional At Large Council should appoint two members of the ALAC, and that the NomCom should name one additional member from each region. This would result in an ALAC of 15 members, 10 selected by the Regional Councils, and five by the NomCom.
9. We agree that individual at large entities should meet some "accreditation" standard, and we find the criteria and standards recommended by the Assistance Group to be an attractive list. We would be interested in community comments on how that "accreditation" should be implemented. Our tentative view is that, at least initially, a group appointed by the ICANN Board should do any such “accreditation”, but we welcome other suggestions as well.
10. We are not persuaded that ICANN should reimburse ALAC members' travel costs to ICANN meetings. We appreciate that funding is an issue for all individuals and organizations, but do not believe that it would be appropriate to fund travel costs for one set of Advisory Committee members and not for the participants in other ACs and SOs. We do agree that the ALAC should have sufficient ICANN staff support to effectively carry out its operations, and will so recommend.
In this context, we intend to recommend that the reformed ICANN generally set for itself the goal to depend less critically on face-to-face interactions in physical meetings, and make it progressively easier and more effective for individuals to participate at a distance with no significant disadvantage.
We encourage community comment on this discussion, and on the entire set of Assistance Group recommendations generally.
3. Public Input and Accountability.
One of the continuing issues for ICANN since its creation has been the establishment of procedures and structures to ensure both broad public input and appropriate methods of review of ICANN actions. The At Large Advisory Committee described above will offer a significant opportunity for informed public input into the ICANN decision-making and policy development processes. The ERC asked Becky Burr, who was present at the creation of ICANN in her former governmental capacity and has continued to stay involved since returning to the private sector, to provide recommendations about four other aspects of a reformed ICANN recommended by the Blueprint: an Ombudsman; a staff position dedicated to ensuring that information about ICANN's activities, and public reaction to those activities, is fully adequate and available to the ICANN Board and constituent entities in a timely manner; a reformed Reconsideration Process; and an Independent Review process.
Ms. Burr has provided her recommendations, and we thank her for the significant effort involved. We find her recommendations helpful and generally persuasive. We strongly encourage comment and reaction from the community, so we may take that into account in producing our "final" recommendations. In the meantime, we offer the following initial comments on Ms. Burr's recommendations:
1. In general, we agree with the proposed charter for the Office of Ombudsman. We believe that the Office should be funded through the normal ICANN budget process, subject to community comment, and the Office budget ultimately approved by the Board. In order to ensure the neutrality of the Office, the Office should prepare its own budget request separate from that of the ICANN CEO, but both should go through the same community and Board scrutiny. We agree with an initial term of two years, with the possibility of a longer tenure after some experience with this concept; we agree that adequate job security is part of the perception of neutrality that is required for this concept to be effective.
We solicit community comments on the Charter, the list of proposed duties and other aspects of the Ombudsman concept.
2. In general, we also agree with the recommendations relating to the Manager of Public Participation (this is just a working title). This person should be responsible for working with the Board, other staff, and the ICANN constituent bodies to help facilitate informed public comment on ICANN activities, and to ensure that comment is understood and available for consideration by the Board and other ICANN bodies. Obviously, this position must coordinate carefully with the staff assigned to support particular ICANN entities, such as the SOs and the ACs, and particularly with the ALAC if created. (We note the comment concerning the need for proper integration of the roles of the Manager of Public Participation and the Staff Manager proposed for the GNSO PDP, and will give attention to this issue.) To the extent practical, information about the current status of ICANN activities should be electronically available on as close to a real-time basis as possible.
3. The recommendations concerning the Reconsideration Policy seem quite sound. At the present time, our intention would be to follow these recommendations almost totally. The one exception might be the notion that the Reconsideration Committee should report to the Board on a quarterly basis; we agree that a periodic report of the kind suggested would be useful, but our current view is that an annual report would be sufficient.
4. The issues surrounding the Independent Review Process are difficult. In general, we find the recommendations useful. Until we can have more detailed discussions with possible providers of arbitration services, we must withhold final judgments on certain of the procedural recommendations made.
5. With respect to the "Additional Recommendations and Observations," we welcome them and will give them serious consideration. We agree it is likely that, as the reformed ICANN further matures, certain additional mechanisms may be appropriate and useful in this area, and we welcome community comment on these suggestions. We note that, while a variety of concerns have been expressed over time about possible "mission creep," and it is true that bylaws are not immutable and thus do not perfectly prevent the possibility of such "mission creep," we have yet to discover and no one has yet suggested an approach that could create more certainty (without eliminating necessary flexibility) than stating ICANN's mission (see Section 1 above) in the ICANN bylaws. We welcome any such suggestions. We also welcome specific suggestions to deal with the other issues raised in this section of Ms. Burr's report, although we believe these issues are likely beyond the scope of the current reform process.
It is quite clear from a reading of the above that, if all these recommendations are accepted, additional staff will be needed. There is a paradox here: everyone wants a "lean and mean" ICANN, but everyone wants the part of ICANN over which he or she is most concerned to function effectively and smoothly. Just like the paradox that more and more process can produce fewer and fewer results, effective functioning in an organization made up of volunteers requires significant staff support. For policy development processes to move rapidly and effectively, and with full appreciation of the relevant considerations, there must be an appropriate infrastructure able to support and implement both the processes and the decisions made by the ICANN volunteer participants.
The approved 2002-2003 budget represents an important increase over 2001-2002, allowing for a modest staff increase from an approved level of 21 (with 17 actually now on board) to 27. Ramping up to these levels will take time, especially with the actual process of recruitment competing for attention with all the many other tasks that ICANN staff must do. This increase, however, as noted in the Approved Budget document, provides for proper staffing for today's ICANN "business as usual." It does not provide for any of the additional positions that will result from the current reform process, including the Ombudsman, the Manager of Public Participation, and all the support staff envisioned for the SO Councils, the new Advisory Committees (the current budget does provide for support staff for the SAC, but not for the ALAC, the RSSAC, or the TAC), the Policy Development Process, or the Nominating Committee – all of which will need staff support to be effective. Neither does it provide for any permanent funding for a GAC Secretariat, although the GAC may provide this itself. And of course, additional staff positions bring along increased overhead, demands for administrative support, equipment and communications support, and travel expenses, all of which would increase further to the extent that ICANN's operations become ever more internationally based.
The ERC has not costed all of this out in detail at this point. However, using conservative estimates of the likely salary, benefits, insurance, administrative overhead, travel, etc. for the 7-10 additional persons that seem likely to be required by the current reform efforts, an additional budget increment over the current budget of between US$1 million and US$1.3 million provides an approximate estimate of what will be required. Some of this may be accomplished with external consultants rather than full-time internal staff, so these estimates are necessarily imprecise. The final actual numbers would be contingent on a detailed analysis, and the extent to which various tasks can be combined and performed by a single individual.
In the 2002-2003 budget, the revenues derived from variable registry/registrar fees from gTLDs and ccTLDs under contract are budgeted at US$3.872 million. A useful metric for comparison purposes is to divide this number by the total number of domain names assumed by the budget; this produces a figure of 12.69 cents per domain name for this portion of the budget. An increase of the higher estimate of US$1.3 million would increase this metric by about one-third, or by 4.23 cents, to a total of 16.92 cents per domain name. This calculation excludes the possible effects of (a) any increase in voluntary funding from ccTLDs, (b) new ccTLDs coming under contract, or (c) the addition of new gTLDs. Neither does it consider the effect on per domain name costs of overall growth in domain name registrations, which would have the effect of lowering the per domain name cost.
These figures lie within the current scope of ICANN's existing agreements with registries and registrars, but pursuant to those agreements, could require budget approval each year by registrars that in the aggregate represent two-thirds of total gTLD domain names. This estimate also does not provide for any increase in reserves, the lack of which represents a substantial exposure for ICANN under the circumstances. Steady building of reserves could add funding requirements that could amount to as much as another 3 to 4 cents per domain name, using this same metric.
This analysis, while still approximate, does provide a general perspective on the budgetary implications of the current reform efforts. We invite comments on this analysis.
To actually implement these various reforms will require what will essentially be a rewriting of ICANN's bylaws. We intend to include in our "final" recommendations a proposed new set of ICANN bylaws reflecting our recommendations, and are now considering how to accomplish that within the relevant timeframe and existing resources.
Assuming that the ICANN Board adopts a final reform plan at its meeting in Shanghai, there will necessarily be a transition from the current structure. We offer the following initial thoughts on that transition process. We welcome comments and suggestions, especially on the practical aspects of the transition.
1. The most critical element of the transition will be the effective implementation of a mechanism that adequately funds staff support for the various SOs and ACs. The following assumes that can be accomplished shortly after the Shanghai meeting. Once that is done, the process of hiring the necessary staff will begin; the goal should be to have as many of the new staff hired as possible by the time of the March 2003 ICANN meeting.
2. There will necessarily be a period of time before the newly constituted ICANN Board can be seated. Assuming final action on reform by the Board in Shanghai in late October, it seems entirely possible that selection of the new ICANN Board could take a period of months. Some bodies (like the ASO and the GNSO) will undoubtedly be able to function quickly and select persons to the Board seats for which they are responsible, but other selections (such as those from the Nominating Committee) are likely to take longer to accomplish. The next public Board meeting following Shanghai will likely be in March of 2003, or some four months after Shanghai. It seems reasonable to assume that a newly constituted ICANN Board could be ready to be seated by that time, and thus a transition structure is (hopefully) necessary only until that time. Nonetheless, any transition structure should be durable enough to last longer if necessary.
The current ICANN Board consists of 18 persons selected by various constituencies, and the CEO ex officio. Of the 18, nine are designated "At Large" directors, and the terms of those directors expire at the end of the annual meeting in 2002. While the date of the official annual meeting has not yet been set, the terms of those directors will clearly expire prior to the March meeting in 2003. This leaves nine directors – three each selected by the DNSO, the ASO, and the PSO. There is currently one vacancy from that group (the seat formerly held by Phil Davidson, selected by the PSO). In addition, the ASO has selected a new director for a term to begin at the end of this year's annual meeting (Mouhamet Diop), and the DNSO is currently in the process of selecting a person for the expiring seat of Alejandro Pisanty, also for a term to begin at the end of this year's annual meeting. Thus, as it currently stands, there will be eight (or nine, if the PSO should hold elections to fill its vacant seat) ICANN directors whose terms would, absent reform, run at least through 2003.
While there is any number of possible transition mechanisms, we believe that the principal objective should be continuing stability during this transition. To that end, we plan to recommend to the ICANN Board that those members of the current Board whose terms would ordinarily continue through next year should remain on the Board until the end of the March meeting in 2003 (or longer, if that should prove necessary to select the reformed Board). At that time, unless they have been selected to the reformed ICANN Board by one of the selecting bodies, they would retire from the ICANN Board. In addition, we plan to recommend that the Board select six (or five, if the PSO has by then selected a third director) of the directors whose terms are due to expire this year to continue until a reformed ICANN Board is selected, at which time they too, unless selected to the reformed ICANN Board, would retire. Since a certain number of current Board members have indicated, publicly and privately, that they do not intend to continue on the Board once their term expires, it may be that this selection process could become simple through the individual decisions of these Board members. Other adjustments may also be necessary to accomplish a transition Board of the right size commensurate with the intent of the final reform decisions.
3. Several of the non-voting liaisons to the ICANN Board (from the GAC, RSSAC, SAC, IAB/IETF) are from existing entities; those entities should select their liaison as soon as possible following the Shanghai meeting, but in any event prior to the March 2003 ICANN meeting. The liaisons from the TAC and the ALAC are discussed below, in connection with the need to create these new organizations. In addition, those organizations that provide a delegate to the NomCom should do so as soon as possible following the Shanghai meeting.
4. The ASO requires no substantive changes. It should be able to function immediately. Since the ASO will select two members of the ICANN Board and one delegate to the NomCom, it should do so as promptly as possible following Board action in Shanghai.
5. The GNSO will initially consist of six existing constituencies, so it should be able to function promptly after the adoption of new Bylaws. Since it will select two members of the ICANN Board, it should do so as promptly as possible following Board action in Shanghai. Other steps it must take are to designate a manager/moderator of the GA mailing list for as long as the GNSO is responsible for its operation, and to implement the PDP as mandated by the new Bylaws. The relevant GNSO constituencies should select their delegates to the NomCom as soon as possible following the Shanghai meeting.
6. ccNSO transition details must await further developments.
7. Assuming the Board creates an ALAC, we will recommend the creation of an Interim ALAC consisting of the members of the ALAC Assistance Group and such other persons as the Board deems appropriate to encourage the prompt implementation of the ALAC structure recommended. The Interim ALAC should designate the ALAC liaison to the ICANN Board until such time as the final ALAC structure is implemented. The Interim ALAC should also select the delegates to the NomCom for which it is responsible as soon as possible following its appointment.
8. The entities that make up the TAC should be able to form the TAC and select its initial Board liaison and NomCom delegate prior to the March 2003 meeting of ICANN.
We reiterate again our call for comments and suggestions. The purpose of these Interim Implementation Reports is to share our tentative conclusions with the rest of the community, so that we can receive feedback and take that reaction into effect in reaching our final conclusions. It should be clear by now that comments and suggestions are carefully considered and frequently adopted, and we encourage all members of the community to offer their views. In this Report, we have tried to set forth both our conclusions and the reasoning behind them, and we urge all members of the community to offer your reactions, pro or con, and any alternative suggestions.
Committee on ICANN Evolution and Reform
2 September 2002
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.