<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ga-roots] Re: ICANN Policy -- revised version
Chris, Stuart and all,
This has been the legacy of the ICANN BoD and staff thus far from
the beginning. It remains so. Hopefully this will change. I have my doubts.
Until or unless there is and @large, and IDNO or similar and and open
process for participation, the ICANN is not creditable enough to
have any consensus based policy's considered truly legitimate...
NameCritic wrote:
> If only you placed that much weight on the Bottom Up Consensus that is also
> part of ICANN's Foundation. The the examples of ICANN's BoD decisions that
> have not properly sought or that ignored Bottom Up Consensus are too many to
> list here, yet the decisions that did seek public consensus then followed
> that public consensus number exactly 0.
>
> Chris McElroy aka NameCritic
>
> ----- Original Message -----
> From: "M. Stuart Lynn" <lynn@icann.org>
> To: "Bret Fausett" <baf@fausett.com>; "Milton Mueller" <Mueller@syr.edu>;
> <webmaster@babybows.com>; <ga-roots@dnso.org>
> Sent: Friday, June 15, 2001 12:41 PM
> Subject: Re: [ga-roots] Re: ICANN Policy -- revised version
>
> > I understand and welcome your views, Brett, But I could not disagree more.
> >
> > ICANN has many policies that are embodied in our charter documents
> > that have not been separately and explicitly codified in a single
> > policy document. For example, we have a policy derived from those
> > documents that commit us to further the stability of the Internet.
> > There has been no bottom-up process to codify that - except as was
> > embodied in the founding of ICANN and in the finalization of those
> > documents.
> >
> > When there are important issues on the table, I will continue to
> > summarize existing policies that may be embodied in those documents
> > and elsewhere (including those that have been explicitly stated) and
> > articulate them for the community. Particularly - as in this case -
> > when I receive enquiries as to what our policy on a given topic may
> > be. That is part of my job. This is no different than our restatement
> > of IANA policies in ICP-1.
> >
> > Articulating existing policies is very different from creating new
> > policy. That requires consensus-based approaches. And I do not think
> > any of us disagree on that.
> >
> > I think we all understand our difference of views on this subject,
> > and I doubt we will persuade each other. So it may be best to move
> > on. But I will look forward to your specific comments.
> >
> > With regards
> > Stuart
> >
> > At 9:45 AM -0700 6/15/01, Bret Fausett wrote:
> > >The merits of the relative positions aside, I am concerned about a
> practice
> > >of drafting papers outside ICANN's rigorous bottom-up, policy development
> > >processes, calling it an attempt to codify existing policy, and then
> > >challenging anyone to go through the rigorous bottom-up, policy
> development
> > >process to change it.
> > >
> > >Again, the merits of the relative positions aside, I'm sure you can
> > >appreciate the *potential* for abuse in that kind of process. At this
> point,
> > >two and half years into the life of ICANN, if a clear policy has not
> already
> > >been written somewhere (and I'm referring to more than a few references
> to
> > >"authoritative roots" in ICANN's foundational documents), I'm not sure it
> > >ought to be created now in the name of "existing policy." Consensus
> > >policy-making is much harder work than that.
> > >
> > >I'll have more on the merits of the paper separately, but the process
> issues
> > >here are of concern.
> > >
> > > -- Bret
> > >
> > >
> > >On 6/15/01 9:17 AM, "M. Stuart Lynn" <lynn@icann.org> wrote:
> > >
> > >> It seems, Milton, that academe has arrived at a new standard since I
> > >> left two years ago. Anyone who agrees with you is "honest" and anyone
> > >> who disagrees is not ;-). Well, well!
> > >>
> > >> The basis for the statement that ICANN's policy is to support a
> > >> single authoritative root is extensively articulated in my document
> > >> and the references clearly cited. The White Paper, the Memorandum of
> > >> Understanding, and the Articles of Incorporation give clear
> > > > indication of ICANN's Policy. They are ICANN's charter documents. I
> > > > suggest you read them again. They are not very hard to understand and
> > > > their statements with regard to an authoritative single root and to
> > >> competing roots are quite clear. My statement on ICANN Policy is not
> > >> unilateral -- it is well-grounded in the community processes that led
> > >> to the White Paper and to the formation of ICANN.
> > >>
> > >> You may disagree. That's fine. It would make for a dull ICANN if
> > >> everyone agreed on everything.
> > >>
> > >> And I would encourage you to follow the appropriate processes if you
> > > > would like to see the current policy changed.
> >
> > --
> >
> > __________________
> > Stuart Lynn
> > President and CEO
> > ICANN
> > 4676 Admiralty Way, Suite 330
> > Marina del Rey, CA 90292
> > Tel: 310-823-9358
> > Fax: 310-823-8649
> > Email: lynn@icann.org
> > --
> > This message was passed to you via the ga-roots@dnso.org list.
> > Send mail to majordomo@dnso.org to unsubscribe
> > ("unsubscribe ga-roots" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
> >
>
> --
> This message was passed to you via the ga-roots@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga-roots" in the body of the message).
> Archives at http://www.dnso.org/archives.html
Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 118k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 972-447-1800 x1894 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
--
This message was passed to you via the ga-roots@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-roots" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|