[ncdnhc-discuss] Latest NC draft

Wed Apr 24 02:54:23 CEST 2002

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
>