Yes, all the members should be there. JJS. ----- Mail original ----- De: "Milton L Mueller" <mueller@syr.edu> À: "Patrik Fältström" <paf@frobbit.se>, "Joe Alhadeff" <joseph.alhadeff@oracle.com> Cc: internal-cg@icann.org Envoyé: Samedi 9 Août 2014 17:56:51 Objet: Re: [Internal-cg] Session at ICANN-51 I believe that all ICG members present should be on stage for the entire thing. And authorized to speak or answer questions or intervene as required, bearing in mind that we need to trust the chair or someone she designates to do the initial summary. I think it’s important both symbolically and substantively to have everyone up there, equal status. --MM From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Patrik Fältström Sent: Saturday, August 9, 2014 2:23 AM To: Joe Alhadeff Cc: internal-cg@icann.org Subject: Re: [Internal-cg] Session at ICANN-51 My thinking: 1. Someone from ICG must do the initial summary, and I think that should be Alissa as the chair, or whoever she designates 2. ICG members should at least during the last open microphone part of the session be on the stage. Exactly how we have to work out when we know the seating arrangement on the stage (as that can not be changed between sessions, and for example ICANN board sessions do set the constraints) So yes, ICG members should be prepared on being on stage for a portion of the session. Patrik On 9 aug 2014, at 00:43, Joe Alhadeff < joseph.alhadeff@oracle.com > wrote: will there be speakers on behalf of ICG as a whole or just their constituencies? ----- Original Message ----- From: paf@frobbit.se To: internal-cg@icann.org Sent: Friday, August 8, 2014 10:04:23 AM GMT -05:00 US/Canada Eastern Subject: [Internal-cg] Session at ICANN-51 I got one comment (thanks Manal) and based on that I have submitted the following. > * Session title; Community Discussion with the ICG > * Brief session overview (extensive session overview and agenda > details can be provided closer to the date) The IANA Stewardship Transition Coordination Group (ICG) will, at the ICANN51 meeting in Los Angeles, have a discussion with the community on various aspects of the transition. The schedule for the session is as follows: - 15 min update from ICG - 30 min update from coordinated proposals, 5 min. each. To plan the session accordingly and accommodate max number of requests, groups are required to make themselves known to the ICG in advance, highlighting their coordination activities and sending in proposals and/or material they intend to discuss - 45 minutes open microphone where issues are brought up by individuals from the floor and/or remote participants > * Number of attendees ( e.g. 150, 300, 500+) 500+ > * Date, time and duration (From Alice: "based on our experience, I > suggest holding the session on Wednesday as this timeframe will allow > communities to hold discussions in their respective meetings prior to > the session") Wednesday or Thursday 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

I do recognize that there is interest of having all ICG members on the stage for the full session. Even if in theory all 30 ICG members come...which will logistically be "interesting". :-) I will come back with more information and questions when I know the actual logistics and for example how furniture is placed "on the stage". Patrik On 9 aug 2014, at 18:14, Subrenat, Jean-Jacques <jjs@dyalog.net> wrote:

Yes, all the members should be there. JJS.

----- Mail original ----- De: "Milton L Mueller" <mueller@syr.edu> À: "Patrik Fältström" <paf@frobbit.se>, "Joe Alhadeff" <joseph.alhadeff@oracle.com> Cc: internal-cg@icann.org Envoyé: Samedi 9 Août 2014 17:56:51 Objet: Re: [Internal-cg] Session at ICANN-51

I believe that all ICG members present should be on stage for the entire thing. And authorized to speak or answer questions or intervene as required, bearing in mind that we need to trust the chair or someone she designates to do the initial summary.

I think it’s important both symbolically and substantively to have everyone up there, equal status.

--MM

From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Patrik Fältström Sent: Saturday, August 9, 2014 2:23 AM To: Joe Alhadeff Cc: internal-cg@icann.org Subject: Re: [Internal-cg] Session at ICANN-51

My thinking:

1. Someone from ICG must do the initial summary, and I think that should be Alissa as the chair, or whoever she designates

2. ICG members should at least during the last open microphone part of the session be on the stage. Exactly how we have to work out when we know the seating arrangement on the stage (as that can not be changed between sessions, and for example ICANN board sessions do set the constraints)

So yes, ICG members should be prepared on being on stage for a portion of the session.

Patrik

On 9 aug 2014, at 00:43, Joe Alhadeff < joseph.alhadeff@oracle.com > wrote:

will there be speakers on behalf of ICG as a whole or just their constituencies? ----- Original Message ----- From: paf@frobbit.se To: internal-cg@icann.org Sent: Friday, August 8, 2014 10:04:23 AM GMT -05:00 US/Canada Eastern Subject: [Internal-cg] Session at ICANN-51

