<html>
Dear Harold,<br>
I certainly join and support YJ's and Kathryn's concerns.<br>
But I think we cannot avoid the entire conception of the ICANN to be
reviewed if we want it to survive.<br><br>
1. we first have to decide what is the priority: the ICANN or the network
(and its participants).<br>
2. where the investment is. By the USG, by the various Govs and local
communities, by the users (probably around $ 1.000.000.000.000 in PCs,
software, learning).<br><br>
From this we have four areas to consider:<br><br>
1. numbers. There are several physical numbering plans. IP must be
coordinated with X.121, Telephone, etc... We need a concertation
committee associating them all. ITU/T seems appropriate to host it. No
one must rule: rotating chair, no need to be an ITU/T Member.<br><br>
2. name space management : the Internet network is one of the name spaces
of the TCP/IP world system that participants jointly invested in (and
served as a market by ISPs, ASPs, Registries). This name space management
is shared among ICANN (legacy), USG (gov/mil/edu/us), ccTLD Alliance
(ccNET), ".eu" for the EEC space, New.net, Open Systems,
Real Names, AOL, MS, Verisign, ITU/T (telephone names), and all the large
naming/numbering system as ISSN, ISBN, etc.. We need a concertation
committee associating them all. No one must rule: rotating chair, no need
to be an ITU/T Member.<br><br>
3. Protocol issues. This has not yet taken off. But it may be the leading
issue in a near future when the system architecture will start being
questioned. The same solution should be expected.<br><br>
4. Mission creep. The ICANN has shown that the gouvernance involves many,
many things. Some are of ICANN's concern only, some are general to all
the name spaces. Some are general interest. What we need is an Internet
Campus where they may meet, debate, cross-fertilize etc... Independently.
This can be ITU/T sponsored in Geneva, UN sponsored in New York, ICANN
sponsored in MdR. Disney sponsored in France, Marriott sponsored in
Hawaii The only thing we know is that it will never be ICANN or USG
controlled or directed. <br><br>
Internet is like the sea. Who knows where are the roots or the springs of
the seas; who is the master of the oceans? All those who said "I
know" or "its me" only shown themselves as pompous fools.
No need fro the NC to be considered that way.<br><br>
But the first thing we have to keep in mind is "mani pulite".
There are rumors and questions enough around IP and name Registries for
the NC and PSO to address first this either ethic or PR problem.
<br><br>
Jefsey Morfin<br><br>
On 03:01 23/04/02, KathrynKL@aol.com said:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Harold:
<br><br>
I join YJ in expressing my deep concern over the broad language of the
Names Council draft which authorizes, legitimizes and expands ICANN's
policy making authority. ICANN is not a policy-making body, and
does not have the resources to do this job well or fairly.
<br><br>
I would urge you to fight for, and if necessary lead the Noncommercial
Constituency, <br>
in dissenting from any Names Council document which confers policy making
authority -- in any type of broad and ambiguous phrases -- upon
ICANN. <br><br>
ICANN does not currently have any unconditional or unbridled power to
make DNS policy, IP address policy or protocol policy. Instead, it
serves as an international coordinator of policies made by regional
groups for addresses and protocols, and should serve the same limited
role for DNS. <br><br>
The NCC has a solid history of fighting ICANN expansion of its extremely
limited policy authority. To continue this tradition, I think a
number of changes must be made to the Scope and mission statements of the
Names Council draft, including but not limited to: <br><br>
1) "policy coordination for infrastructure security"
- must be much more narrowly defined, perhaps to:
"technical security measures as necessary to maintain those
technical aspects of the DNS and address infrastructure that ICANN
directs" <br><br>
2) "Policy-related functions, including: <br>
IP address and AS number
allocation" ==> far too broad, perhaps to ==>
"limited authority to assist regional IP organizations in their work
and in international coordination of their efforts." <br><br>
"ccTLD global policy
coordination" ==> again, far too broad. ccTLD
Names Council representatives should have some deep concerns about this
language and offer changes to dramatically limit it. Please support
their efforts. <br><br>
"Protocol numbering via the IANA
registries," ==> again, far too broad. The PSO
advises ICANN, but I do not know that ICANN currently has any authority
to dictate protocols and standards of the Internet. ==>
please seek deletion of this phrase. <br><br>
** "gTLD registry-level policies
==> NO! A thousand times No (to quote Shakespeare, I think)
==> many of us have fought for so long to give registries as
much independence as possible. We want the market, not ICANN, to
direct registries. Please fight for much, much more limited
language here, e.g. ==> "extremely limited authority to
work with gTLD registry-level policies as necessary to maintain the
technical stability of the DNS root." <br><br>
From Mission 1, please remove all mention
of ICANN's policy function. This recommendation alone endorses a
huge and dramatic increase in ICANN's authority. I think the NCC
should support only reflection of ICANN's mission to coordinate
**technical** functions. <br><br>
I would also ask the Names Council to
include a new line in the ICANN mission statement: "To date,
ICANN has engaged in policy making efforts including the creation of a
Uniform Dispute Resolution Process and Procedure that deeply divided the
Internet community and alienated many of its members. ICANN should
not view its mandate as continuing to expand domain name policy
authority, particularly in the area of disputes. It should be a
matter of ICANN scope and mission to leave domain name policy to national
governments, national courts, and the traditional processes and
institutions of international law and policy." <br><br>
Beyond that, things on their face look
OK. If the policy making function of ICANN is dramatically narrowed
as discussed above, the structural recommendations, etc., should be
OK. If the Scope and Mission of ICANN is not narrowed, then these
later structural and implementation sections will be an unmitigated
disaster. <br><br>
Good luck, Harold. <br>
Kathryn Kleiman <br>
ACM-IGP <br>
<br>
Harold Feld circulated: <br><br>
<blockquote type=cite class=cite cite>DRAFT version 6 <br>
Highlighted items are under review. <br>
Scope and mission of ICANN <br>
In broad terms the Names Council (NC) agreed with the factual <br>
description of ICANN's functions listed in "What ICANN Does"
at: <br>
<a href="http://www.icann.org/general/toward-mission-statement-07mar02.htm" eudora="autourl">http://www.icann.org/general/toward-mission-statement-07mar02.htm</a>
which <br>
(in summary) cover: <br>
1. General operational functions (such as IP address allocation, <br>
maintaining the DNS root zone file). <br>
2. gTLD administrative functions (such as registrar accreditation, <br>
supervising the Uniform Dispute Resolution Policy, determining the <br>
process for new gTLDs). <br>
3. ccTLD administrative functions (such as updating the IANA database <br>
entries concerning ccTLD Managers, or requests for delegation and <br>
re-delegation). <br>
4. Policy coordination for infrastructure security. <br>
5. Policy-related functions including: <br>
5.1. IP address and AS number allocation, <br>
5.2 ccTLD global policy coordination, <br>
5.3. Protocol numbering via the IANA registries, <br>
5.4 gTLD registry-level policies. <br><br>
Recommendation 1 - mission. The Names Council proposes the following <br>
re-statement of ICANN's mission: <br>
"ICANN's mission is to coordinate technical and policy functions of the <br>
domain name system in order to promote a stable, secure and commercially <br>
viable domain name system, promote competition in key aspects of the <br>
DNS, and achieve broad representation of global Internet communities, <br>
all for the benefit of the users of the global Internet." <br>
The Names Council specified the following existing functions of ICANN <br>
where the NC notes that improvements and enhancements in delivery of <br>
services or improvements in relationships are needed: <br>
- ccTLD administrative functions <br>
- root server administration <br>
- Registry and Registrar contract enforcement e.g. escrow, the UDRP and <br>
WhoIs. <br><br>
Recommendation 2 - structure. Create clearly delineated divisions within <br>
and under ICANN responsible for the administration of operational and <br>
policy functions. This would establish separate staff functions for <br>
policy and operational functions but maintain a clear authority within <br>
ICANN management for all such functions. <br><br>
<br>
Some of the Names Council noted that the greatest potential for mission <br>
creep lay in the areas of additional security and additional consumer <br>
protection. The Names Council recognised that the functions expected of <br>
ICANN as viewed today may, be different in a changed world of tomorrow. <br>
That future world may dictate that ICANN's functions are more, or are <br>
fewer, than those today. Focus of the core functions of the moment will <br>
be a key to success. <br>
Recommendation 3 - functions. ICANN's functions should not be extended <br>
at this time beyond what is outlined in the note "What ICANN Does" . <br><br>
Funding ICANN <br>
Short-term <br>
The NC believes that the debate over the longer term funding of ICANN <br>
should not be distracted by any short term funding problem. <br>
Recommendation 4 - short-term funding. The NC urges the existing funders <br>
to reach at least interim agreements quickly to avoid any short fall in <br>
ICANN's existing budget. <br>
<br><br>
<br><br>
Longer term <br>
Recommendation 5 - core funding. Funding could potentially come from <br>
more than one source but the bulk of funds should ultimately derive from <br>
the revenues of gTLD Registrants' fees and be administered via <br>
Registrars and/or Registries. <br><br>
Recommendation 6 - secondary sources. Secondary sources should include <br>
the ccTLDs and RIRs, but should not include governments. <br><br>
(Consideration should be given to the relevance of ccTLDs which are <br>
marketed in non-geographic ways to recommendations 5 and 6). <br><br>
Recommendation 7 - supplementary sources. Supplementary sources could be <br>
found from sources such as secretariat service fees to the GAC. <br><br>
Recommendation 8 - budgeting. Further to recommendation 2, ICANN <br>
budgeting should reflect a delineated structure. <br><br>
Advisory Bodies and Policy Development <br>
Recommendation 9 - policy making. ICANN policy advisory bodies should <br>
formulate policy recommendations based on a bottom-up, consensus process <br>
of all stakeholders. </font></blockquote></blockquote></html>