Further to yesterday's (May 14) NC call I attach version 10 of the interim NC recommendations on ICANN evolution. Recommendations 1-25 have now been adopted.

In light of the tight timetable in front of us and the fact that we did not cover the last item of yesterday's agenda I have drafted some further items for debate by e-mail and subsequent adoption/amendment by e-mail or at the latest the NC call of May 29. These are based on the questions asked in recent ICANN evaluation committee working papers and in proposals in the constituency positions that have been forwarded to the NC to date.

 

They are a set of recommendations on who should elect the board and a subsequent set of three non-exhaustive options for how many seats which flow from these recommendations. I have tried to separate out areas of principle from the end game of board seats. I look forward to the debate.

Philip

NC Chair

 

Interim Names Council recommendations on ICANN Evolution May 2002 v10

Discussion items

Introduction

This document contains interim recommendations from the Names Council on issues of high-level principle as a contribution to the 2002 discussions on ICANN evolution. The Names Council will continue to add recommendations as the debate continues and will also add detail (especially on policy development and board composition) to some of its earlier recommendations as time allows. The recommendations are shared by all NC constituencies unless where indicated in the annotated footnotes.

 

These recommendations evolved during a series of telephone conferences and exchanges of e-mail beginning March 2002 and going forward. These conferences were held jointly with the chair and alternate chair of the General Assembly and included sessions with ICANN CEO, staff and advisors and the chairman of the ICANN evolution committee.

 

Scope and mission of ICANN

In broad terms the Names Council (NC) agreed with the factual description of ICANN's functions listed in "What ICANN Does" at: http://www.icann.org/general/toward-mission-statement-07mar02.htm which (in summary) cover:

1. General operational functions (such as IP address allocation, maintaining the DNS root zone file).
2. gTLD administrative functions (such as registrar accreditation, supervising the Uniform Dispute Resolution Policy, determining the process for new gTLDs).
3. ccTLD administrative functions (such as updating the IANA database entries concerning ccTLD Managers, or requests for delegation and re-delegation).
4. Policy coordination for infrastructure security.
5. Policy-related functions including:
  5.1. IP address and AS number allocation,

  5.2  ccTLD global policy coordination,

  5.3. Protocol numbering via the IANA registries,

  5.4 gTLD registry-level policies.

Recommendation 1 - mission. The Names Council proposes the following re-statement of ICANN's mission:

"ICANN's mission is to coordinate technical and policy functions of the domain name system in order to promote a stable, secure and commercially viable domain name system, promote competition in key aspects of the DNS, and achieve broad representation of global Internet communities, all for the benefit of the users of the global Internet[1]."

The Names Council specified the following existing functions of ICANN where the NC notes that improvements and enhancements in delivery of services or improvements in relationships are needed:

- IANA administrative function for ccTLDs

- root server administration

- gTLD Registry and Registrar contract enforcement e.g. escrow,  the UDRP and WhoIs.

 

Recommendation 2 - structure. Create clearly delineated divisions within and under ICANN responsible for the administration of  operational and policy functions. This would establish separate staff functions for policy and  operational functions but maintain a clear authority within ICANN management for all such functions.

 

 

Some of the Names Council  noted that the greatest potential for mission creep lay in the areas of additional security and additional consumer protection. The Names Council recognised that the functions expected of ICANN as viewed today may, be different in a changed world of tomorrow. That future world may dictate that ICANN's functions are more, or are fewer, than those today. Focus of the core functions of the moment will be a key to success.

Recommendation 3 - functions.  ICANN's functions should not be extended at this time beyond what is outlined in the note "What ICANN Does", subject to the distinct roles of ICANN and IANA being maintained.

 

Funding ICANN

Short-term

The NC believes that the debate over the longer term funding of ICANN should not be distracted by any short term funding problem.

Recommendation 4 - short-term funding.  The NC urges the existing funders to reach at least interim agreements quickly to avoid any short fall in ICANN's existing budget.

 

Longer term

Recommendation 5 - core funding. Funding could potentially come from more than one source but the bulk of funds should ultimately derive from the revenues of gTLD Registrants' fees and be administered via Registrars and/or Registries.

 

Recommendation 6 - secondary sources.  Secondary sources should include the ccTLDs and RIRs,  but should not include governments. 

(Consideration should be given to the relevance of ccTLDs which are marketed in non-geographic ways to recommendations 5 and 6).

 

Recommendation 7 - supplementary sources. Supplementary sources could be found from sources such as secretariat service fees to the GAC. 

 

Recommendation 8 - budgeting. Further to recommendation 2, ICANN budgeting should reflect a delineated structure.  

 

Policy Development bodies[2]

Recommendation 9 - policy making. ICANN policy development bodies should formulate policy recommendations based on a bottom-up, consensus process of all stakeholders[3]. There must be a clear process and that process should be managed by the ICANN Board.

 

Recommendation 10 - impact. The policy recommendations from such policy development bodies should be ordinarily binding on the ICANN Board and ICANN entities, but with rejection possible subject to a 2/3 Board majority.

 

Recommendation 11 - staff support.  ICANN’s policy development bodies should be made more effective by the provision of full-time staff to support all aspects of policy making including a co-ordinating secretariat and staff support to policy-making task forces and similar groups.

 

Recommendation 12 - ccTLDs. Create a new policy development body for the ccTLDs. This would need means of collaborative decision making with the gTLD policy development body on relevant areas of policy.

 