I got one comment (thanks Manal) and based on that I have submitted the following. > * Session title; Community Discussion with the ICG > * Brief session overview (extensive session overview and agenda > details can be provided closer to the date) The IANA Stewardship Transition Coordination Group (ICG) will, at the ICANN51 meeting in Los Angeles, have a discussion with the community on various aspects of the transition. The schedule for the session is as follows: - 15 min update from ICG - 30 min update from coordinated proposals, 5 min. each. To plan the session accordingly and accommodate max number of requests, groups are required to make themselves known to the ICG in advance, highlighting their coordination activities and sending in proposals and/or material they intend to discuss - 45 minutes open microphone where issues are brought up by individuals from the floor and/or remote participants > * Number of attendees ( e.g. 150, 300, 500+) 500+ > * Date, time and duration (From Alice: "based on our experience, I > suggest holding the session on Wednesday as this timeframe will allow > communities to hold discussions in their respective meetings prior to > the session") Wednesday or Thursday 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

ICANN meetings have had groups as large as that in the front of the room before. It is not a big deal.

-----Original Message----- I do recognize that there is interest of having all ICG members on the stage for the full session. Even if in theory all 30 ICG members come...which will logistically be "interesting". :-)

I will come back with more information and questions when I know the actual logistics and for example how furniture is placed "on the stage".

Patrik

Dear All, Every moment we received a new thought. Somebody stated that The Role of the chair is purely administrative and NOT DECISION MAKING Another person stated that Quote " It is the role of the Chair to designate that consensus is reached and announce this designation to the ICG. Member(s) of the ICG should be able to challenge the designation of the Chair as part of the discussion. If several participants in the ICG disagree with the designation given to a position by the Chair or any other consensus call, they may follow these steps sequentially: 1. Send email to the Chair, copying the ICG explaining why the decision is believed to be in error. 2. If the Chair still disagrees with the complainants, the Chair must explain his or her reasoning in the response to the complainants. Any ICG member that believes that his/her contributions are being systematically ignored or discounted or wants to appeal a decision of the ICG should discuss the circumstances with the ICG Chair/Co-Chairs" Unquote. I am sorry these are incoherent with each other In particular, when there is no precedure that an ICG memebr acts against the chair,s ruling and until that objection not settled staisfactorily , the objection agianst ruling continued to prevail . What does it mean that " If several participants in the ICG disagree with the designation given to a position by the Chair or any other consensus call, they may follow these steps sequentially: 1. Send email to the Chair, copying the ICG explaining why the decision is believed to be in error. 2. If the Chair still disagrees with the complainants, the Chair must explain his or her reasoning in the response to the complainants" Too much power is given to the chair and thus she or he does not have purely adm,inistrative and logestic role.rather has dominating role This may not be correct Tks Kavouss 2014-08-10 22:58 GMT+02:00 WUKnoben <wolf-ulrich.knoben@t-online.de>:

Dear colleagues,

referring to my related E-Mail some days ago I herewith put a draft proposal for the ICG decision making process (see attached) to the dropbox and welcome your edits/comments/amendments.

The proposal is mainly based on my GNSO expertise and the process used generally in GNSO Working Groups. My thinking is:

- we do not have to reinvent a fully new process rather we can use the experience all of us have gained in the international environment - we should find to a common understanding of "consensus"

I'd like to encourage you to point out in your view

- what may be wrong with this process proposed - what may be missing - what may be questionnable or cause misunderstanding

In the end the agreed outcome could be annexed to the ICG charter.

Best regards

Wolf-Ulrich _______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

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

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

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

Keith:

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.

We have one deliverable -- the proposal to NTIA. We cannot deliver the majority proposal and a minority statement. We need a proposal that is supported by the global multistakeholder community. Russ

I hope you enjoyed your vacation. Well said. Thanks for pulling the various threads together. Russ On Aug 18, 2014, at 9:05 AM, Jari Arkko wrote:

I’m back from my vacation, thank you all for working hard on the ICG in the last couple of weeks.

And I wanted to make a couple of observations on this thread.

First, Russ was right in saying that we have one deliverable, and it is one that needs to be broadly supported by the global multistakeholder community. No such support implies no proposal and no transition*. But we want that transition to happen. So. We need to work towards some form of broad support, and being able to show that. It is the only thing we need to do, and it is very important.

Second, I wanted to emphasise what Lynn said:

...

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.

