[Internal-cg] Consensus building process

mnuduma at yahoo.com mnuduma at yahoo.com
Wed Aug 27 11:26:50 UTC 2014


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