[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