[council] Consensus defined

[DannyYounger@cs.com]

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.