[ncdnhc-discuss] Latest NC draft
Michael Froomkin - U.Miami School of Law
froomkin at law.miami.edu
Wed Apr 24 05:02:52 CEST 2002
Not in the least far-fetched. Please inform yourself better.
On Tue, 23 Apr 2002, Alejandro Pisanty - DGSCA y FQ, UNAM wrote:
> James,
>
> too far fetched. Let's focus more closely on realistic scenarios.
>
> Anyway in your description, what structures would ICANN need to make sure
> it receives and refuses such a call? Who should provide the counterpoint
> to such a call?
>
> 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 Tue, 23 Apr 2002, James Love wrote:
>
> > Alejandro, free speech is a reason to limit ICANN's mission. In
> > particular, suppose the copyright industry decided to make ICANN a global
> > police for copyright violations, like they already have for
> > trademark/domain names. Suppose ICANN started taking away domain names
> > from sites that "infringed" on copyrights. Well, what is considered
> > infringment is controverisal. If I quote from a corporate or government
> > memo I get, is that infringement of a copyright, or a use permited under
> > various notions of copyright exceptions? If I post an article from the NY
> > Times on this list, is this a permited use, or an infringement? If I link
> > to an article in the FT, is that an infringement (the FT terms of service
> > says it is). ICANN should stay away from these disputes. Not because
> > they are not important, but because ICANN isn't the body to make copyright
> > law. If you agree with my point, make us happy and propose an ICANN
> > can't statement, regarding policy making on global copyright issues. Jamie
> >
> >
> > > 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
> >
> >
> > --
> > James Love
> > http://www.cptech.org mailto:james.love at cptech.org
> > mobile +1.202.361.3040
> >
> >
> > _______________________________________________
> > Discuss mailing list
> > Discuss at icann-ncc.org
> > http://www.icann-ncc.org/mailman/listinfo/discuss
> >
>
> _______________________________________________
> 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.<--
More information about the Ncuc-discuss
mailing list