[Internal-cg] Consensus building process
joseph alhadeff
joseph.alhadeff at oracle.com
Thu Aug 14 19:19:36 UTC 2014
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] *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>
> [mailto: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 <mailto:kavouss.arasteh at gmail.com>
>
> *Sent:*Thursday, August 14, 2014 7:22 PM
>
> *To:*WUKnoben <mailto:wolf-ulrich.knoben at t-online.de>
>
> *Cc:*Milton L Mueller <mailto:mueller at syr.edu> ; Martin Boyle
> <mailto:Martin.Boyle at nominet.org.uk> ; Coordination Group
> <mailto: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
> <mailto: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 <mailto:mueller at syr.edu>
>
> *Sent:*Tuesday, August 12, 2014 8:12 PM
>
> *To:*'Martin Boyle' <mailto:Martin.Boyle at nominet.org.uk> ;
> Coordination Group <mailto: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>
> [mailto: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>
> [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
> <mailto: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>
> [mailto: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
> <mailto:kavouss.arasteh at gmail.com>>
> À: "Patrik Fältström" <paf at frobbit.se <mailto:paf at frobbit.se>>
> Cc: "Coordination Group" <internal-cg at icann.org
> <mailto: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
> <mailto:paf at frobbit.se> > :
>
>
>
>
> On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben at t-online.de
> <mailto: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 <mailto:Internal-cg at icann.org>
> https://mm.icann.org/mailman/listinfo/internal-cg
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org <mailto:Internal-cg at icann.org>
> https://mm.icann.org/mailman/listinfo/internal-cg
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org <mailto:Internal-cg at icann.org>
> https://mm.icann.org/mailman/listinfo/internal-cg
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org <mailto:Internal-cg at icann.org>
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org <mailto: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/20140814/4be098f8/attachment.html>
More information about the Internal-cg
mailing list