[Internal-cg] Consensus building process
Adiel Akplogan
adiel at afrinic.net
Sat Aug 23 13:37:16 UTC 2014
Agree.
- a.
On Aug 22, 2014, at 04:43 AM, Alissa Cooper <alissa at cooperw.in> wrote:
> One more item I forgot to mention — this document says nothing about the
> role of our two liaisons in decision-making. From my perspective I think
> the liaisons should be encouraged to engage in all discussions, but when
> it comes down to making consensus determinations, they should be recused.
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140823/6beb0adb/signature.asc>
More information about the Internal-cg
mailing list