Recommendation 13 - gTLDs:  Create a new policy development body for gTLDs[4]. This would need means of collaborative decision making with the ccTLD policy development body on relevant areas of policy.

 

 

Board composition and size

 

Recommendation 14 – Board elections. The policy development bodies should elect or select a number of voting Board members.

 

Recommendation 15 – Board size. The Board should be set at a size that balances two goals – large enough to be representative, small enough to be functional[5].

 

 

Transparency

 

Recommendation 16 – independent review. Create a committee for independent review of appealed decisions of the ICANN Board.

 

Recommendation 17 – ombudsman.  Create the office of a professional ombudsman.

 

 

Policy development process gTLDs

 

Recommendation 18 – who?[6]  The stakeholders in the gTLD policy development body should be at a minimum the following constituencies: Business users, intellectual property interests, gTLD Registries, Registrars, non-commercial organisations, Internet service and connectivity providers.

 

Recommendation 19 - Other stakeholders. Other stakeholders, such as individual domain name holders, could be added subject to the requirements of the Names Council “Criteria for establishing new DNSO constituencies”  as set out in the NC rules of procedure at www.dnso.org.

 

Recommendation 20 - structure  The stakeholders in the gTLD policy development body should elect representatives to a Council or similar body.

 

Recommendation 21 – working practice The gTLD policy development body should operate by establishing small, specialist working groups with realistic timelines. These working groups may vary in size and composition depending on the issue and could include outside expertise. The working groups would consult with constituencies/stakeholders and then make final recommendations to the Council or similar body of the gTLD policy development body.

 

Recommendation 22 - Board liaison To ensure Board level engagement in the policy development process one or more Board members should be assigned as a liaison to each policy development body.

 

Recommendation 23 – extremis  Ordinarily all policy development should be via the policy development bodies and subject to recommendation 10 in terms of obligation on the Board. In extremis when externalities dictate, the Board should be able to direct ICANN staff to draft a policy for fast-track consideration (not to exceed 60 days) by the policy development body.

 

Recommendation 24 – general assembly. The gTLD policy development body should have a general assembly whose prime role is to provide a forum for broad inter-constituency exchange. Consequently, membership should be limited to the agreed stakeholders who are represented in the policy development body.

 

Recommendation 25 – public consultation  There should be public consultation on proposed new policy within strict time limits, typically not to exceed 30 days.  Such consultation should serve as the channel by which individuals and parties not fitting into the stakeholders/ constituency scheme participate in policy-making. Fora of self-declared interested parties should be specifically requested for input during such consultation. The necessary financial and human resources will need to be made available for public consultation.

 

 

Items for debate by e-mail and adoption/amendment at the NC call May 29

These are based on the questions asked in recent ICANN evaluation committee working papers and in proposals in the constituency positions that have been forwarded to the NC to date. {Items in these brackets are key options for debate}

 

Policy development bodies (II)

Recommendation 26 – technical bodies.  There should be separate policy development bodies for addressing and protocols.

 

Advisory Bodies

Recommendation 27 – government. There should be a Government advisory body.

 

Recommendation 28 – technical. There should be a technical advisory body, along the lines specified in the Lynn proposal.

 

Board composition and size (II)

Recommendation 29 – Board seats for advisory bodies. There should be one {non-voting ?} board seat for i) the government and ii) the technical advisory bodies. {Note – this has implications for recommendation 33 option 2}

 

Recommendation 30 – Board members from policy bodies. Further to recommendation 14, the four policy development bodies (gTLds, ccTLDs, addressing, protocols) should elect an {equal} number of Board members. Note this has implications for recommendation 33 – option3}

 

Recommendation 31 – Board members at-large. A nominating committee should select a quota of Board seats {which will be in equal number to those elected from the policy development bodies}.

 

Recommendation 32 – nominating committee. A nominating committee should be established to select a certain quota of Board seats. That committee should comprise appointed representatives of the stakeholders identified within the gTLD and ccTLD policy development bodies, plus individuals who could represent at-large interests (such as former national leaders, senior figures from international organisations, a nominee of the GAC). The nominating committee should carry out its work according to a charter that stresses the need to select professional and experienced individuals, and to avoid domination of the Board by a particular geographic region or industry sector.

 

 

 

Recommendation 33 -  board numbers options

Further to recommendations 15, 29-32 the following compositions are proposed as options for the composition of the Board:

Option 1

gTLD policy development body                       2 seats

ccTLD policy development body         2 seats

addressing policy development body    2 seats

protocols policy development body      2 seats

                                                           8 seats

Nominating committee                         8 seats

ICANN CEO                                     1 seat

Sub-total                                             17 seats

Government, technical advisory                       2 seats (non-voting)

                                                           19 seats

 

 

Option 2

gTLD policy development body                       3 seats

ccTLD policy development body         3 seats

addressing policy development body    3 seats

protocols policy development body      3 seats

                                                           12 seats

Nominating committee                         5 seats

ICANN CEO                                     1 seat

Government                                        1 seat

Sub-total                                             19 seats

 

Option 3

gTLD policy development body                       4 seats*

ccTLD policy development body         2 seats

addressing policy development body    1 seats

protocols policy development body      1 seats

                                                           8 seats

Nominating committee                         8 seats

ICANN CEO                                     1 seat

Sub-total                                             17 seats

Government, technical advisory                       2 seats (non-voting)

                                                           19 seats

 

* The gTLD policy development is given additional seats because the nature and breadth of its representation and stakeholders is a level of magnitude above that of the other policy development bodies.