[ncdnhc-discuss] Latest NC draft
James Love
james.love at cptech.org
Wed Apr 24 02:41:23 CEST 2002
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
More information about the Ncuc-discuss
mailing list