[Internal-cg] Consensus building process

Tue Aug 12 18:16:00 UTC 2014

Dear Martin
I do not clearly understand your illusion to WCIT.
Please just tell me, what happened if the views of those dealing with
naming, or  numbers, or protocle remained a minority views  and the rest
are joining what do you call rough consensus.
Let us imagine also that we go ahead with such soft consensus in which a
valid views of one of these groups are not taken into account

Do you still believe that such a soft or rough consensus  disregarding the
views of one key player could be considered a valid outcome
Pls comment.
I am of the strong view that the chair should further and further discuss
until we find a real ( not rough .not soft ,not hard ) consensus
Kavouss

2014-08-12 19:23 GMT+02:00 Martin Boyle <Martin.Boyle at nominet.org.uk>:

>  Hi All,
>
>
>
> First thanks to Wolf-Ulrich for his paper.  I greatly like the idea of
> standards of good behaviour and mutual respect – and I’m pleased to see
> that this is already very much the framework for the way that the ICG
> works.  I’d also note that the analysis of shades of grey in levels of
> support is interesting – was it Patrik who first noted the two extremes
> (non-substantial and substantial issues) and the level of consensus that
> might be needed?  I’m just not sure I know how to use them…
>
>
>
> I’d firmly endorse the aim that “the ICG … reach at least Consensus on the
> Proposal for the IANA Stewardship Transition to be forwarded to the NTIA”
> subject to our continued effort to try to achieve full/unanimous consensus
> or (at least) to have addressed address points of concern.
>
>
>
> However, I do not like processes that are supposed to be by consensus
> being resolved by voting (cf WCIT):  voting leaves winners and losers.  It
> also means that people get lazy and fail to look for compromise or common
> ground or ways to address “reasonable” concerns.  That aversion is not
> really addressed by supermajorities:  even at an 80% supermajority, all the
> domain name registries or all the government representatives or all GNSO
> members could be overruled.  At 85% all the ccTLD registries, at 90% all
> the gTLD registries could be ignored.
>
>
>
> I do recognise the need for a mechanism that allows us to come to a final
> recommendation and I’m afraid that I do not see any magic wand.  But I
> would suggest a number of basic principles:
>
>
>
> ·         The aim of the discussion should be to try to find a solution
> where **no member of the ICG still maintains serious opposition to the
> outcome.**  Reasons for objections should be given, allowing the ICG
> wherever possible to try to address those concerns.
>
> ·         **Recourse to any form of voting should be the exception.**
> Its use might be fine for non-substantive issues.  For substantive issues,
> at least none of the “customer groups” (numbers, protocols, gTLDs or
> ccTLDs) of the IANA remains strongly opposed.
>
> ·         Group members who still have problems with the evaluation
> should be invited to **identify possible ways in which the proposal could
> be modified to make it acceptable to them.**
>
> ·         Discussions should continue until **no “IANA customer” group is
> firmly opposed.**
>
>
>
> One final point:  I would be willing to allow anyone who feels that they
> have not been heard to put a minority view into the final report.  I’d
> rather that did not happen, but if the views are strong enough, it would be
> best to have then documented in the report than to be first aired in the
> discussion that follows the publication of our final report.
>
>
>
> Cheers
>
>
>
> Martin
>
>
>
>
>
>
>
> *From:* internal-cg-bounces at icann.org [mailto:
> internal-cg-bounces at icann.org] *On Behalf Of *Kavouss Arasteh
> *Sent:* 11 August 2014 20:48
> *To:* Drazek, Keith
>
> *Cc:* Coordination Group
> *Subject:* Re: [Internal-cg] Consensus building process
>
>
>
> Dear All,
>
> Undoubtedly, it would be super majority either 2/3 or 4/5 .
>
> Kavouss
>
>
>
> 2014-08-11 18:18 GMT+02:00 Drazek, Keith <kdrazek at verisign.com>:
>
> I agree that we will need a clear process for determining consensus that
> falls somewhere on the spectrum between humming and requiring a unanimous
> vote.
>
> If we get in to discussions of voting, we'll also need to address the
> thresholds required to establish consensus. Is it a simple majority?
> Super-majority?  Unanimous voting is an unhelpful requirement that would
> likely obstruct our work and our ability to deliver, so I believe that
> should be a non-starter for the ICG. We need to avoid the possibility of
> one dissenting vote undermining an otherwise strongly supported
> recommendation that represents broad community consensus.
>
> However, if/when there is not full consensus, it will be important that we
> have a mechanism for expressing dissenting opinions. The GNSO Registries
> Stakeholder Group employs a "minority statement" mechanism to allow for all
> views to be expressed when there is consensus but not unanimity on a
> particular topic. Perhaps we should consider a similar mechanism for the
> ICG.
>
> Keith
>
>
> -----Original Message-----
> From: internal-cg-bounces at icann.org [mailto:internal-cg-bounces at icann.org]
> On Behalf Of Subrenat, Jean-Jacques
> Sent: Monday, August 11, 2014 6:09 AM
> To: Kavouss Arasteh
> Cc: Coordination Group
> Subject: Re: [Internal-cg] Consensus building process
>
> Hello Colleagues,
>
> From the experience of the past few weeks, unfortunately we can conclude
> that the current process is not successful. Rather than meting out blame or
> praise, we need to understand why it's not working. Group dynamics and a
> bit of sociology can help.
>
> Our Coordination Group is different from what some of us/you have come to
> consider as "normal". The technical bodies (IETF, IAB) have developed an
> efficient process where "rough consensus" is understood and accepted. But
> other components of the ICG have different habits, and also a different
> accountability mechanism: however attractive "rough" may be, it is
> insufficient. For example, the GAC has its own rules (a joint position can
> only be reached by unanimity), and the ALAC routinely conducts all its
> votes on a full-membership basis (each member has to say ay, nay, abstain,
> or be noted down as not having cast a vote).
>
> So the challenge is this: is the "rough consensus" really adapted to all
> the needs of our group? With the experience gained collectively in London,
> and especially since then, I would recommend a dual approach:
>
> A/ MATTERS REQUIRING ALL MEMBERS TO VOTE (typically, to be decided as soon
> as possible, with the exception of our Transition plan)
>    - Chair structure and membership,
>    - Charter of the ICG,
>    - choice of Secretariat (ICANN or outside of ICANN, or a mixture of
> both),
>    - choice of near-final drafts and approval of final draft of our
> Transition plan, before presentation to the NTIA.
>
> B/ MATTERS WHERE OTHER FORMS OF DECISION-MAKING ARE ACCEPTABLE
>    - Appraisal of specific community input, as a contribution to the ICG's
> recommended plan (e.g. ALAC should appraise input from its own community
> before submitting it to the whole ICG),
>    - external relations and communications of the ICG (once the Chair
> structure has been chosen and populated, it may wish to ask Chair, or
> another of its members, to be the point of contact),
>    - administrative & logistic matters, in conjunction with the chosen
> Secretariat (here too, delegation would be possible).
>
> I'm prepared to provide a more detailed proposal for the above items.
>
> Best regards,
> Jean-Jacques.
>
>
>
> ----- Mail original -----
> De: "Kavouss Arasteh" <kavouss.arasteh at gmail.com>
> À: "Patrik Fältström" <paf at frobbit.se>
> Cc: "Coordination Group" <internal-cg at icann.org>
> Envoyé: Lundi 11 Août 2014 10:40:08
> Objet: Re: [Internal-cg] Consensus building process
>
>
>
>
> Dear Wolf
> Thank you very much for reply
> My point is that if one or more ICG Mmember(s) is7are againszt the ruling
> of the Chir ,They could raise their issue and the matter must be settled by
> simple explanation or if not resolved by voting . I.E. CHAIR DOES NOT HAVE
> DECISION MAKING POWER ON HE OR HIS OWN WISHES RATHER TO TAKE INTO ACCOUNT
> VIEWS OF MEMBERS Regards KAVOUSS Regards
>
>
>
>
>
> 2014-08-11 8:33 GMT+02:00 Patrik Fältström < paf at frobbit.se > :
>
>
>
>
> On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben at t-online.de >
> wrote:
>
> > The chair’s designation that consensus is reached is not her/his own
> decision rather than a wrap-up of extensive discussions. Of course this
> designation can be challenged by members. And this is what triggers your
> question about “If several participants in the ICG disagree with the
> designation given ...”. I’m open to any helpful suggestion on how we could
> procede in such a case.
> > In the end consensus - as defined – has to be achieved.
>
> Let me emphasize what you say here, which I strongly agree with.
>
> We must deliver.
>
> This implies we must be able to reach consensus.
>
> The last couple of weeks discussions on various topics makes me a bit
> pessimistic on the ability for us to reach consensus, but I am optimistic,
> always optimistic, on peoples ability and interest in actually deliver.
>
> Remember that the chair is calling on the consensus question, not the
> substance. That way the power of the chair is decreased to a minimum and
> process issues.
>
> Patrik
>
>
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140812/b969e89c/attachment.html>