RE: [ga] RE: DNSO Constituency Structure

["Gomes, Chuck" <cgomes@verisign.com>]

Patrick,

I also think Danny did a very good job in discussing consensus in the
message to reference below.  In fact I personally complemented him in this
regard after first reading it.

But, whereas I do believe that structurally changes could definitely improve
the consensus development process, I do not agree that the problems are
primarily structural versus procedural.  Regardless of what structural
changes are made, if clearly defined processes and procedures are not put
into place, we will find ourselves right back where we are now.  In a global
and hugely diverse environment like the Internet, consensus will always be
hard to reach.  Therefore, if there are not clearly defined policies and
procedures with regard to what should be expected outcomes of the consensus
development efforts, it seems highly unlikely that it will be successful.  I
personally believe that is why many people currently are trying to take
shortcuts with regard to consensus development (e.g., task forces).  They
are easier and take less effort and it's not too hard to convince some
people that they are legitimate, but in reality they are a far cry from what
the bylaws and contracts between ICANN and registries demand.

Chuck 

> -----Original Message-----
> From: Patrick Corliss [mailto:patrick@quad.net.au]
> Sent: Saturday, November 24, 2001 12:51 PM
> To: Gomes, Chuck
> Cc: [ga]
> Subject: Re: [ga] RE: DNSO Constituency Structure
> 
> 
> 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@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html