Re: [Internal-cg] Consensus building process
Alissa: Are liaisons participants but not members? Joe ----- Original Message ----- From: alissa@cooperw.in To: mnuduma@yahoo.com, martin.boyle@nominet.org.uk, internal-cg@icann.org Sent: Thursday, August 28, 2014 5:56:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Internal-cg] Consensus building process Mary, Martin, all, I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own. But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable. That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter. Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used. Alissa On 8/27/14, 4:26 AM, "mnuduma@yahoo.com" <mnuduma@yahoo.com> wrote:
All I am sorry, if I missed some views or threads. I have same concerns as raised by Martin. A mere footnote of a minority objections, say 10% or whatever number that may be, can hardly be acceptable on substantive issues by those on that side of the divide. I think ICG should strive at having consensus in all issues and go to voting as a last resort, and where it becomes impossible to reach, the minority view should form part of the main report/proposal, including the rationale for the objections. I am being curious here: why have we changed "members" to 'Participants', any compelling reasons? Mary Uduma
Sent from my BlackBerry wireless device from MTN
-----Original Message----- From: Martin Boyle <Martin.Boyle@nominet.org.uk> Sender: internal-cg-bounces@icann.org Date: Wed, 27 Aug 2014 08:30:22 To: Alissa Cooper<alissa@cooperw.in>; Internal-cg@icann.org<internal-cg@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: 27 August 2014 00:03 To: Internal-cg@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@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@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@t-online.de] Sent: Monday, August 18, 2014 10:43 PM To: Manal Ismail; Lynn St.Amour; Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Lynn St.Amour Sent: Monday, August 18, 2014 2:48 AM To: Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of joseph alhadeff Sent: 14 August 2014 20:07 To: internal-cg@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@verisign.com> Date: Thursday, August 14, 2014 at 13:10 To: ICG List <internal-cg@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@icann.org [mailto:internal-cg-bounces@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@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@icann.org [mailto:internal-cg-bounces@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@icann.org [mailto:internal-cg-bounces@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@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@icann.org [mailto:internal-cg-bounces@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@gmail.com> À: "Patrik Fältström" <paf@frobbit.se> Cc: "Coordination Group" <internal-cg@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@frobbit.se > :
On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben@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@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
No, that was not the intent of the change either. I don’t think we need to overly specify this. There is some name for the group of 30 — “members” is fine — and those people are involved in consensus decision-taking and counted for purposes of quorum. Liaisons are not. Alissa On 8/28/14, 5:55 PM, "Joe Alhadeff" <joseph.alhadeff@oracle.com> wrote:
Alissa:
Are liaisons participants but not members?
Joe ----- Original Message ----- From: alissa@cooperw.in To: mnuduma@yahoo.com, martin.boyle@nominet.org.uk, internal-cg@icann.org Sent: Thursday, August 28, 2014 5:56:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Internal-cg] Consensus building process
Mary, Martin, all,
I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own.
But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable. That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter.
Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used.
Alissa
On 8/27/14, 4:26 AM, "mnuduma@yahoo.com" <mnuduma@yahoo.com> wrote:
All I am sorry, if I missed some views or threads. I have same concerns as raised by Martin. A mere footnote of a minority objections, say 10% or whatever number that may be, can hardly be acceptable on substantive issues by those on that side of the divide. I think ICG should strive at having consensus in all issues and go to voting as a last resort, and where it becomes impossible to reach, the minority view should form part of the main report/proposal, including the rationale for the objections. I am being curious here: why have we changed "members" to 'Participants', any compelling reasons? Mary Uduma
Sent from my BlackBerry wireless device from MTN
-----Original Message----- From: Martin Boyle <Martin.Boyle@nominet.org.uk> Sender: internal-cg-bounces@icann.org Date: Wed, 27 Aug 2014 08:30:22 To: Alissa Cooper<alissa@cooperw.in>; Internal-cg@icann.org<internal-cg@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: 27 August 2014 00:03 To: Internal-cg@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@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@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@t-online.de] Sent: Monday, August 18, 2014 10:43 PM To: Manal Ismail; Lynn St.Amour; Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Lynn St.Amour Sent: Monday, August 18, 2014 2:48 AM To: Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of joseph alhadeff Sent: 14 August 2014 20:07 To: internal-cg@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@verisign.com> Date: Thursday, August 14, 2014 at 13:10 To: ICG List <internal-cg@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@icann.org [mailto:internal-cg-bounces@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@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@icann.org [mailto:internal-cg-bounces@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@icann.org [mailto:internal-cg-bounces@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@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@icann.org [mailto:internal-cg-bounces@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@gmail.com> À: "Patrik Fältström" <paf@frobbit.se> Cc: "Coordination Group" <internal-cg@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@frobbit.se > :
On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben@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@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Dear All, I understand from Alissa ,s reply that we continue to refer to MEMBER and NOT TO PARTICIPANT Regards Kavouss 2014-08-29 17:51 GMT+02:00 Alissa Cooper <alissa@cooperw.in>:
No, that was not the intent of the change either.
I don’t think we need to overly specify this. There is some name for the group of 30 — “members” is fine — and those people are involved in consensus decision-taking and counted for purposes of quorum. Liaisons are not.
Alissa
On 8/28/14, 5:55 PM, "Joe Alhadeff" <joseph.alhadeff@oracle.com> wrote:
Alissa:
Are liaisons participants but not members?
Joe ----- Original Message ----- From: alissa@cooperw.in To: mnuduma@yahoo.com, martin.boyle@nominet.org.uk, internal-cg@icann.org Sent: Thursday, August 28, 2014 5:56:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Internal-cg] Consensus building process
Mary, Martin, all,
I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own.
But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable. That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter.
Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used.
Alissa
On 8/27/14, 4:26 AM, "mnuduma@yahoo.com" <mnuduma@yahoo.com> wrote:
All I am sorry, if I missed some views or threads. I have same concerns as raised by Martin. A mere footnote of a minority objections, say 10% or whatever number that may be, can hardly be acceptable on substantive issues by those on that side of the divide. I think ICG should strive at having consensus in all issues and go to voting as a last resort, and where it becomes impossible to reach, the minority view should form part of the main report/proposal, including the rationale for the objections. I am being curious here: why have we changed "members" to 'Participants', any compelling reasons? Mary Uduma
Sent from my BlackBerry wireless device from MTN
-----Original Message----- From: Martin Boyle <Martin.Boyle@nominet.org.uk> Sender: internal-cg-bounces@icann.org Date: Wed, 27 Aug 2014 08:30:22 To: Alissa Cooper<alissa@cooperw.in>; Internal-cg@icann.org<internal-cg@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: 27 August 2014 00:03 To: Internal-cg@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@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@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@t-online.de] Sent: Monday, August 18, 2014 10:43 PM To: Manal Ismail; Lynn St.Amour; Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Lynn St.Amour Sent: Monday, August 18, 2014 2:48 AM To: Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of joseph alhadeff Sent: 14 August 2014 20:07 To: internal-cg@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@verisign.com> Date: Thursday, August 14, 2014 at 13:10 To: ICG List <internal-cg@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@icann.org [mailto:internal-cg-bounces@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@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@icann.org [mailto:internal-cg-bounces@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@icann.org [mailto:internal-cg-bounces@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@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@icann.org [mailto:internal-cg-bounces@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@gmail.com> À: "Patrik Fältström" <paf@frobbit.se> Cc: "Coordination Group" <internal-cg@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@frobbit.se > :
On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben@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@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Dear Alissa, I read again your message below and have some comments are included below each of the paragraph of your message " Mary, Martin, all,
I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own.
Comments I do not think views of 14 people or persons should be seen as minority views Consequently the quorum of simple majority should be changed to SUPER majoriy of atleast 2/ 3 or 4/ 5 Please note letters sent by to Chairman and President of ICANN by US
But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable.That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter.
Comments You missed the points What we are trying to say is we MUST make utmost efforts to reach consensus. Imagine a case that minority( in your analysis 14 out of 30 ) are from Naming, numbers and protocol ( three operational communities) do you still want to send the outcome of the ICG objected by these three main communities to NTIA and just attaching their objections? THAT DOES NOT WORK
Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used.
Comments We are referred to in many published and publicly available information as ICG Members. Therefroe we should not change that .Your argument that without being associated with an organisartion we are not eligible or qualified to be referred as Members .That argument does not have any logic or rational Additional Comments You might be very tired and overloaded as you became more and more inflexible and commanding We should work together. I am not in agreement with any one whe or she uses the term " I INSIST" .There no insistancy at all in this process. We should cooperate , collaborate and negotiate with each other Regards Kavouss
Alissa"
2014-08-29 18:04 GMT+02:00 Kavouss Arasteh <kavouss.arasteh@gmail.com>:
Dear All, I understand from Alissa ,s reply that we continue to refer to MEMBER and NOT TO PARTICIPANT Regards Kavouss
2014-08-29 17:51 GMT+02:00 Alissa Cooper <alissa@cooperw.in>:
No, that was not the intent of the change either.
I don’t think we need to overly specify this. There is some name for the group of 30 — “members” is fine — and those people are involved in consensus decision-taking and counted for purposes of quorum. Liaisons are not.
Alissa
On 8/28/14, 5:55 PM, "Joe Alhadeff" <joseph.alhadeff@oracle.com> wrote:
Alissa:
Are liaisons participants but not members?
Joe ----- Original Message ----- From: alissa@cooperw.in To: mnuduma@yahoo.com, martin.boyle@nominet.org.uk, internal-cg@icann.org Sent: Thursday, August 28, 2014 5:56:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Internal-cg] Consensus building process
Mary, Martin, all,
I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own.
But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable. That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter.
Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used.
Alissa
On 8/27/14, 4:26 AM, "mnuduma@yahoo.com" <mnuduma@yahoo.com> wrote:
All I am sorry, if I missed some views or threads. I have same concerns as raised by Martin. A mere footnote of a minority objections, say 10% or whatever number that may be, can hardly be acceptable on substantive issues by those on that side of the divide. I think ICG should strive at having consensus in all issues and go to voting as a last resort, and where it becomes impossible to reach, the minority view should form part of the main report/proposal, including the rationale for the objections. I am being curious here: why have we changed "members" to 'Participants', any compelling reasons? Mary Uduma
Sent from my BlackBerry wireless device from MTN
-----Original Message----- From: Martin Boyle <Martin.Boyle@nominet.org.uk> Sender: internal-cg-bounces@icann.org Date: Wed, 27 Aug 2014 08:30:22 To: Alissa Cooper<alissa@cooperw.in>; Internal-cg@icann.org<internal-cg@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: 27 August 2014 00:03 To: Internal-cg@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@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@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@t-online.de] Sent: Monday, August 18, 2014 10:43 PM To: Manal Ismail; Lynn St.Amour; Internal-cg@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@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@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Lynn St.Amour Sent: Monday, August 18, 2014 2:48 AM To: Internal-cg@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@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@icann.org > [mailto:internal-cg-bounces@icann.org] > On Behalf Of joseph alhadeff > Sent: 14 August 2014 20:07 > To: internal-cg@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@verisign.com> > Date: Thursday, August 14, 2014 at 13:10 > To: ICG List <internal-cg@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@icann.org > [mailto:internal-cg-bounces@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@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@icann.org > [mailto:internal-cg-bounces@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@icann.org > [mailto:internal-cg-bounces@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@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@icann.org > [mailto:internal-cg-bounces@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@gmail.com> > À: "Patrik Fältström" <paf@frobbit.se> > Cc: "Coordination Group" <internal-cg@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@frobbit.se > : > > > > > On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben@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@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > _______________________________________________ > Internal-cg mailing list > Internal-cg@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > _______________________________________________ > Internal-cg mailing list > Internal-cg@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > _______________________________________________ > Internal-cg mailing list > Internal-cg@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > _______________________________________________ > Internal-cg mailing list > Internal-cg@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > > > > > _______________________________________________ > Internal-cg mailing list > Internal-cg@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > _______________________________________________ > Internal-cg mailing list > Internal-cg@icann.org > https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Dear Kavouss, I thought that I was generally in agreement with your mail below until I read your “Additional Comments.” Firstly I think that Alissa is doing an excellent job in trying to pull together some ideas for common ground and I appreciate the way she has patiently put up with my objections on this draft. While I agree with you that we should cooperate, collaborate and negotiate with each other, I think she is enabling this, including in gently trying to identify solutions and look for compromise ways forward. However, I object strongly to, and dissociate myself from, your comments about “very tired and overloaded” and “inflexible and commanding.” I think this is inappropriate language and not accurate either. Please can we keep the discussion on a polite and impersonal level? Martin From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Kavouss Arasteh Sent: 29 August 2014 18:09 To: Alissa Cooper Cc: Coordination Group Subject: Re: [Internal-cg] Consensus building process Dear Alissa, I read again your message below and have some comments are included below each of the paragraph of your message " Mary, Martin, all,
I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own.
Comments I do not think views of 14 people or persons should be seen as minority views Consequently the quorum of simple majority should be changed to SUPER majoriy of atleast 2/ 3 or 4/ 5 Please note letters sent by to Chairman and President of ICANN by US
But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable.That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter.
Comments You missed the points What we are trying to say is we MUST make utmost efforts to reach consensus. Imagine a case that minority( in your analysis 14 out of 30 ) are from Naming, numbers and protocol ( three operational communities) do you still want to send the outcome of the ICG objected by these three main communities to NTIA and just attaching their objections? THAT DOES NOT WORK
Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used.
Comments We are referred to in many published and publicly available information as ICG Members. Therefroe we should not change that .Your argument that without being associated with an organisartion we are not eligible or qualified to be referred as Members .That argument does not have any logic or rational Additional Comments You might be very tired and overloaded as you became more and more inflexible and commanding We should work together. I am not in agreement with any one whe or she uses the term " I INSIST" .There no insistancy at all in this process. We should cooperate , collaborate and negotiate with each other Regards Kavouss
Alissa"
2014-08-29 18:04 GMT+02:00 Kavouss Arasteh <kavouss.arasteh@gmail.com<mailto:kavouss.arasteh@gmail.com>>: Dear All, I understand from Alissa ,s reply that we continue to refer to MEMBER and NOT TO PARTICIPANT Regards Kavouss 2014-08-29 17:51 GMT+02:00 Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>: No, that was not the intent of the change either. I don’t think we need to overly specify this. There is some name for the group of 30 — “members” is fine — and those people are involved in consensus decision-taking and counted for purposes of quorum. Liaisons are not. Alissa On 8/28/14, 5:55 PM, "Joe Alhadeff" <joseph.alhadeff@oracle.com<mailto:joseph.alhadeff@oracle.com>> wrote:
Alissa:
Are liaisons participants but not members?
Joe ----- Original Message ----- From: alissa@cooperw.in<mailto:alissa@cooperw.in> To: mnuduma@yahoo.com<mailto:mnuduma@yahoo.com>, martin.boyle@nominet.org.uk<mailto:martin.boyle@nominet.org.uk>, internal-cg@icann.org<mailto:internal-cg@icann.org> Sent: Thursday, August 28, 2014 5:56:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Internal-cg] Consensus building process
Mary, Martin, all,
I would be fine to replace “small minority” with “minority.” That is, if a minority of any size — from 1 to 14 ICG reps — cannot have its objections accommodated after extended discussion, those objections should be documented and the group should move on. I would resist defining “small” in any other way, since again our numeric representation in the group is arbitrary and has unclear meaning of its own.
But if your request is that the ICG cannot progress a document that has an objection from any minority, or from an operational community minority — that, I believe, is not workable. That allows 1 or more ICG reps to prevent the ICG’s work from going forward. Specifically, it puts us in a situation where rather than sending a final proposal to NTIA with a fully explained objection from a minority, we would not be able to send anything at all. I think we have to be able to send something, even if all the IETF reps object, or all the numbering reps, or all the ccTLD reps, or all the naming reps, or any or all reps from another constituency. Sending nothing means that NTIA has to make a judgment of its own of whatever state our process ends in, rather than us informing them of the end state. I don’t see how the former is preferable to the latter.
Also, I was the one who did the “member”/“participant” switch — it seems quite strange to me to consider ourselves members since this is not a membership organization — but it’s obviously confusing so I’m happy for the term “members” to be used.
Alissa
On 8/27/14, 4:26 AM, "mnuduma@yahoo.com<mailto:mnuduma@yahoo.com>" <mnuduma@yahoo.com<mailto:mnuduma@yahoo.com>> wrote:
All I am sorry, if I missed some views or threads. I have same concerns as raised by Martin. A mere footnote of a minority objections, say 10% or whatever number that may be, can hardly be acceptable on substantive issues by those on that side of the divide. I think ICG should strive at having consensus in all issues and go to voting as a last resort, and where it becomes impossible to reach, the minority view should form part of the main report/proposal, including the rationale for the objections. I am being curious here: why have we changed "members" to 'Participants', any compelling reasons? Mary Uduma
Sent from my BlackBerry wireless device from MTN
-----Original Message----- From: Martin Boyle <Martin.Boyle@nominet.org.uk<mailto:Martin.Boyle@nominet.org.uk>> Sender: internal-cg-bounces@icann.org<mailto:internal-cg-bounces@icann.org> Date: Wed, 27 Aug 2014 08:30:22 To: Alissa Cooper<alissa@cooperw.in<mailto:alissa@cooperw.in>>; Internal-cg@icann.org<mailto:Internal-cg@icann.org><internal-cg@icann.org<mailto:internal-cg@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@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@icann.org>] On Behalf Of Alissa Cooper Sent: 27 August 2014 00:03 To: Internal-cg@icann.org<mailto:Internal-cg@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@cooperw.in<mailto:alissa@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@tra.gov.eg<mailto:manal@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@t-online.de<mailto:wolf-ulrich.knoben@t-online.de>] Sent: Monday, August 18, 2014 10:43 PM To: Manal Ismail; Lynn St.Amour; Internal-cg@icann.org<mailto:Internal-cg@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@icann.org<mailto:Internal-cg@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@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@icann.org>] On Behalf Of Lynn St.Amour Sent: Monday, August 18, 2014 2:48 AM To: Internal-cg@icann.org<mailto:Internal-cg@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@nominet.org.uk<mailto:Martin.Boyle@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@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@icann.org>] On Behalf Of joseph alhadeff Sent: 14 August 2014 20:07 To: internal-cg@icann.org<mailto:internal-cg@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@verisign.com<mailto:kdrazek@verisign.com>> Date: Thursday, August 14, 2014 at 13:10 To: ICG List <internal-cg@icann.org<mailto:internal-cg@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@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@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@t-online.de<mailto:wolf-ulrich.knoben@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@icann.org<mailto:From%3Ainternal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@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@icann.org<mailto:From%3Ainternal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@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@verisign.com<mailto:kdrazek@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@icann.org<mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org<mailto:internal-cg-bounces@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@gmail.com<mailto:kavouss.arasteh@gmail.com>> À: "Patrik Fältström" <paf@frobbit.se<mailto:paf@frobbit.se>> Cc: "Coordination Group" <internal-cg@icann.org<mailto:internal-cg@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@frobbit.se<mailto:paf@frobbit.se> > :
On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben@t-online.de<mailto:wolf-ulrich.knoben@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@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg _______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg
participants (4)
-
Alissa Cooper -
Joe Alhadeff -
Kavouss Arasteh -
Martin Boyle