Re: [ga] just my quick input

[Danny Younger <dannyyounger@xxxxxxxxx>]

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.