[Internal-cg] Consensus building process
Milton L Mueller
mueller at syr.edu
Fri Aug 29 18:39:06 UTC 2014
Oh, now I see that Alissa's mind was already changed, so my last message was unnecessary
--MM
> -----Original Message-----
> From: internal-cg-bounces at icann.org [mailto:internal-cg-
> >I'm pretty sure that it is a fairly unlikely scenario, but other
> >communities should not be able to force a solution that overrides the
> >concerns of the directly affected party(ies). Essentially, if the
> >ccTLD members say "no" to something proposed for the root-zone file
> >that directly and only affects ccTLD entries, surely that should not be
> >overridden?
>
> Ah, now I understand your concern, and I agree.
>
> >
> >So trying to find a way forward:
> >
> >1. I'm ok with the term "small minority" which allows some debate at
> >the time over what small means. I could not accept "if a minority disagrees"
> >for reasons I've outlined before, that it does not really reflect the
> >need to find a suitable compromise.
> >
> >2. Add something along the lines of, "It is not expected that the
> >representatives of an operational community significantly and directly
> >affected by a conclusion would be overruled in this process."
> >
> >Would this approach be acceptable to colleagues?
>
> This works for me.
>
> Thanks,
> Alissa
>
> >
> >
> >As I say, I think that this is an unlikely scenario - we should have
> >been able to find a compromise by then - but I am not convinced that a
> >footnote from the affected operational community saying that, and
> >identifying why, the approach was unacceptable to that community would
> >be considered to be a viable proposal.
> >
> >Hope this helps
> >
> >Martin
> >
> >
> >-----Original Message-----
> >From: Alissa Cooper [mailto:alissa at cooperw.in]
> >Sent: 28 August 2014 22:56
> >To: mnuduma at yahoo.com; Martin Boyle; Internal-cg at icann.org
> >Subject: Re: [Internal-cg] Consensus building process
> >
> >Mary, Martin, all,
> >
> >I would be fine to replace “small minority” with “minority.” That is,
> >if a minority of any size — from 1 to 14 ICG reps — cannot have its
> >objections accommodated after extended discussion, those objections
> >should be documented and the group should move on. I would resist
> >defining “small”
> >in any other way, since again our numeric representation in the group
> >is arbitrary and has unclear meaning of its own.
> >
> >But if your request is that the ICG cannot progress a document that has
> >an objection from any minority, or from an operational community
> >minority — that, I believe, is not workable. That allows 1 or more ICG
> >reps to prevent the ICG’s work from going forward. Specifically, it
> >puts us in a situation where rather than sending a final proposal to
> >NTIA with a fully explained objection from a minority, we would not be
> >able to send anything at all. I think we have to be able to send
> >something, even if all the IETF reps object, or all the numbering reps,
> >or all the ccTLD reps, or all the naming reps, or any or all reps from
> >another constituency. Sending nothing means that NTIA has to make a
> >judgment of its own of whatever state our process ends in, rather than
> >us informing them of the end state. I don’t see how the former is
> >preferable to the latter.
> >
> >Also, I was the one who did the “member”/“participant” switch — it
> >seems quite strange to me to consider ourselves members since this is
> >not a membership organization — but it’s obviously confusing so I’m
> >happy for the term “members” to be used.
> >
> >Alissa
> >
> >On 8/27/14, 4:26 AM, "mnuduma at yahoo.com" <mnuduma at yahoo.com>
> wrote:
> >
> >>All
> >>I am sorry, if I missed some views or threads.
> >>I have same concerns as raised by Martin. A mere footnote of a
> >>minority objections, say 10% or whatever number that may be, can
> >>hardly be acceptable on substantive issues by those on that side of
> >>the divide. I think ICG should strive at having consensus in all
> >>issues and go to voting as a last resort, and where it becomes
> >>impossible to reach, the minority view should form part of the main
> >>report/proposal, including the rationale for the objections. I am
> >>being curious here: why have we changed "members" to 'Participants',
> any compelling reasons?
> >>Mary Uduma
> >>
> >>Sent from my BlackBerry wireless device from MTN
> >>
> >>-----Original Message-----
> >>From: Martin Boyle <Martin.Boyle at nominet.org.uk>
> >>Sender: internal-cg-bounces at icann.org
> >>Date: Wed, 27 Aug 2014 08:30:22
> >>To: Alissa Cooper<alissa at cooperw.in>;
> >>Internal-cg at icann.org<internal-cg at icann.org>
> >>Subject: Re: [Internal-cg] Consensus building process
> >>
> >>Hi Alissa,
> >>
> >>Thanks for your revised text.
> >>
> >>I still have concerns over minority views where a group is seriously
> >>impacted by the decision. I've noted before that, for the names part
> >>of the equation, the ccTLD or the GNSO community could be in a
> >>significant minority. As a result, any recommendation coloured by a
> >>footnote objection from that community would hardly be a solution.
> >>
> >>That obviously depends on what we mean by small minority (less than
> >>10% would meet my concerns, but might not meet concerns of others).
> >>
> >>I've made a few changes that try to clarify the meaning of the text.
> >>However, I'm bemused by the (partial) change from the term "members"
> >>to "participants." I can see that we do not want to non-participants
> >>to be dominant in the committee for counting purposes, but we do not
> >>spell the consequences out.
> >>
> >>Best
> >>
> >>Martin
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: internal-cg-bounces at icann.org
> >>[mailto:internal-cg-bounces at icann.org] On Behalf Of Alissa Cooper
> >>Sent: 27 August 2014 00:03
> >>To: Internal-cg at icann.org
> >>Subject: Re: [Internal-cg] Consensus building process
> >>
> >>I made a small change to at the bottom of page 1 in v4 to explain the
> >>role of liaisons.
> >>
> >>I haven’t seen any responses to the other changes, explained in my
> >>note below. Any outstanding objections to the v4 version?
> >>
> >>Thanks,
> >>Alissa
> >>
> >>On 8/21/14, 5:13 PM, "Alissa Cooper" <alissa at cooperw.in> wrote:
> >>
> >>>Hi all,
> >>>
> >>>I have attached and uploaded to Dropbox a v4 that addresses my
> >>>remaining concerns with the consensus document. It is based on the v3
> >>>that was uploaded by Paul earlier this week. Here is a summary of the
> >>>changes and my rationales for them:
> >>>
> >>>1) Personnel decisions vs. All other decisions In section 4 I have
> >>>created two subsections, one about personnel decisions and one about
> >>>all other decisions. I have removed the language about “substantive”
> >>>and “non-substantive” because it wasn’t clear to me what it meant and
> >>>I think the actual meaningful distinction is personnel vs.
> >>>non-personnel decisions. That is, for personnel decisions I think
> >>>voting and going with the majority winner is fine; for all other
> >>>decisions I do not think we should vote.
> >>>
> >>>As I mentioned in the chat window on the call, I don’t see how we can
> >>>credibly vote on document approvals and other non-personnel matters
> >>>since our numbers in terms of representation of constituencies (which
> >>>themselves can be sliced and diced many different ways) are arbitrary.
> >>>
> >>>2) Hold-out problem
> >>>As I stated before I was concerned about the language in the document
> >>>that required all of the operational community representatives (or
> >>>“IANA
> >>>customers”) to be satisfied with every decision, because I believe
> >>>this would allow one group to prevent the full ICG from moving
> >>>forward. From my perspective the important parts are (i) that we
> >>>spend sufficient time trying to accommodate objections, and (ii) that
> >>>we document objections that cannot be accommodated. As long as we
> put
> >>>in a serious effort at accommodation and objectors can explain in as
> >>>much detail as they like why they object, I don’t think any
> >>>individual or group should have the power to prevent our process from
> >>>moving forward or to prevent us from sending a proposal to NTIA. I
> >>>have therefore removed the language about satisfying all IANA
> customers.
> >>>
> >>>3) Principles
> >>>I thought the second set of principles was clearer than the first, so
> >>>I have kept the second and deleted the first. I do not believe we can
> >>>put a numeric figure on “rough consensus” for the same reason that we
> >>>should not be voting, and the term “rough consensus” does not
> >>>otherwise appear in the document, so I removed the 4/5 requirement as
> >>>well.
> >>>
> >>>4) Methodology
> >>>I have made a number of suggestions to the methodology section. I
> >>>propose as a first step that the chair/co-chairs set a time frame for
> >>>discussion, which can be extended if necessary. I suggest that
> >>>re-evaluation of a published designation only occur in light of
> >>>serious objections to the designation — this should be an exceptional
> >>>circumstance. I removed the notion that the designation would
> >>>continue to be updated until everyone agrees with it because I don’t
> >>>understand how that process would ever terminate. And I added more
> >>>detail about the nature of polls.
> >>>
> >>>5) Appeal
> >>>I removed the language about the ability for any participant to
> >>>appeal a designation — again, I don’t understand how a
> >>>decision-making process would terminate if there can be endless
> >>>appeals, and if we go down the path of documenting objections, I
> >>>don’t think this is necessary.
> >>>
> >>>6) Decision-making venues
> >>>I think we should be able to make decisions on the mailing list
> >>>(especially easy ones :-)) in addition to during meetings, so I added
> >>>some words to that effect.
> >>>
> >>>7) Editorial
> >>>I did a bunch of editorial clean-up.
> >>>
> >>>Thoughts?
> >>>
> >>>Alissa
> >>>
> >>>
> >>>On 8/20/14, 11:12 AM, "Manal Ismail" <manal at tra.gov.eg> wrote:
> >>>
> >>>>Thanks Wolf-Ulrich and apologies for my late reply ..
> >>>>I was already not fully satisfied with the language I suggested and
> >>>>was open for better language ..
> >>>>But in the absence of any, I'm ok with reverting back to the
> >>>>original text ..
> >>>>Thanks again for the heads up ..
> >>>>Kind Regards
> >>>>--Manal
> >>>>-----Original Message-----
> >>>>From: WUKnoben [mailto:wolf-ulrich.knoben at t-online.de]
> >>>>Sent: Monday, August 18, 2014 10:43 PM
> >>>>To: Manal Ismail; Lynn St.Amour; Internal-cg at icann.org
> >>>>Subject: Re: [Internal-cg] Consensus building process
> >>>>
> >>>>Thanks Manal,
> >>>>
> >>>>I think we starting a bit mixing between charter related items and
> >>>>those items related to these draft guidelines. The ICG role must
> >>>>definitely be fixed in the charter. What is expressed in the
> >>>>guidelines can per se only work within the limited role of the ICG.
> >>>>Whether it's "decision making"
> >>>>or "conclusion" - this is just wording and needs common understanding.
> >>>>But for me "administrative" decision making looks a bit confusing as
> >>>>it could imply additional ICG guidelines for "other" decision making.
> >>>>So for the latest draft version (v3) coming up I took the liberty,
> >>>>not to accept your amendments in this respect.
> >>>>
> >>>>Best regards
> >>>>
> >>>>Wolf-Ulrich
> >>>>
> >>>>-----Ursprüngliche Nachricht-----
> >>>>From: Manal Ismail
> >>>>Sent: Monday, August 18, 2014 2:22 PM
> >>>>To: Lynn St.Amour ; Internal-cg at icann.org
> >>>>Subject: Re: [Internal-cg] Consensus building process
> >>>>
> >>>>I fully agree with Lynn that, within our task of
> >>>>coordinating/assimilating proposals, we hopefully don't have major
> >>>>autonomous decisions to make .. and if they exist, I believe, we
> >>>>should try to revert back to the community, to the extent possible ..
> >>>>Yet, having said that and within our administrative work, we may run
> >>>>into different situations including:
> >>>>
> >>>>- All proposals received fit smoothly into one puzzle (theoretical
> >>>>best case
> >>>>scenario)
> >>>>- Gaps/missing information needed to complete the consolidated
> >>>>proposal (request missing information from the relevant
> >>>>community(ies))
> >>>>- Overlaps with different proposals sharing the same view (easy
> >>>>administrative work to come up with a single draft)
> >>>>- Overlaps where the different proposals received suggest
> >>>>different/opposite views (I believe, this where we need to agree how
> >>>>to
> >>>>handle)
> >>>>- Other possible scenarios ??
> >>>>
> >>>>Just thinking out loud ..
> >>>>
> >>>>Please note that I did some edits, marked in track changes, to
> >>>>ICG-Consensus Building_draft_v2.doc (hope this is the right version)
> >>>>and saved a new version with my initials appended .. I tried to
> >>>>reduce/eliminate the words 'decision making', to the extent
> >>>>possible, in order to avoid any misunderstanding with respect to
> >>>>ICG's limited role of coordination .. I'm open to better language
> >>>>and flexible to revert back to the original text if so agreed ..
> >>>>
> >>>>Finally I just want to note that this does not exclude that feedback
> >>>>from the GAC may still be received when GAC discussions are
> >>>>concluded ..
> >>>>
> >>>>Kind Regards
> >>>>--Manal
> >>>>
> >>>>-----Original Message-----
> >>>>From: internal-cg-bounces at icann.org
> >>>>[mailto:internal-cg-bounces at icann.org]
> >>>>On Behalf Of Lynn St.Amour
> >>>>Sent: Monday, August 18, 2014 2:48 AM
> >>>>To: Internal-cg at icann.org
> >>>>Subject: Re: [Internal-cg] Consensus building process
> >>>>
> >>>>Hi everyone,
> >>>>
> >>>>as someone just coming back online, thanks to all who have been so
> >>>>thoughtful (and active).
> >>>>
> >>>>I would really like to support Martin's points. Also noting, that
> >>>>if we have substantial and consequential differences with respect to
> >>>>the final proposal - there will not be any agreement (whether we
> >>>>vote or call consensus).
> >>>>
> >>>>At the same time, it seems we might be slipping into thinking that
> >>>>we will
> >>>>have major autonomous decisions to make. Given our task is to
> >>>>coordinate/assimilate proposals from 3 different communities (for
> >>>>largely administrative work that is being done very well today), the
> >>>>main work of reaching agreement should be in the communities. If
> >>>>there are substantial differences, they will have to sort them out
> >>>>at the source.
> >>>>
> >>>>What am I mis-understanding?
> >>>>
> >>>>Best,
> >>>>
> >>>>Lynn
> >>>>
> >>>>
> >>>>On Aug 15, 2014, at 1:10 PM, Martin Boyle
> >>>><Martin.Boyle at nominet.org.uk>
> >>>>wrote:
> >>>>
> >>>>> Hi Joe,
> >>>>>
> >>>>> I am concerned by the return to the idea of supermajorities
> >>>>> overruling significantly affected parties. I do not like recourse
> >>>>> to voting (for reasons that I have already explained), and
> >>>>> certainly not when it can be used to overrule legitimate concerns.
> >>>>>
> >>>>> First, I agree with your division between non-substantial (those
> >>>>>not related to the final proposal, but focussed on our ways of
> >>>>>working, charter, even the RFP) and the substantial (related to
> >>>>>proposals).
> >>>>>
> >>>>> For your hyper-majority proposal (which reminds me of EU formulae
> >>>>>for Council decisions - and that's not an accolade!), what is the
> >>>>>percentage?
> >>>>> I gave some thresholds in my original mail on this issue. What
> >>>>>happens if one of the dissenting organisations were to be the gTLDs?
> >>>>>Or the ccTLDs?
> >>>>> (Interestingly, I don't think such a mess would happen in the case
> >>>>>for numbers or protocols.)
> >>>>>
> >>>>> And being voted against won't solve the problem because you won't
> >>>>>have addressed the specific concerns of the beaten party who would
> >>>>>then lobby against the solution showing that we do not have a
> >>>>>consensus proposal.
> >>>>>
> >>>>> Essentially, I see a distinct risk of a formulaic approach leading
> >>>>> to a risk of marginalising particular interests simply because
> >>>>> they don't fit the model others might prefer.
> >>>>>
> >>>>> I would note that the role of the ICG is to represent the wider
> >>>>>community.
> >>>>> However, we are not elected by them, but appointed by our
> >>>>>communities and accountability to those communities. The chair's
> >>>>>role is to try to pull together consensus, ensuring that serious
> >>>>>concerns are properly considered and that the output is something
> >>>>>that works for all and where there are appropriate safeguards. I
> >>>>>agree that the discussion can't keep going around in loops (hence
> >>>>>the need for us to justify our positions) and sometimes there will
> >>>>>be a final dissenting voice who does need to be given a say in the
> >>>>>final document.
> >>>>>
> >>>>> 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:07
> >>>>> To: internal-cg at icann.org
> >>>>> Subject: Re: [Internal-cg] Consensus building process
> >>>>>
> >>>>> Colleagues:
> >>>>>
> >>>>> Perhaps we can consider a different dividing line on consensus. I
> >>>>>would suggest that we have two main buckets, that which is related
> >>>>>to a proposal and that which is related to our operations. For
> >>>>>operations 2/3 of those expressing an opinion is sufficient to
> >>>>>arrive at decisions, but for issues related to proposals we need
> >>>>>more than
> >>>>> 2/3 (other percent?) of all members with no more than 2
> >>>>>participating organizations dissenting. The role of the chair would
> >>>>>thus be constrained by rules regarding when consensus is achieved,
> >>>>>but the chair would have the ability to manage discussion or call
> >>>>>for a formal vote if they believed it would help move us towards
> >>>>>consensus.
> >>>>>
> >>>>> Slightly less complex and perhaps more action-oriented.
> >>>>>
> >>>>> Joe
> >>>>> On 8/14/2014 2:26 PM, James M. Bladel wrote:
> >>>>> Agree. "Consensus" is not equivalent to "Unanimity."
> >>>>>
> >>>>> J.
> >>>>>
> >>>>>
> >>>>> From: <Drazek>, Keith Drazek <kdrazek at verisign.com>
> >>>>> Date: Thursday, August 14, 2014 at 13:10
> >>>>> To: ICG List <internal-cg at icann.org>
> >>>>> 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]
> >>>>> 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
> >>>>> Sent: Thursday, August 14, 2014 7:22 PM
> >>>>> To: WUKnoben
> >>>>> Cc:Milton L Mueller ; Martin Boyle ; Coordination Group
> >>>>> 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
> >>>>> Sent: Tuesday, August 12, 2014 8:12 PM
> >>>>> To: 'Martin Boyle' ; Coordination Group
> >>>>> 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]
> >>>>> 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 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 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
More information about the Internal-cg
mailing list