Interim Names Council recommendations on ICANN Evolution May 2002 v12

 

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

 

Underlying all of them are recommendations 5 (funding) and 11(staff support for policy development bodies).  Unless ICANN is allowed to adopt the budget it needs, it will perform poorly. Unless that funding allows for staff support to policy development, policy development will be poor. All the rest will be irrelevant change without action on these two enabling conditions of success.

 

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.

 

Recommendation 14 – technical bodies.  There should be separate policy development bodies for addressing and protocols. There needs to be an effective mechanism for cross-policy development body consultation.

 

 

Transparency

 

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

 

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

 

 

Policy development process gTLDs

 

Recommendation 17 – who?[5]  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 18 - 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[6]”  as set out in the NC rules of procedure at www.dnso.org.

 

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

 

Recommendation 20 – 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 21 - 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 22 – extremis[7]  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 23 – general assembly[8]. 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 24 – 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.

 

 

Advisory Bodies

 

Recommendation 25 – government. There should be a Government advisory body. There needs to be an improved flow of communication and better coordination with the ICANN policy development bodies.

 

Recommendation 26 – technical. There should be ad hoc technical advisory committees providing neutral technical advice and convened by the ICANN Board. There is no need for a standing technical advisory body with Board representation. Linking board seats to the current set of advisory bodies would prohibit the establishment of future advisory bodies.

 

Board composition and size

 

Recommendation 27 – Board liaison for government. The government advisory body chair or designee should provide a permanent liaison role to the ICANN Board.

 

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

 

Recommendation 29 – Board members from policy bodies. The four policy development bodies (gTLds, ccTLDs, addressing, protocols) should elect an equal number of Board members.

 

Recommendation 30 – Board members at-large. A nominating committee[10] should select a quota of Board seats which will be less than or equal in number to those elected from the policy development bodies.

 

 

 

 

 


[1] The gTLD registry constituency did not agree to the wording of the last phrase of this mission statement

[2] The IP constituency prefers the term issue identification bodies as outlined in the constituency’s position paper.

[3] The gTLD registry constituency did not agree to the wording of the last phrase of this statement

[4] The non-commercial constituency did not agree to this phrasing wishing instead to add detail about the participants in the gTLD policy development body. This debate is planned later in May 2002.

[5] The gTLD constituency support separate policy development bodies for suppliers and users. The GA chair adds individual domain name holders to this list.

[6] The final decision rests, as in the current by-laws, with the Board. DNSO criteria are a decision-making tool.

[7] The GA chair favours additional safeguards on fast-track policies.

[8] The GA chair favours open membership for the GA.

[9] A representative of the Registrars wanted more substance to be added to this recommendation. That debate is planned later in May 2002.

[10] The ISPCP do not support a nominating committee. The GA chair prefers direct election for at-large.