[Internal-cg] Consensus building process

Kavouss Arasteh kavouss.arasteh at gmail.com
Wed Aug 27 15:10:29 UTC 2014 

Dear All,
I have further analyzed the text and made/suggest further revision as rev.2
See attachment



2014-08-27 14:21 GMT+02:00 Kavouss Arasteh <kavouss.arasteh at gmail.com>:

> Dear All,
> I agree with Martin that while Members are understood to be referred as
> participants but participants are not understood to be members
> The ICG as announced composed of members and NOT PARTICIPANTS
> I THEREFROE REQUEST TO GO BACK TO MEMBERS
> I have other comments which is included in the text
> One important issue is that any Quorum should be super majority ( 2/3) and
> not simple majority.
> For such an important issue ,simple majority is inappropriate as with 49 %
> of members in disagreement position ,the conclusion is not valid
> I made some other changes ,see attachemnt
> Regards
> Kavouss
>
>
> 2014-08-27 10:30 GMT+02:00 Martin Boyle <Martin.Boyle at nominet.org.uk>:
>
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140827/03728928/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ICG-Consensus Building_draft_v4 + MB (1),REV 2 KA.doc
Type: application/msword
Size: 139776 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140827/03728928/ICG-ConsensusBuilding_draft_v4MB1REV2KA.doc>

More information about the Internal-cg mailing list