Third, I would not like us to get confused by words. Milton has correctly reminded us of the dangers of loose terminology. The IETF term is rough consensus, not consensus, and rough consensus is also the term that we used in the charter. We should of course strive for full consensus, but I think the group has so far been consistent in stating that full consensus (unanimity) is too high bar. In my personal opinion unanimity requirement would prevent the completion of the transition, as there is likely to be someone who disagrees. But we do need nevertheless a truly broad support for the proposal, as well as support of the IANA customers. We can choose to show that broad support in different ways. I have been calling to use the rough consensus model and term. There are other possible terms and other possible decision mechanisms, and I have no strong opinion on which one we should do. But for information, I wanted to explain the difference between (super)majority voting and IETF rough consensus. In the IETF context, as explained in RFC 7282, rough consensus means a process where all concerns are understood and addressed to the extent seen as necessary by the group, rather than merely voting minority opinions away. That is, the emphasis is on understanding all issues and deciding how important they are, rather than specific voting numbers. I’d like some aspect of that to remain in the ICG process as well.

Fourth, I agree with Alissa’s concern that we need a process that terminates and that can be practically executed. And I don’t know how to interpret substantial vs. non-substantial, serious, firm, strong, etc.

My current thinking is that we are too focused on the ICG’s role and its voting procedures. We are not the centre of the universe, the communities are. If the names, numbers, and protocols communities think the proposal is good and majority of us agrees after a discussion and revision, we have a go. Otherwise we do not. And documenting minority view is in my view natural, and it does not take weight away from a broadly supported proposal.

Personally, I wonder if we could condense the principles to the following:

· The aim of the discussion should be to try to find a solution where no member of the ICG maintains an opposition to the outcome. Reasons for objections should be given, allowing the communities and the ICG wherever possible to try to address those concerns. All objections need to be understood and discussed to determine their validity and the possible remedies. · After this process, the ICG can recommend a solution if at most a small minority disagrees, but most agree and no IANA customer group is opposed.

Jari

*) At least not different from the status quo… some of us feel fairly transitioned already :-)

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

Dear all, I have added some revisions to the critical section 4 of this document, by way of edits to the “alternative" text. In addition, I’ve taken a bold and foolish step in proposing a possible definition of “rough consensus” for the purposes of this exercise: · [After this process, the IGC may reach a “rough consensus” with the support of 4/5 of the members of the entire ICG, including 100% of IANA customer community members. In this case all dissenting views will be noted and included in the conclusion.] The document is located on Dropbox here: https://www.dropbox.com/s/yjmb78cp6ln7mmb/ICG-Consensus%20Building_draft_v3.... Paul. ________________________________________________________________________ Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100 See you at APNIC 38! http://conference.apnic.net/38 On 19 Aug 2014, at 9:39 am, WUKnoben <wolf-ulrich.knoben@t-online.de> wrote:

Thanks Jarri for these useful comments. I've inserted your proposed text re the principles as alternative to the one proposed by Martin that we could better discuss it tomorrow.

We should also discuss the question of "minority view". Can we define minority in quantity (number of members) or in quality or both? Since the recommendation level designation shall be defined by this minority.

I've also added a small paragraph describing that the ICG is "acting" at meetings with a quorum. This quorum - preset as simple majority of the ICG members - should also be discussed.

The updated draft is available at the dropbox to be used for the adobe presentation.

Best regards

Wolf-Ulrich

