[council] NC conclusions on structure - draft version 5
Names council members
Just a reminder that reactions to the text below would be
welcome in advance of our next call.
Philip
----- Original Message -----
From: Philip
Sheppard
To: NC
(list)
Sent: 11 April 2002 12:19
Subject: [council] NC conclusions on structure - draft version
5 Further to the second NC call and e-mail
correspondence please find the latest version of our draft conclusions in
progress. I have added in proposed the J Scott/Cary wording on mission as a
new recommendation - as it is a change from the re-statement of the ICANN staff
wording in previous versions. Note also the preamble and wording of
recommendation 3 has changed. I have intentionally
kept the note short and just tried to capture the recommendations. Constituency
papers and the minutes will be adequate to capture the reasoning behind these
recommendations. Philip
--------------------------
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:
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). 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: "ICANN's mission is to
coordinate technical and policy functions of the domain name system in order to
promote a safe, stable and commercially viable domain name system, promote
competition, and achieve broad representation of global Internet communities,
all for the benefit of the public."
The Names Council specified the following
existing functions of ICANN where the NC would like ICANN to
do better in carrying them out: - ccTLD administrative functions
- root server administration
- Registry and Registrar contract enforcement with
respect to intellectual property and other existing conditions.
Recommendation 2 - structure. Create
clearly delineated divisions within ICANN responsible for the administration of
its operational and policy functions. This would establish separate staff
functions for policy and operational functions.
The Names Council felt that the greatest
potential for mission creep lay in the areas of additional security and
additional consumer protection. 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.
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 agreement 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 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 charitable
donations, conference fees, and secretariat service fees to the
GAC.
Recommendation 8 - budgeting. Further to
recommendation 2, ICANN budgeting should reflect a delineated structure and be
based on certainty. As much as possible ICANN should identify services that it
can charge for, leaving funds from contractual agreements to cover everything
else.
Advisory Bodies
Recommendation 9 - policy making. ICANN
policy advisory bodies should formulate policy recommendations based on a
bottom-up, consensus process of the affected
stakeholders.
Recommendation 10 - impact. The policy
recommendations from such policy advisory bodies should be ordinarily binding on
the ICANN Board 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 and
their effectiveness improved 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
supporting organisation for the ccTLDs. |