[Internal-cg] Consensus building process

Thu Aug 14 20:08:11 UTC 2014

Dear Wolf
Thank you very much for your kind reply.
I suggest that we do not formally define the exceptional circumstances that
we may wish to proceed if there is some level of disagreemnet
I have been working in internatuional sensitive and delicate meetings and
conférences and learned that we need to treat any issue which may face on a
case by case basis and not generalized the matter.
AS I mentioned before going to vote is one of the most democratic practice
in international procedure. It should be avoided as musch as possible but
not totally excluded .What remain is the criteria, simple majority or
abolute majority which may be 2/3 or 4/5  as both  practices are used by
all parlimentary circumstances
 Let us bear in mind the above but write it very cautiously
Regards
Kavouss

2014-08-14 21:19 GMT+02:00 joseph alhadeff <joseph.alhadeff at oracle.com>:

>  Milton:
>
> I agree with the first bullet points, but have reservations on the last.
> I agree that no customer stakeholder objection related to the proposal can
> exist and still have a consensus, but I also think that we cannot have a
> consensus if a number of the non-customer stakeholders object.
>
> Best-
>
> Joe
>
> On 8/14/2014 2:49 PM, Milton L Mueller wrote:
>
>  Keith
>
> On the “holdout” problem,  I think Martin’s principles addressed your
> concerns. To reproduce them here:
>
>
>
> ·         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.**
>
>
>
> Note these two things:
>
>
>
> 1)      If there really is no consensus (and that DOES mean no one
> objects, even if they don’t fully agree) then we are reverting to a kind of
> supermajority voting or decision rule as outlined in the GNSO rules.
> Purists like me refuse to call this “consensus.” It doesn’t mean that we
> are “stuck” or blocked, it just means that we really don’t have something
> that conforms to the classical meaning of consensus. I think we should not
> play verbal games and call this “consensus.”
>
> 2)      IANA customer groups (groups, not individuals) have a kind of
> special status in Martin’s principles, given their direct stake in how IANA
> is managed. Even though I am not representing a customer group, I think
> this is fair. If everyone in a particular customer group cannot live with a
> decision, it is certainly not consensus and we probably shouldn’t force
> such a decision on them, no matter how much everyone else supports it. We
> might extend the same kind of protection to other groups; e.g., if none of
> the user representatives (NCSG and ALAC) agree, it would seem unreasonable
> to claim that an outcome has even “rough” consensus. But if one particular
> individual within that user group can’t be swayed, then it should not be
> considered the same kind of obstacle to an outcome.
>
>
>
> Hope this is clear
>
> Milton L Mueller
>
> Laura J and L. Douglas Meredith Professor
>
> Syracuse University School of Information Studies
>
> http://faculty.ischool.syr.edu/mueller/
>
>
>
>
>
> *From:* internal-cg-bounces at icann.org [
> mailto:internal-cg-bounces at icann.org <internal-cg-bounces at icann.org>] *On
> Behalf Of *Drazek, Keith
> *Sent:* Thursday, August 14, 2014 2:10 PM
> *To:* Coordination Group
> *Subject:* Re: [Internal-cg] Consensus building process
>
>
>
> Just so I’m clear…
>
>
>
> Looking ahead….if we end up with 29 ICG reps in favor of a final
> recommendation and one person who unreasonably refuses to compromise, will
> that be deemed “consensus” or “no consensus?”
>
>
>
> Hypothetically speaking, if one holdout among us can obstruct a decision
> that has received support from all other members, and would prevent
> delivery of a recommendation….I find that very troubling.
>
>
>
> Keith
>
>
>
>
>
>
>
> *From:* internal-cg-bounces at icann.org [
> mailto:internal-cg-bounces at icann.org <internal-cg-bounces at icann.org>] *On
> Behalf Of *WUKnoben
> *Sent:* Thursday, August 14, 2014 1:47 PM
> *To:* Kavouss Arasteh
> *Cc:* Coordination Group
> *Subject:* Re: [Internal-cg] Consensus building process
>
>
>
> Dear Kavouss,
>
>
>
> you make the same point I expressed by saying that “I’m still uncertain
> with “non-substantive” issues which level of substance may depend on
> different views”. I would welcome you providing other more useful criteria
> to decide in which rare cases a “poll” or “voting” could apply.
>
>
>
> As you may have seen in my latest draft I removed the “adjectives” from
> consensus. So I would appreciate your written suggestion for an acceptable
> text that I could better understand your disagreement with the present
> proposal.
>
> Best regards
>
> Wolf-Ulrich
>
>
>
> *From:* Kavouss Arasteh <kavouss.arasteh at gmail.com>
>
> *Sent:* Thursday, August 14, 2014 7:22 PM
>
> *To:* WUKnoben <wolf-ulrich.knoben at t-online.de>
>
> *Cc:* Milton L Mueller <mueller at syr.edu> ; Martin Boyle
> <Martin.Boyle at nominet.org.uk> ; Coordination Group <internal-cg at icann.org>
>
> *Subject:* Re: [Internal-cg] Consensus building process
>
>
>
> Dear All,
>
> I am not comfortable to any of these measures.
>
> The more we discuss and analyze ,the more problem is created.
>
> I strongly disagree to make any discrimination among the contstituent
> groups in ICG ,WHEN IT IS PROPOSED qUOTE
>
> "For substantive issues, at least none of the “customer groups” (numbers,
> protocols, gTLDs or ccTLDs) of the IANA remains strongly opposed"
>
> What is considered by someone " substantive" may be considered by others "
> non substantive,
>
> NO ADJECTIVE FOR OPPOSITION .NO ADJECTIVE FOR SCONSENSUS.
>
> If you want instead of making progress to draft another chatter or
> convention for decision making ,I disagree with that .
>
> It ios incumbent to the chair and the two vice chairs to make utmost
> efforts to build consensus-
>
> Pls end this discussion
>
> Regards
>
> Kavouss
>
>
>
>
>
>
>
> 2014-08-14 18:32 GMT+02:00 WUKnoben <wolf-ulrich.knoben at t-online.de>:
>
> Thanks all for your valuable input.
>
>
>
> Milton is right calling for verbal clarity. But differentation is also
> needed and there are different approaches to achieve it. And as I said
> before the suggestion so far was based on GNSO habit.
>
>
>
> I tried to accomodate the discussion and therefore suggest to
> differentiate between “recommendation by consensus” (highest level, 100%)
> and “recommendation” (all remaining discussion results leading to a
> recommendation).
>
>
>
> I agree to all basic principles Martin came up with and incorporated them.
>
> I’m still uncertain with “non-substantive” issues which level of substance
> may depend on different views.
>
>
>
> I would appreciate further fruitful discussion on the list and we will
> hopefully see an end at our call next week.
>
>
>
> See my edits attached.
>
> Best regards
>
> Wolf-Ulrich
>
>
>
> *From:* Milton L Mueller <mueller at syr.edu>
>
> *Sent:* Tuesday, August 12, 2014 8:12 PM
>
> *To:* 'Martin Boyle' <Martin.Boyle at nominet.org.uk> ; Coordination Group
> <internal-cg at icann.org>
>
> *Subject:* Re: [Internal-cg] Consensus building process
>
>
>
> I think Martin makes very good points here.
>
> I like his proposed principles, every one of them.
>
>
>
> I must confess that I have been wincing at the way the word “consensus” is
> (ab)used routinely in these circles. Either it is truly consensus, and
> everyone either agrees or agrees not to object, or it is _something else_.
> Will we please stop trying to apply the term “consensus” to supermajority
> voting processes? My academic commitment to verbal clarity and directness
> is screaming at me that this is wrong.
>
>
>
> The IETF concept of “rough” consensus is an informal mechanism that is
> suitable for a more homogeneous environment in which adherence to standards
> is voluntary anyway, but in an environment with binding outcomes and
> political factions, it can and, in the ICANN context, frequently HAS merely
> provided a rationalization for ignoring significant minority points of
> view.
>
> --MM
>
>
>
> *From:* internal-cg-bounces at icann.org [mailto:
> internal-cg-bounces at icann.org] *On Behalf Of *Martin Boyle
> *Sent:* Tuesday, August 12, 2014 1:24 PM
> *To:* Coordination Group
> *Subject:* Re: [Internal-cg] Consensus building process
>
>
>
> 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 <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
>
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
>
>
> _______________________________________________
> Internal-cg mailing listInternal-cg at icann.orghttps://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/20140814/b3a490b4/attachment.html>