-----Ursprüngliche Nachricht----- From: Jari Arkko Sent: Monday, August 18, 2014 3:05 PM To: Coordination Group Subject: Re: [Internal-cg] Consensus building process

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg <ICG-Consensus Building_draft_v3.doc>_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

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> [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

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 <mueller@syr.edu> *Sent:* Tuesday, August 12, 2014 8:12 PM *To:* 'Martin Boyle' <Martin.Boyle@nominet.org.uk> ; Coordination Group <internal-cg@icann.org> *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 <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

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<mailto:kavouss.arasteh@gmail.com> Sent: Thursday, August 14, 2014 7:22 PM To: WUKnoben<mailto:wolf-ulrich.knoben@t-online.de> Cc: Milton L Mueller<mailto:mueller@syr.edu> ; Martin Boyle<mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group<mailto:internal-cg@icann.org> 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<mailto:mueller@syr.edu> Sent: Tuesday, August 12, 2014 8:12 PM To: 'Martin Boyle'<mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group<mailto:internal-cg@icann.org> 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> [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: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

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] *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 <mailto:kavouss.arasteh@gmail.com>

*Sent:*Thursday, August 14, 2014 7:22 PM

*To:*WUKnoben <mailto:wolf-ulrich.knoben@t-online.de>

*Cc:*Milton L Mueller <mailto:mueller@syr.edu> ; Martin Boyle <mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group <mailto:internal-cg@icann.org>

*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 <mailto:mueller@syr.edu>

*Sent:*Tuesday, August 12, 2014 8:12 PM

*To:*'Martin Boyle' <mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group <mailto:internal-cg@icann.org>

*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> [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: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 https://mm.icann.org/mailman/listinfo/internal-cg

All, I find some of this discussion refreshing, and important, because we will most certainly end up in these kind of corner case situations one day or another. That said, I do not think we can envision all different cases. Further, I think we have to separate the question on whether people agree or disagree to "the main proposal" from agreeing or disagreeing to "the conclusion of the discussion" (which might include information about minority views etc). Yes, we are to deliver _one_ proposal, but even one proposal might include various wordings [based on minority views] that round off the corners so that the actual product from ICG might be acceptable, while "the main path" might not be. Because of this, I am like Martin nervous over voting, because it will most certainly for many reasons be hard to vote about some text. Instead, we will have to work with multiple versions until our chair do declare the text be as good as it can be [I am not to declare or repeat what the basis should be for that decision]. Yes, it will be hard, but I do feel we do understand all of us we in this group want to get some deliveries. And not deadlock. So I am optimistic. Patrik On 15 aug 2014, at 19:10, 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

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

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

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

Agree fully. Keith On Aug 21, 2014, at 8:44 PM, "Alissa Cooper" <alissa@cooperw.in> wrote:

One more item I forgot to mention — this document says nothing about the role of our two liaisons in decision-making. From my perspective I think the liaisons should be encouraged to engage in all discussions, but when it comes down to making consensus determinations, they should be recused.

Alissa

On 8/21/14, 5:13 PM, "Alissa Cooper" <alissa@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

Agree. - a. On Aug 22, 2014, at 04:43 AM, Alissa Cooper <alissa@cooperw.in> wrote:

One more item I forgot to mention — this document says nothing about the role of our two liaisons in decision-making. From my perspective I think the liaisons should be encouraged to engage in all discussions, but when it comes down to making consensus determinations, they should be recused.

Alissa

On 8/21/14, 5:13 PM, "Alissa Cooper" <alissa@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

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

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

Hi Martin, On 8/29/14, 10:16 AM, "Martin Boyle" <Martin.Boyle@nominet.org.uk> wrote:

Alissa,

My concern is not so much on the size of the minority, but that something that seriously impacts one group (and perhaps not others in the same way) where that group is opposing. Outvoting them does not constitute a solution.

The original wording - related to the IANA customer community - puts the situation into context. I recognise this gave others some concerns, including to you.

I'm pretty sure that it is a fairly unlikely scenario, but other communities should not be able to force a solution that overrides the concerns of the directly affected party(ies). Essentially, if the ccTLD members say "no" to something proposed for the root-zone file that directly and only affects ccTLD entries, surely that should not be overridden?

Ah, now I understand your concern, and I agree.

So trying to find a way forward:

1. I'm ok with the term "small minority" which allows some debate at the time over what small means. I could not accept "if a minority disagrees" for reasons I've outlined before, that it does not really reflect the need to find a suitable compromise.

2. Add something along the lines of, "It is not expected that the representatives of an operational community significantly and directly affected by a conclusion would be overruled in this process."

Would this approach be acceptable to colleagues?

This works for me. Thanks, Alissa

As I say, I think that this is an unlikely scenario - we should have been able to find a compromise by then - but I am not convinced that a footnote from the affected operational community saying that, and identifying why, the approach was unacceptable to that community would be considered to be a viable proposal.

Hope this helps

Martin

-----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: 28 August 2014 22:56 To: mnuduma@yahoo.com; Martin Boyle; Internal-cg@icann.org 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

Oh, now I see that Alissa's mind was already changed, so my last message was unnecessary --MM

-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-

...

I'm pretty sure that it is a fairly unlikely scenario, but other communities should not be able to force a solution that overrides the concerns of the directly affected party(ies). Essentially, if the ccTLD members say "no" to something proposed for the root-zone file that directly and only affects ccTLD entries, surely that should not be overridden?

Ah, now I understand your concern, and I agree.

...

So trying to find a way forward:

1. I'm ok with the term "small minority" which allows some debate at the time over what small means. I could not accept "if a minority disagrees" for reasons I've outlined before, that it does not really reflect the need to find a suitable compromise.

2. Add something along the lines of, "It is not expected that the representatives of an operational community significantly and directly affected by a conclusion would be overruled in this process."

Would this approach be acceptable to colleagues?

This works for me.

Thanks, Alissa

...

As I say, I think that this is an unlikely scenario - we should have been able to find a compromise by then - but I am not convinced that a footnote from the affected operational community saying that, and identifying why, the approach was unacceptable to that community would be considered to be a viable proposal.

Hope this helps

Martin

-----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: 28 August 2014 22:56 To: mnuduma@yahoo.com; Martin Boyle; Internal-cg@icann.org 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 agree with Martin that while Members are understood to be referred as participants but participants are not understood to be members The ICG as announced composed of members and NOT PARTICIPANTS I THEREFROE REQUEST TO GO BACK TO MEMBERS I have other comments which is included in the text One important issue is that any Quorum should be super majority ( 2/3) and not simple majority. For such an important issue ,simple majority is inappropriate as with 49 % of members in disagreement position ,the conclusion is not valid I made some other changes ,see attachemnt Regards Kavouss 2014-08-27 10:30 GMT+02:00 Martin Boyle <Martin.Boyle@nominet.org.uk>:

Hi Alissa,

Thanks for your revised text.

I still have concerns over minority views where a group is seriously impacted by the decision. I've noted before that, for the names part of the equation, the ccTLD or the GNSO community could be in a significant minority. As a result, any recommendation coloured by a footnote objection from that community would hardly be a solution.

That obviously depends on what we mean by small minority (less than 10% would meet my concerns, but might not meet concerns of others).

I've made a few changes that try to clarify the meaning of the text. However, I'm bemused by the (partial) change from the term "members" to "participants." I can see that we do not want to non-participants to be dominant in the committee for counting purposes, but we do not spell the consequences out.

Best

Martin

-----Original Message----- From: internal-cg-bounces@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

Keith On the “holdout” problem, I think Martin’s principles addressed your concerns. To reproduce them here: · 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.* Note these two things: 1) If there really is no consensus (and that DOES mean no one objects, even if they don’t fully agree) then we are reverting to a kind of supermajority voting or decision rule as outlined in the GNSO rules. Purists like me refuse to call this “consensus.” It doesn’t mean that we are “stuck” or blocked, it just means that we really don’t have something that conforms to the classical meaning of consensus. I think we should not play verbal games and call this “consensus.” 2) IANA customer groups (groups, not individuals) have a kind of special status in Martin’s principles, given their direct stake in how IANA is managed. Even though I am not representing a customer group, I think this is fair. If everyone in a particular customer group cannot live with a decision, it is certainly not consensus and we probably shouldn’t force such a decision on them, no matter how much everyone else supports it. We might extend the same kind of protection to other groups; e.g., if none of the user representatives (NCSG and ALAC) agree, it would seem unreasonable to claim that an outcome has even “rough” consensus. But if one particular individual within that user group can’t be swayed, then it should not be considered the same kind of obstacle to an outcome. Hope this is clear Milton L Mueller Laura J and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Drazek, Keith Sent: Thursday, August 14, 2014 2:10 PM To: Coordination Group 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] 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<mailto:kavouss.arasteh@gmail.com> Sent: Thursday, August 14, 2014 7:22 PM To: WUKnoben<mailto:wolf-ulrich.knoben@t-online.de> Cc: Milton L Mueller<mailto:mueller@syr.edu> ; Martin Boyle<mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group<mailto:internal-cg@icann.org> 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<mailto:mueller@syr.edu> Sent: Tuesday, August 12, 2014 8:12 PM To: 'Martin Boyle'<mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group<mailto:internal-cg@icann.org> 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> [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: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

Dear Wolf Thank you very much for your kind reply. I suggest that we do not formally define the exceptional circumstances that we may wish to proceed if there is some level of disagreemnet I have been working in internatuional sensitive and delicate meetings and conférences and learned that we need to treat any issue which may face on a case by case basis and not generalized the matter. AS I mentioned before going to vote is one of the most democratic practice in international procedure. It should be avoided as musch as possible but not totally excluded .What remain is the criteria, simple majority or abolute majority which may be 2/3 or 4/5 as both practices are used by all parlimentary circumstances Let us bear in mind the above but write it very cautiously Regards Kavouss 2014-08-14 21:19 GMT+02:00 joseph alhadeff <joseph.alhadeff@oracle.com>:

Milton:

I agree with the first bullet points, but have reservations on the last. I agree that no customer stakeholder objection related to the proposal can exist and still have a consensus, but I also think that we cannot have a consensus if a number of the non-customer stakeholders object.

Best-

Joe

On 8/14/2014 2:49 PM, Milton L Mueller wrote:

Keith

On the “holdout” problem, I think Martin’s principles addressed your concerns. To reproduce them here:

· 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.**

Note these two things:

1) If there really is no consensus (and that DOES mean no one objects, even if they don’t fully agree) then we are reverting to a kind of supermajority voting or decision rule as outlined in the GNSO rules. Purists like me refuse to call this “consensus.” It doesn’t mean that we are “stuck” or blocked, it just means that we really don’t have something that conforms to the classical meaning of consensus. I think we should not play verbal games and call this “consensus.”

