Re: [ga] just my quick input

["kidsearch" <kidsearch@xxxxxxxxxxxxx>]

>From the ICANN website. http://www.icann.org/topics/ 

Kuala Lumpur Meeting
The next round of ICANN meetings in 2004 will be held 19-23 July in Kuala Lumpur, Malaysia. The meetings are free to attend, and open to any interested person. ICANN encourages broad participation in its bottom-up consensus-development process. You can take part in these meetings by attending in person, by taking part in the webcast and remote participation opportunities, and/or by joining one of the various ICANN-related mailing lists

The source of my information about using a bottom up consensus is from the horse's mouth. This is not the only reference to it, just one to show that this was not some "philosophy" invented by the users of this list.

Chris McElroy aka NameCritic
http://www.articlecontentprovider.com




----- Original Message ----- 
From: "Danny Younger" <dannyyounger@xxxxxxxxx>
To: "kidsearch" <kidsearch@xxxxxxxxxxxxx>; "Simon Schuster" <significants@xxxxxxxxx>; <ga@xxxxxxxxxxxxxx>
Sent: Wednesday, December 13, 2006 10:20 AM
Subject: Re: [ga] just my quick input


> Chris, 
> 
> FYI, regarding bottom-up consensus...
> 
> The following is the ICANN Board view (as explained by
> the Evolution and Reform Committee):
> 
> The notion that ICANN would operate by consensus does
> not find its origin in the US Government's White
> Paper. Indeed, the only mention of consensus in that
> document makes it clear that the authors of the White
> Paper assumed that consensus would not be the normal
> method of decision-making in the private-sector
> organization it contemplated:
> 
> "Typically this means that decision-making processes
> should be sound and transparent; the basis for
> corporate decisions should be recorded and made
> publicly available. Super-majority or even consensus
> requirements may be useful to protect against capture
> by a self-interested faction."
> 
> Nor does the Memorandum of Understanding between the
> US Government and ICANN (that officially recognized
> ICANN as the private-sector entity with which the US
> would work to transition management of the DNS from
> governmental control) ever mention consensus
> decision-making. Neither the original ICANN bylaws
> submitted to the US Government, nor the amended bylaws
> in effect at the time the US Government recognized
> ICANN, ever mention consensus. In those latter
> documents, the only supermajority requirements deal
> with the creation of new Supporting Organizations or
> the amendment of the bylaws, each of which requires a
> two-thirds majority of the Board.
> 
> So how did ICANN come to be perceived as an entity
> that should (or can) only operate by consensus?
> Perhaps it was a natural result of the emphasis on
> "bottom-up" policy development, which is a concept
> that is frequently referenced in the White Paper and
> subsequent documents, although that notion - bottom-up
> policy development - is also fully consistent with a
> general process that encourages community acquiescence
> in individual initiatives generally. But most likely,
> this notion originates with the 31 March 1999 revision
> of ICANN's bylaws that inserted provisions
> establishing with the Domain Name Supporting
> Organization. In particular, the following language is
> the first language in any official ICANN document that
> uses the word "consensus:"
> 
> (d) If two-thirds (2/3) of the members of the NC
> determine that the DNSO process has produced a
> community consensus, that consensus position shall be
> forwarded to the Board as a consensus recommendation,
> along with all materials or other information that
> could reasonably be relevant to the Board's review of
> that determination, including (but not limited to) the
> dissenting statement(s) of any member(s) of the NC. If
> more than one-half (1/2) but less than two-thirds
> (2/3) of the members of the NC determine that the DNSO
> process has produced a community consensus, that
> position may be forwarded to the Board as a NC
> recommendation, along with statements of majority and
> minority views, and any separate or dissenting
> statement(s) of any member(s) of the NC. Any proposed
> recommendation that is not supported by an affirmative
> vote of one-half (1/2) of the members of the NC may be
> returned to the body from which it originated, or may
> be assigned to a new body, for further work. In such a
> case, the NC may report to the board the lack of a
> consensus and the steps, if any, it plans to take from
> this point forward with respect to this particular
> recommendation. The NC is responsible for ensuring
> that the Board is informed of any significant
> implementation or operational concerns expressed by
> any responsible party.
> 
> As is clear from this language, there is no mandate
> that only "consensus" recommendations be forwarded to
> the Board, and the only logical inference is that the
> Board could act on recommendations that were not (at
> least by the test set forth here of a two-thirds vote
> of the Names Council) the result of community
> consensus. This conclusion is also supported by the
> language that has been in the ICANN bylaws from the
> time they were first submitted to the US government -
> that "[n]othing in [these bylaws] is intended to limit
> the general powers of the Board or the Corporation to
> act on matters not within the scope of a Supporting
> Organization or that the Board finds are necessary or
> appropriate to further the purposes of the
> Corporation." Since this language clearly permits the
> Board to act without or even contrary to a
> recommendation from a Supporting Organization, and
> sets no supermajority voting requirements, it is clear
> that the ICANN Board is not legally limited to taking
> actions that are demonstrably (or even arguably)
> "consensus" positions, whatever the exact meaning of
> that word.
> 
> The other (and today more important) source of ICANN's
> consensus mentality is the original NSI registry
> agreements, where NSI negotiated limitations on NSI's
> obligations to comply with ICANN policies to only
> those that qualified as "consensus policies." Those
> limitations have been replicated in contracts since
> that time, and were defined as follows:
> 
> (a) "Consensus Policies" are those adopted based on a
> consensus among Internet stakeholders represented in
> the ICANN process, as demonstrated by (1) the adoption
> of the policy by the ICANN Board of Directors, (2) a
> recommendation that the policy should be adopted by at
> least a two-thirds vote of the council of the ICANN
> Supporting Organization to which the matter is
> delegated, and (3) a written report and supporting
> materials (which must include all substantive
> submissions to the Supporting Organization relating to
> the proposal) that (i) documents the extent of
> agreement and disagreement among impacted groups, (ii)
> documents the outreach process used to seek to achieve
> adequate representation of the views of groups that
> are likely to be impacted, and (iii) documents the
> nature and intensity of reasoned support and
> opposition to the proposed policy.
> 
> Similar language now exists in all the gTLD registry
> agreements. The implication of this is that registry
> operators are not in general bound by those contracts
> to comply with ICANN policies that do not meet the
> contractual definition of "consensus policies" quoted
> above.
> 
> Even without these legal motivations, over time the
> natural tendency of an organization such as ICANN
> would be to seek consensus wherever possible, and to
> act without demonstrable consensus support only when
> absolutely necessary. This is a logical and
> appropriate approach for an entity that depends on the
> voluntary cooperation of a wide variety of
> participants, and is in any event most consistent with
> the successful past history of Internet development.
> But this tendency should not be confused with the
> notion that there is some requirement that legitimate
> actions can only rest on a demonstration of consensus
> (however defined). The fact is that there is no such
> requirement. ICANN's efforts to reach "consensus"
> reflect a community preference, not a fundamental
> mandate from ICANN's founding.
> 
> http://www.icann.org/committees/evol-reform/working-paper-process-07may02.htm
> 
> 
> 
> ____________________________________________________________________________________
> Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.
>