[Internal-cg] Consensus building process
joseph alhadeff
joseph.alhadeff at oracle.com
Fri Aug 15 16:52:45 UTC 2014
yes. Thanks.
On 8/15/2014 12:25 PM, Martin Boyle wrote:
>
> Hi Joe,
>
> Yes, you are right. I thought my principle 3 was enough to resolve
> this: essentially there is an obligation on any party opposing
> (blocking) consensus to explain their concerns to allow those concerns
> to be addressed. Essentially this allows the issues to be addressed
> head on and resolved. On the other hand, overruling a maintained and
> solid objection would just lead to that coming back again later in the
> process.
>
> It works for the hold-out case that Keith flags. For the substantive
> cases, though, the only defence I can see for a legitimate objection
> to be ignored through weigh of numbers is to allow that point to be
> specifically addressed in the final report (and I really am just
> talking about the final proposal and the process for getting there to
> be the only substantive issue we have).
>
> If Wolf-Ulrich were to add to the end of principle 3, "If these
> concerns are not met in the final proposal, the opposing party should
> be invited to present the dissenting views in a written submission to
> the report.", would this work?
>
> Cheers
>
> Martin
>
> *From:*internal-cg-bounces at icann.org
> [mailto:internal-cg-bounces at icann.org] *On Behalf Of *joseph alhadeff
> *Sent:* 14 August 2014 20:20
> *To:* internal-cg at icann.org
> *Subject:* Re: [Internal-cg] Consensus building process
>
> 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>
> [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 <mailto: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/20140815/282f43ac/attachment.html>
More information about the Internal-cg
mailing list