2) IANA customer groups (groups, not individuals) have a kind of special status in Martin’s principles, given their direct stake in how IANA is managed. Even though I am not representing a customer group, I think this is fair. If everyone in a particular customer group cannot live with a decision, it is certainly not consensus and we probably shouldn’t force such a decision on them, no matter how much everyone else supports it. We might extend the same kind of protection to other groups; e.g., if none of the user representatives (NCSG and ALAC) agree, it would seem unreasonable to claim that an outcome has even “rough” consensus. But if one particular individual within that user group can’t be swayed, then it should not be considered the same kind of obstacle to an outcome.

Hope this is clear

Milton L Mueller

Laura J and L. Douglas Meredith Professor

Syracuse University School of Information Studies

http://faculty.ischool.syr.edu/mueller/

*From:* internal-cg-bounces@icann.org [ mailto:internal-cg-bounces@icann.org <internal-cg-bounces@icann.org>] *On Behalf Of *Drazek, Keith *Sent:* Thursday, August 14, 2014 2:10 PM *To:* Coordination Group *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 <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 <kavouss.arasteh@gmail.com>

*Sent:* Thursday, August 14, 2014 7:22 PM

*To:* WUKnoben <wolf-ulrich.knoben@t-online.de>

*Cc:* Milton L Mueller <mueller@syr.edu> ; Martin Boyle <Martin.Boyle@nominet.org.uk> ; Coordination Group <internal-cg@icann.org>

