[Internal-cg] Consensus building process

Mon Aug 11 19:48:14 UTC 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140811/78572d80/attachment.html>