[ncdnhc-discuss] Latest NC draft

[Jefsey Morfin]

Dear Harold,
I certainly join and support YJ's and Kathryn's concerns.
But I think we cannot avoid the entire conception of the ICANN to be 
reviewed if we want it to survive.

1. we first have to decide what is the priority: the ICANN or the network 
(and its participants).
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).

 From this we have four areas to consider:

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.

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.

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.

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.

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.

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.

Jefsey Morfin

On 03:01 23/04/02, KathrynKL at aol.com said:
>Harold:
>
>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.
>
>I would urge you to fight for, and if necessary lead the Noncommercial 
>Constituency,
>in dissenting from any Names Council document which confers policy making 
>authority -- in any type of broad and ambiguous phrases -- upon ICANN.
>
>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.
>
>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:
>
>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"
>
>2)  "Policy-related functions, including:
>       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."
>
>       "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.
>
>       "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.
>
>       ** "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."
>
>       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.
>
>       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."
>
>       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.
>
>Good luck, Harold.
>Kathryn Kleiman
>ACM-IGP
>
>Harold Feld circulated:
>
>>DRAFT version 6
>>Highlighted items are under review.
>>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."
>>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:
>>- ccTLD administrative functions
>>- root server administration
>>- 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" .
>>
>>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.
>>
>>Advisory Bodies and Policy Development
>>Recommendation 9 - policy making. ICANN policy advisory bodies should
>>formulate policy recommendations based on a bottom-up, consensus process
>>of all stakeholders.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20020423/341158f3/attachment-0001.html>