DRAFT version 5
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:
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 and procedures for any new gTLDs etc.
3. ccTLD administrative functions (such as updating the IANA database entries concerning ccTLD Managers,
or requests for delegation and redelegation).
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:
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 p ublic."
Names Council specified the following existing functions of
ICANN where the NC
like ICANN to do better in carrying them out:notes that
improvements and enhancements in delivery of services or improvements
in relationships are needed:
- ccTLD administrative functions
- root server administration
- Registry and Registrar contract enforcement with respect to escrow, intellectual property and other existing conditions.
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.
tThe Names Council felt
noted that the greatest potential for mission creep
lay in the areas of additional security and additional consumer
protection. [question:I saw no indication of
mission creep by ICANN in the approach they took to security. Perhaps
some others can point me to the examples.] The creation of
infrastructure for at-large membership was also mentioned; however,
it was also argued that this topic should not be discussed alongside
ICANN's functions. [this is unclear to
me? can we clarify what is meant by this statement?]
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" .
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.
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).
7 - supplementary sources.
Supplementary sources could be found from sources such as charitable
donations, conference fees, and secretariat service fees to the
Recommendation 7: While some have suggested foundation funding, there is no indication that this is a stable or timely funding mechanism. GAC could provide funding for their own secretariat. Other governmental funding sources are unlikely
8 - budgeting. Further
to recommendation 2, ICANN budgeting should reflect a delineated
structure and be based on certainty.
much as possible ICANN should identify services that it can charge
for, leaving funds from contractual agreements to cover everything
Advisory Bodies and Policy Development Entities/organizations
9 - policy making.
ICANN policy advisory bodies should formulate policy recommendations
based on a bottom-up, consensus process of
Recommendation 10 - impact. The policy recommendations from such policy advisory 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. The DNSO and the other policy advisory bodies should remain essentially intact in function, and their effectiveness and processes be improved, including 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. [Comment: The DNSO should consider the forum concept objectively in order to make an informed decision about the best way to develop effective policy].
Recommendation 12 - ccTLDs. Support the creation ofCreate a new supporting organisationorganization/entity for the ccTLDs with agreed to relationships to support collaborative policy making with the gTLD equivalent, on areas of policy which are of mutual concerns [e.g. international domain names, etc.].
Recommendation 13: gTLDS. Maintain a supporting or equivalent organization in the gTLD domain names environment. Liasion with ccTLD entity and other policy entities/organizations; advisory bodies, etc.