*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 <mueller@syr.edu>

*Sent:* Tuesday, August 12, 2014 8:12 PM

*To:* 'Martin Boyle' <Martin.Boyle@nominet.org.uk> ; Coordination Group <internal-cg@icann.org>

*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 <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 listInternal-cg@icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

Thanks Alissa, I understand your concerns - avoid deadlocks - be clear in where and when a discussion should end with a recommendation - detail the communication modalities - make the distinction between substantive/non-substantive issues clear It should be discussed on Tuesday next week since in parts it is related to the chair's power in driving the process. Re the communication modalities during the process I'd like to see it practically. As we intend to hold conference calls at least every 2 weeks decisions should be taken just there, and it should appear in advance under the related agenda item. The designation process can run in between via email etc. A quorum (for "substantive issues") could be simple majority (secretariat to evaluate!) including a simple majority attendance of the "customer groups". Let me think about a little more and come up with suggestions. But it seems the more we dive into the details the more complex the process shall evolve since everybody tends to cover eventualities. Best regards Wolf-Ulrich -----Ursprüngliche Nachricht----- From: Alissa Cooper Sent: Friday, August 15, 2014 2:05 AM To: joseph alhadeff ; internal-cg@icann.org Subject: Re: [Internal-cg] Consensus building process I think I have the opposite opinion on this. I think letting any group continue to object still allows the hold-out problem to cause us to result in deadlock. I think it would be preferable to set a deadline at which the final recommendation level designation will be made, and at that point if there are minority opinions, from a group or from an individual, those should be documented and published along with the main document. I don’t think any other option safeguards us from deadlock, whether it be inflicted by a group or an individual. And in particular for the case of sending a transition plan to NTIA, I don’t think deadlock is an option. Moreover, I don’t see how the “recommended method for discovering the recommendation level designation,” as outlined in Wolf-Ulrich’s draft, necessarily terminates. Step (iii) seems to allow individuals to make the process go in a circle repeatedly by objecting to the recommendation designation. Step (iv) discusses the use of polls, but does not specify how they should be used to arrive at a final outcome. Also, the document does not specify how consensus should be determined within our different modalities of communication — email, conference call, in person. Can we set comment periods with deadlines and, with no objections raised, make a recommendation designation via this mailing list? Can we do the same on a voice call — ask for objections and, hearing none, proceed? Can we hum when we’re in person? ;) Do we need to confirm hums on the mailing list (this is what we do in the IETF)? From an operational perspective, I was hoping this document would provide answers to these questions. I think it would also be helpful for the document to describe what is meant by “non-substantive” issues. From my perspective, I have no problem with us moving fairly quickly to a vote on personnel matters — chairs, who we choose for the secretariat, who will speak to the press, etc. — and deciding by simple majority. For documents we have to agree to publish or send (including the transition plan), I think we need a method that we know will terminate for agreeing on a recommendation level designation, and that allows for dissenting opinions to be simultaneously published. Those are the only two categories that I think we need. Finally, I think the most we can require as far as participation levels (quorum for decision-making) is simple majority. This is a volunteer activity, people will be busy at various times, and there may be some decisions where certain ICG participants have reasons for not engaging in the discussion. We shouldn’t set a standard for participation that we might not be able to meet. Alissa On 8/14/14, 12:19 PM, "joseph alhadeff" <joseph.alhadeff@oracle.com> wrote:

