[ncdnhc-discuss] Latest NC draft

[Michael Froomkin - U.Miami School of Law]

I think that the answer is, ICANN has almost no role in protecting
consumers directly.  It should serve as a resource for local authorities
that need technical help, and it should perhaps compile information as to
which local authorities consumers should consult.

The free speech issues are fully taken care of by instituting a
decentralized system of domain name creation and regulation such that
conusmers have choices among large numbers of registries located in a
variety of jurisdictions and subject to a variety of local rules.
Requiring some transparancy as to the rules applied (e.g. clear
publication of contract terms), enables consumers to make informed choices
among alternatives (e.g. register at home or abroad).

On Tue, 23 Apr 2002, Alejandro Pisanty - DGSCA y FQ, UNAM wrote:

> Dear Kathy,
> 
> re not expanding ICANN's policy making, it would help the commitee I serve
> as chairperson enormously to understand how this call is reconciled with
> two matters that have empahtically been brought forward by our own
> constituency, protection of free speech and protection of consumer
> interests.
> 
> We are also still missing non-commercial views on crucial issues, like
> funding, for which we would be most thankful.
> 
> Yours,
> 
> Alejandro Pisanty
> 
> 
> ..  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
>      Dr. Alejandro Pisanty
> Director General de Servicios de Computo Academico
> UNAM, Universidad Nacional Autonoma de Mexico
> Av. Universidad 3000, 04510 Mexico DF Mexico
> Tel. (+52-55) 5622-8541, 5622-8542 Fax 5550-8405
> http://www.dgsca.unam.mx
> *
> ** 10 Aniversario de Internet Society - www.inet2002.org en Washington, DC
> ---->> Unete a ISOC Mexico, www.isoc.org
>  Participa en ICANN, www.icann.org
> ..  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
> 
> 
> 
> On Mon, 22 Apr 2002 KathrynKL at aol.com wrote:
> 
> > 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.
> > >
> > >
> >
> >
> >
> 
> _______________________________________________
> Discuss mailing list
> Discuss at icann-ncc.org
> http://www.icann-ncc.org/mailman/listinfo/discuss
> 

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   froomkin at law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's hot here.<--