[ncdnhc-discuss] Latest NC draft

[KathrynKL at aol.com]

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/20020422/b26d4585/attachment-0001.html>