DRAFT Interim Names Council recommendations on ICANN Evolution May 2002 v9

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" .

 

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

Recommendation 9 - policy making. ICANN policy development bodies should formulate policy recommendations based on a bottom-up, consensus process of all stakeholders[2]. 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[3]. 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[4].

 

 

Transparency

 

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

 

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

 

 

Policy development process gTLDs

Draft recommendations based on NC discussion 2 May ; for discussion now by e-mail and adoption/amendment at the next call.

 

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

 

Recommendation 19 - Other stakeholders. Other stakeholders 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 http://www.dnso.org/ . The idea of fora of self-declared stakeholders with only an advisory role is rejected.

 

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

 

Recommendation 21 – public consultation  There should be public consultation on proposed new policy within strict time limits. The burden of public consultation as an integral part of early, detailed policy discussion should be avoided.

 

Recommendation 22 – working practise The gTLD policy development body should operate by establishing small, specialist working groups where expertise and representation are balanced.  These working groups (similar to the existing DNSO task forces) may vary in size and composition depending on the issue. They would make recommendations to the Council or similar body of the gTLD policy development body.

 

Recommendation 23 - Board engagement To ensure Board level engagement in the policy development process one Board member should be a non-voting member of each such working group.

 

Recommendation 24 – 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 adopt an interim policy also by 2/3 majority, pending a final policy, developed through the policy development bodies.