Re: [ga] RE: DNSO Constituency Structure

["Patrick Corliss" <patrick@quad.net.au>]

On Sat, 24 Nov 2001 10:14:16 -0500, Chuck Gomes wrote:


> I don't disagree with any of the arguments about the failure of the
> consensus system within ICANN but I attribute that to the fact that no
> valid consensus development process has ever been put into place.  I
> also recognize that such a task would be very challenging.

Hi Chuck

Danny has answered this quite well on the Names Council mailing list.  It is
a little long, and it may not be the answer, but it is worth reading.

My view is that the wording of the process (below) needs tightening up to
provide those doing the work with clearer guidance as to whether they have
satisfied the relevant criteria.

The failure of the consensus system has a number of reasons which I see as
being caused by the need to get agreement from too many conflicting parties.

In other words it is more a structural problem than a procedural one.

Regards
Patrick Corliss

On Mon, 8 Oct 2001 23:27:43 EDT, Danny Younger wrote:
Subject: [council] Consensus defined

To the representatives of the registrar and registry constituencies:

As an individual employed by a registrar, I am reasonably familiar with the
Registrar Accreditation Agreement and with the Registry Agreement, both of
which cite the following definition of consensus policies:

"Consensus Policies" are those specifications or policies established based
on a consensus among Internet stakeholders represented in the ICANN process,
as demonstrated by (a) action of the ICANN Board of Directors establishing
the specification or policy, (b) a recommendation, adopted by at least a
two-thirds vote of the council of the ICANN Supporting Organization to which
the matter is delegated, that the specification or policy should be
established, and (c) 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.

It would have been reasonable to assume that this definition would have been
brought to the attention of the NC Review Task Force.  Instead, the author
of the Task Force report has had to resort to rather poor "guidance" from
lexicons.   This has resulted in aberrant conclusions that have led to the
misguided recommendation that "the by-laws should be changed to remove
the obligation on the NC to "determine community consensus"".

Changing the Bylaws is a serious matter that should not be considered
lightly.  Changing Bylaws that pertain to consensus policies, the only
policies we have that can bind even recalcitrant participants, is
particularly serious business.

When we review the White Paper, we note that consensus requirements are
viewed as a mechanism to be used to protect against capture by a
self-interested faction.  The Names Council, by definition, is a
self-interested faction.  Accordingly, the definition currently used by
ICANN establishes as a requirement the absolute need to thoroughly represent
the views of groups that are likely to be impacted.  These "groups" are
parts of the Internet community that may not have representation within
the Names Council.

One of ICANN's founding principles is fairness.  Changing the Bylaws so that
the NC no longer has the obligation to determine community consensus
violates this founding principle.  The declaration that "the NC vote itself
on a recommendation, being reflective of the elected representatives of
DNSO stakeholders, is the "only" practical means of determining community
consensus" is spurious... there are many other stakeholders in the ICANN
world other than the DNSO stakeholders, and clearly, there are indeed other
practical means of determining community consensus.

One such method that has withstood the test of time is the use of an open
working group.  The Task Force report concludes that "DNSO working groups as
currently formed are by construction not a representative sample of DNSO
stakeholders because they are open to participation by anyone who chooses."
Again, the author of this report has completely missed the point.  Every NC
constituency  can participate in an open working group as well as
individuals that are not currently represented in the DNSO -- this makes the
working group even more representative of the broader Internet community,
and thus more capable of arriving at true consensus than a body that is only
limited to DNSO stakeholders.

The author of the Task Force report contends that the Council has been
provided with "no help as to how the task should be done."  The task to
which he refers is to "determine that the DNSO process has produced a
community consensus".  Help is most certainly available.  It is contained in
the current definition of a consensus policy.  To determine if consensus
exists:

a.  you must first propose a policy
b.  you must then engage in outreach to those that are likely to be impacted
by the new policy
c.  you must document your outreach efforts to prove that you have
adequately represented the views of those likely to be impacted
d.  you must ask for substantive submissions by those that might be impacted
e.  you must include all such substantive submissions in your report
f.  based upon those submissions, you must document the extent of
agreement/disagreement among impacted parties
g.  you must document the nature and intensity of reasoned support or
opposition to the proposed policy
h.  you must provide a written report citing all the above findings and
justifying your conclusions
i.  you must make such a complete report available for review by the
constituencies
j.  you must include all constituency comments in your supporting materials
k.  you must revise your report accordingly in view of constituency comments
l.  then the report must be made available for public comment
m.  all public comments must be included in the supporting materials
n.  the report must next by re-assessed in light of the public comments, and
then finalized.
o.  at this point the Council is at liberty to vote on the policy
recommendation
p.  results of such a vote are forwarded to the Board.

All of this is necessary because a consensus policy must be able to
withstand the prospect of examination by the Independant Review Panel,
the American Arbitration Association and/or judicial scrutiny in any court
of competent jurisdiction (as indicated by the relevant paragraphs in
several of ICANN's major agreements).

A hastily ratified report serves no one's best interest.  It is quite
apparent that the Interim Review Task Force report should be returned
to the body from which it originated for further work.  There is no need
for a shoddy report just because it is deemed necessary to strictly adhere
to a self-imposed timeline that would ensure a final presentation at the
upcoming plenary session.

There are too many deficiencies in this report at present, only some of
which are cited above. I urge you all to send this report back to the
drafting table, and to offer the benefit of your guidance to a Task Force
that sorely needs your input on "consensus".  The Bylaws require no
change... it is this report that requires change.




--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html