Milton:

I agree with the first bullet points, but have reservations on the last. I agree that no customer stakeholder objection related to the proposal can exist and still have a consensus, but I also think that we cannot have a consensus if a number of the non-customer stakeholders object.

Best-

Joe On 8/14/2014 2:49 PM, Milton L Mueller wrote:

Keith On the “holdout” problem, I think Martin’s principles addressed your concerns. To reproduce them here:

· 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.*

Note these two things:

1) If there really is no consensus (and that DOES mean no one objects, even if they don’t fully agree) then we are reverting to a kind of supermajority voting or decision rule as outlined in the GNSO rules. Purists like me refuse to call this “consensus.” It doesn’t mean that we are “stuck” or blocked, it just means that we really don’t have something that conforms to the classical meaning of consensus. I think we should not play verbal games and call this “consensus.” 2) IANA customer groups (groups, not individuals) have a kind of special status in Martin’s principles, given their direct stake in how IANA is managed. Even though I am not representing a customer group, I think this is fair. If everyone in a particular customer group cannot live with a decision, it is certainly not consensus and we probably shouldn’t force such a decision on them, no matter how much everyone else supports it. We might extend the same kind of protection to other groups; e.g., if none of the user representatives (NCSG and ALAC) agree, it would seem unreasonable to claim that an outcome has even “rough” consensus. But if one particular individual within that user group can’t be swayed, then it should not be considered the same kind of obstacle to an outcome.

Hope this is clear

Milton L Mueller Laura J and L. Douglas Meredith Professor

Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/

From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Drazek, Keith Sent: Thursday, August 14, 2014 2:10 PM To: Coordination Group 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 <mailto:kavouss.arasteh@gmail.com>

Sent: Thursday, August 14, 2014 7:22 PM

To:

WUKnoben <mailto:wolf-ulrich.knoben@t-online.de>

Cc: Milton L Mueller <mailto:mueller@syr.edu> ; Martin Boyle <mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group <mailto:internal-cg@icann.org>

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 <mailto:mueller@syr.edu>

Sent: Tuesday, August 12, 2014 8:12 PM

To:

'Martin Boyle' <mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group <mailto:internal-cg@icann.org>

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 <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

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.orghttps://mm.icann.org/mailman/listinfo/internal-cg

_______________________________________________ Internal-cg mailing list Internal-cg@icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

yes. Thanks. On 8/15/2014 12:25 PM, Martin Boyle wrote:

Hi Joe,

Yes, you are right. I thought my principle 3 was enough to resolve this: essentially there is an obligation on any party opposing (blocking) consensus to explain their concerns to allow those concerns to be addressed. Essentially this allows the issues to be addressed head on and resolved. On the other hand, overruling a maintained and solid objection would just lead to that coming back again later in the process.

It works for the hold-out case that Keith flags. For the substantive cases, though, the only defence I can see for a legitimate objection to be ignored through weigh of numbers is to allow that point to be specifically addressed in the final report (and I really am just talking about the final proposal and the process for getting there to be the only substantive issue we have).

If Wolf-Ulrich were to add to the end of principle 3, "If these concerns are not met in the final proposal, the opposing party should be invited to present the dissenting views in a written submission to the report.", would this work?

Cheers

Martin

*From:*internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] *On Behalf Of *joseph alhadeff *Sent:* 14 August 2014 20:20 *To:* internal-cg@icann.org *Subject:* Re: [Internal-cg] Consensus building process

Milton:

I agree with the first bullet points, but have reservations on the last. I agree that no customer stakeholder objection related to the proposal can exist and still have a consensus, but I also think that we cannot have a consensus if a number of the non-customer stakeholders object.

Best-

Joe

On 8/14/2014 2:49 PM, Milton L Mueller wrote:

Keith

On the "holdout" problem, I think Martin's principles addressed your concerns. To reproduce them here:

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.**

Note these two things:

