DRAFT Names Council reply to Committee on ICANN Evolution and Reform – Recommendations for the Evolution and Reform of ICANN v1

DRAFT Names Council reply to Committee on ICANN Evolution and Reform – Recommendations for the Evolution and Reform of ICANN June 2002 v1

Introduction

This response from the Names Council follows extensive debate since March 2002 and is based on a set of 30 recommendations[1] produced by the Council in consultation with the general assembly to date.

Underlying all of them are recommendations on funding and staff support for policy development bodies. Unless ICANN is allowed the budget it needs, it will perform poorly. Unless that funding allows for staff support to policy development, policy development will be poor. Other changes will be insufficient to make a difference without action on these two enabling conditions of success.

I. SCOPE AND MISSION

Q1. The committee supports the ICANN staff paper on mission. In broad terms the NC agrees.

(r1) The Names Council proposes the following re-statement of ICANN's mission:

"ICANN's mission is to co-ordinate 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[2]."

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.

II BOARD COMPOSITION

Q2. The Committee proposes one voting board seat for the ICANN CEO. The NC agrees.

The Committee proposes 7 voting board seats for the chairs of the policy development and advisory bodies. The NC disagrees for four reasons:

a) accountability. (r29) Policy development bodies should elect an equal number of Board members.

b) time. The chairman of a policy development body, unless full time, cannot perform effectively as both chair and a board member. This is especially so for the proposed GNSO as the chair is proposed to be both the steering committee and the GA chair.

c) inflexibility. Linking board seats to the current set of advisory bodies would prohibit the establishment of future advisory bodies.

d) government. The GAC cannot be treated in this way. Governments speak for themselves.

Q3. The committee proposes 5-11 board members from a nominating committee[3]. The NC partially agrees.

(r30) A nominating committee[4] should select a quota of Board seats which will be less than or equal in number to those elected from the policy development bodies.

III. BOARD SELECTION PROCESS

Q4. The committee proposes criteria for Board members selected by a nominating committee: “broad functional diversity in the areas of expertise relevant to ICANN's mission; geographic and cultural diversity; the capacity to understand the global impact of ICANN's actions; and the ability to contribute to the overall credibility of the ICANN Board”. … “integrity, objectivity, intelligence, evident capacity for thoughtful group decision-making, and evident willingness to fulfil the responsibilities that are accepted by a Board member”. The NC agrees.

IV. NOMINATING COMMITTEE COMPOSITION AND RESPONSIBILITY

Q5. The committee seeks proposals on composition. The NC proposes a 15 member nominating committee.

Five (5) Providers

Five (5) Users

Five (5) At-large, government or equivalent representatives

The Provider sector should ideally be parties that have contractual relationships with ICANN to provide DNS and Numbering services such as Registrars, generic TLD Registries, registries, RIRs, Root Server Operators, etc, whereas the User sector would ideally encompass a broad spectrum of commercial, non-commercial and individual viewpoints.

Q6. The committee asks if board directors selected by the nominating committee should be ratified by the board. The NC disagrees. This opens up to potential abuse and could create an unhealthy circle of self-perpetuation.

V. POLICY DEVELOPMENT STRUCTURE

The key failure in policy development to date is a result of lack of funding to provide staff support for policy development. 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. Other changes will be insufficient to make a difference without action on these two enabling conditions of success.

(r11) 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.

Q7i. generic names. The committee proposes a structure for a generic name supporting organisation (GNSO). The NC partially agrees.

(r13) Create a new policy development body for gTLDs. This would need means of collaborative decision making with the ccTLD policy development body on relevant areas of policy.

(r17) 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.

(r18) 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.

GNSO steering committee

Q7.ii The committee propose that a nominating committee appoint the chair and some steering committee members. The NC disagrees.

(r19) The stakeholders in the gTLD policy development body should elect representatives to a Council or similar body.

The NC believes the steering committees should select their own chairs.

Q8. Country code support organisation

The committee calls for a separate country code SO. The NC agrees.

(r12) 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.

Q9. Technical advisory committee

The committee supports a technical advisory committee. The NC disagrees.

(r14) There should be separate policy development bodies for addressing and protocols. There needs to be an effective mechanism for cross-policy development body consultation.

(r26) 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.

VI. POLICY DEVELOPMENT PROCESS.

The Committee ask for proposals on procedures and time limits. The NC strongly endorses a bottom-up process.

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

(r10) 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.

(r20) 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.

(r21) 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.

(r22) extremis.[8] 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.

(r23) general assembly[9]. 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.

(r24) 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.

VII. PUBLIC OVERSIGHT AND PARTICIPATION

The Committee recommends arbitration for alleged by-law violations and the office of an ombudsman for day to day complaints. The NC agrees.

(r16) Create the office of a professional ombudsman.

VIII. FUNDING

Q11. The committee lists this as item VIII. The NC believes it should be item I. It is the first step of the critical path to success. It determines success or failure. There is no choice on source of funding. The fees paid by gTLD registrants are the core.

(r5) 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.

(r6) secondary sources. Secondary sources should include the ccTLDs and RIRs, but should not include governments. ICANN’s budget should be conservative and reflect what is achievable not desirable from secondary sources.

(r7) supplementary sources. Supplementary sources could be found from sources such as secretariat service fees to the GAC.

Q12. Budget process.

The committee seeks comments. The ICANN budget approval process should be independent of those who administer ICANN funding.

IX. GOVERNMENT

The committee proposes a seat on the board for the GAC chair. The NC disagrees.

The GAC cannot be treated in this way. Governments speak for themselves.

(r25) There should be a Government advisory body. There needs to be an improved flow of communication and better co-ordination with the ICANN policy development bodies.

(r27) The government advisory body chair or designee should provide a permanent liaison role to the ICANN Board.

X. OUTSIDE RESOURCES

Q14. The committee recommends use of external expertise. The NC agrees.

Indeed the NC already practices this in relevant working groups and would like to go further.

XI. INTERNAL ICANN STRUCTURE

Q15. The committee proposes an internal divide within ICANN of the policy and operational functions. The NC agrees.

(r2) 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.

(r8) budgeting. Further to recommendation 2, ICANN budgeting should reflect a delineated structure.

XII. TRANSITION

The NC supports the gradual evolution of ICANN. END.

[1] Numbers in parentheses refer to NC recommendation number from version 12.

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

[3] Terminology. Nominating committee is the wrong word. What is described is a selection committee but for clarity we do not change the terminology here.

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

[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 gTLD registry constituency did not agree to the wording of the last phrase of this statement

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

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