[Internal-cg] Consensus building process
Alissa Cooper
alissa at cooperw.in
Fri Aug 29 17:33:00 UTC 2014
Hi Martin,
On 8/29/14, 10:16 AM, "Martin Boyle" <Martin.Boyle at nominet.org.uk> wrote:
>Alissa,
>
>My concern is not so much on the size of the minority, but that something
>that seriously impacts one group (and perhaps not others in the same way)
>where that group is opposing. Outvoting them does not constitute a
>solution.
>
>The original wording - related to the IANA customer community - puts the
>situation into context. I recognise this gave others some concerns,
>including to you.
>
>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
>
>
More information about the Internal-cg
mailing list