1)If there really is no consensus (and that DOES mean no one objects, even if they don't fully agree) then we are reverting to a kind of supermajority voting or decision rule as outlined in the GNSO rules. Purists like me refuse to call this "consensus." It doesn't mean that we are "stuck" or blocked, it just means that we really don't have something that conforms to the classical meaning of consensus. I think we should not play verbal games and call this "consensus."

2)IANA customer groups (groups, not individuals) have a kind of special status in Martin's principles, given their direct stake in how IANA is managed. Even though I am not representing a customer group, I think this is fair. If everyone in a particular customer group cannot live with a decision, it is certainly not consensus and we probably shouldn't force such a decision on them, no matter how much everyone else supports it. We might extend the same kind of protection to other groups; e.g., if none of the user representatives (NCSG and ALAC) agree, it would seem unreasonable to claim that an outcome has even "rough" consensus. But if one particular individual within that user group can't be swayed, then it should not be considered the same kind of obstacle to an outcome.

Hope this is clear

Milton L Mueller

Laura J and L. Douglas Meredith Professor

Syracuse University School of Information Studies

http://faculty.ischool.syr.edu/mueller/

*From:*internal-cg-bounces@icann.org <mailto:internal-cg-bounces@icann.org> [mailto:internal-cg-bounces@icann.org] *On Behalf Of *Drazek, Keith *Sent:* Thursday, August 14, 2014 2:10 PM *To:* Coordination Group *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] *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 <mailto:kavouss.arasteh@gmail.com>

*Sent:*Thursday, August 14, 2014 7:22 PM

*To:*WUKnoben <mailto:wolf-ulrich.knoben@t-online.de>

*Cc:*Milton L Mueller <mailto:mueller@syr.edu> ; Martin Boyle <mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group <mailto:internal-cg@icann.org>

*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 <mailto:mueller@syr.edu>

*Sent:*Tuesday, August 12, 2014 8:12 PM

*To:*'Martin Boyle' <mailto:Martin.Boyle@nominet.org.uk> ; Coordination Group <mailto:internal-cg@icann.org>

*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> [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: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

Dear Milton I fully agree with your analysis and propose also to stop disputing with each other in trying to describe what is consensus and adding any positive, negative, rough ,soft ,or hartd to it Consensus is consensus according to international sustomary law . My understzanding of Consensus is as you described " everyone either agrees or agrees not to object" FULL STOP ,THE SHOW IS OVER.NO MORE DISCUSSION .NO MORE DISPUTE .CONSENSUS EMERGED ON WHAT IS CONSENSUS KAVOUSS 2014-08-12 20:16 GMT+02:00 Kavouss Arasteh <kavouss.arasteh@gmail.com>:

Dear Martin I do not clearly understand your illusion to WCIT. Please just tell me, what happened if the views of those dealing with naming, or numbers, or protocle remained a minority views and the rest are joining what do you call rough consensus. Let us imagine also that we go ahead with such soft consensus in which a valid views of one of these groups are not taken into account

Do you still believe that such a soft or rough consensus disregarding the views of one key player could be considered a valid outcome Pls comment. I am of the strong view that the chair should further and further discuss until we find a real ( not rough .not soft ,not hard ) consensus Kavouss

2014-08-12 19:23 GMT+02:00 Martin Boyle <Martin.Boyle@nominet.org.uk>:

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

Thanks Kavouss, you are right, there should be a mechanism imposed to settle the consensus designation dispute. Voting could be one means whereby the voting scheme has to be defined. Maybe there are other ideas... Best regards Wolf-Ulrich From: Kavouss Arasteh Sent: Monday, August 11, 2014 10:40 AM To: Patrik Fältström Cc: WUKnoben ; Coordination Group Subject: 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

On Aug 10, 2014, at 19:57 PM, Milton L Mueller <mueller@syr.edu> wrote:

ICANN meetings have had groups as large as that in the front of the room before. It is not a big deal.

Not a big deal, ut will it be effective? I doubt that 30 people on stage at the same will achieve anything really positive. Maybe an alternative will be to have 1 rep from each stakeholder group on stage and have the others seat in the front row of the room. When presenting all will be present and other not on stage can be allow to react and speak if really needed. - a.

-----Original Message-----

...

I do recognize that there is interest of having all ICG members on the stage for the full session. Even if in theory all 30 ICG members come...which will logistically be "interesting". :-)

I will come back with more information and questions when I know the actual logistics and for example how furniture is placed "on the stage".

Patrik

_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg

-----Original Message-----

Maybe an alternative will be to have 1 rep from each stakeholder group on stage and have the others seat in the front row of the room. When presenting all will be present and other not on stage can be allow to react and speak if really needed.

Nope.

Not a big deal, but will it be effective? I doubt that 30 people on stage at the same will achieve anything really positive.

1) It will provide equal recognition and visibility to everyone on the ICG. 2) it will show our diversity 3) it will completely avoid bias in selection and negate any sense that the ICG is under the control of a small faction