[Internal-cg] Consensus building process

Kavouss Arasteh kavouss.arasteh at gmail.com
Fri Aug 29 16:04:17 UTC 2014


Dear All,
I understand from Alissa ,s reply that we continue to refer to MEMBER and
NOT TO PARTICIPANT
Regards
Kavouss


2014-08-29 17:51 GMT+02:00 Alissa Cooper <alissa at cooperw.in>:

> No, that was not the intent of the change either.
>
> I don’t think we need to overly specify this. There is some name for the
> group of 30 — “members” is fine — and those people are involved in
> consensus decision-taking and counted for purposes of quorum. Liaisons are
> not.
>
> Alissa
>
> On 8/28/14, 5:55 PM, "Joe Alhadeff" <joseph.alhadeff at oracle.com> wrote:
>
> >Alissa:
> >
> >Are liaisons participants but not members?
> >
> >Joe
> >----- Original Message -----
> >From: alissa at cooperw.in
> >To: mnuduma at yahoo.com, martin.boyle at nominet.org.uk, internal-cg at icann.org
> >Sent: Thursday, August 28, 2014 5:56:11 PM GMT -05:00 US/Canada Eastern
> >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
>
>
> _______________________________________________
> 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/20140829/1fd9ced5/attachment.html>


More information about the Internal-cg mailing list