[Internal-cg] Consensus building process

Tue Aug 26 23:03:11 UTC 2014

I made a small change to at the bottom of page 1 in v4 to explain the role
of liaisons.

I haven’t seen any responses to the other changes, explained in my note
below. Any outstanding objections to the v4 version?

Thanks,
Alissa

On 8/21/14, 5:13 PM, "Alissa Cooper" <alissa at cooperw.in> wrote:

>Hi all,
>
>I have attached and uploaded to Dropbox a v4 that addresses my remaining
>concerns with the consensus document. It is based on the v3 that was
>uploaded by Paul earlier this week. Here is a summary of the changes and
>my rationales for them:
>
>1) Personnel decisions vs. All other decisions
>In section 4 I have created two subsections, one about personnel decisions
>and one about all other decisions. I have removed the language about
>“substantive” and “non-substantive” because it wasn’t clear to me what it
>meant and I think the actual meaningful distinction is personnel vs.
>non-personnel decisions. That is, for personnel decisions I think voting
>and going with the majority winner is fine; for all other decisions I do
>not think we should vote.
>
>As I mentioned in the chat window on the call, I don’t see how we can
>credibly vote on document approvals and other non-personnel matters since
>our numbers in terms of representation of constituencies (which themselves
>can be sliced and diced many different ways) are arbitrary.
>
>2) Hold-out problem
>As I stated before I was concerned about the language in the document that
>required all of the operational community representatives (or “IANA
>customers”) to be satisfied with every decision, because I believe this
>would allow one group to prevent the full ICG from moving forward. From my
>perspective the important parts are (i) that we spend sufficient time
>trying to accommodate objections, and (ii) that we document objections
>that cannot be accommodated. As long as we put in a serious effort at
>accommodation and objectors can explain in as much detail as they like why
>they object, I don’t think any individual or group should have the power
>to prevent our process from moving forward or to prevent us from sending a
>proposal to NTIA. I have therefore removed the language about satisfying
>all IANA customers.
>
>3) Principles
>I thought the second set of principles was clearer than the first, so I
>have kept the second and deleted the first. I do not believe we can put a
>numeric figure on “rough consensus” for the same reason that we should not
>be voting, and the term “rough consensus” does not otherwise appear in the
>document, so I removed the 4/5 requirement as well.
>
>4) Methodology
>I have made a number of suggestions to the methodology section. I propose
>as a first step that the chair/co-chairs set a time frame for discussion,
>which can be extended if necessary. I suggest that re-evaluation of a
>published designation only occur in light of serious objections to the
>designation — this should be an exceptional circumstance. I removed the
>notion that the designation would continue to be updated until everyone
>agrees with it because I don’t understand how that process would ever
>terminate. And I added more detail about the nature of polls.
>
>5) Appeal
>I removed the language about the ability for any participant to appeal a
>designation — again, I don’t understand how a decision-making process
>would terminate if there can be endless appeals, and if we go down the
>path of documenting objections, I don’t think this is necessary.
>
>6) Decision-making venues
>I think we should be able to make decisions on the mailing list
>(especially easy ones :-)) in addition to during meetings, so I added some
>words to that effect.
>
>7) Editorial
>I did a bunch of editorial clean-up.
>
>Thoughts?
>
>Alissa
>
>
>On 8/20/14, 11:12 AM, "Manal Ismail" <manal at tra.gov.eg> wrote:
>
>>Thanks Wolf-Ulrich and apologies for my late reply ..
>>I was already not fully satisfied with the language I suggested and was
>>open for better language ..
>>But in the absence of any, I'm ok with reverting back to the original
>>text ..
>>Thanks again for the heads up ..
>>Kind Regards
>>--Manal
>>-----Original Message-----
>>From: WUKnoben [mailto:wolf-ulrich.knoben at t-online.de]
>>Sent: Monday, August 18, 2014 10:43 PM
>>To: Manal Ismail; Lynn St.Amour; Internal-cg at icann.org
>>Subject: Re: [Internal-cg] Consensus building process
>>
>>Thanks Manal,
>>
>>I think we starting a bit mixing between charter related items and those
>>items related to these draft guidelines. The ICG role must definitely be
>>fixed in the charter. What is expressed in the guidelines can per se only
>>work within the limited role of the ICG. Whether it's "decision making"
>>or "conclusion" - this is just wording and needs common understanding.
>>But for me "administrative" decision making looks a bit confusing as it
>>could imply additional ICG guidelines for "other" decision making.
>>So for the latest draft version (v3) coming up I took the liberty, not to
>>accept your amendments in this respect.
>>
>>Best regards
>>
>>Wolf-Ulrich
>>
>>-----Ursprüngliche Nachricht-----
>>From: Manal Ismail
>>Sent: Monday, August 18, 2014 2:22 PM
>>To: Lynn St.Amour ; Internal-cg at icann.org
>>Subject: Re: [Internal-cg] Consensus building process
>>
>>I fully agree with Lynn that, within our task of
>>coordinating/assimilating proposals, we hopefully don't have major
>>autonomous decisions to make .. and if they exist, I believe, we should
>>try to revert back to the community, to the extent possible .. Yet,
>>having said that and within our administrative work, we may run into
>>different situations including:
>>
>>- All proposals received fit smoothly into one puzzle (theoretical best
>>case
>>scenario)
>>- Gaps/missing information needed to complete the consolidated proposal
>>(request missing information from the relevant community(ies))
>>- Overlaps with different proposals sharing the same view (easy
>>administrative work to come up with a single draft)
>>- Overlaps where the different proposals received suggest
>>different/opposite views (I believe, this where we need to agree how to
>>handle)
>>- Other possible scenarios ??
>>
>>Just thinking out loud ..
>>
>>Please note that I did some edits, marked in track changes, to
>>ICG-Consensus Building_draft_v2.doc (hope this is the right version) and
>>saved a new version with my initials appended .. I tried to
>>reduce/eliminate the words 'decision making', to the extent possible, in
>>order to avoid any misunderstanding with respect to ICG's limited role of
>>coordination .. I'm open to better language and flexible to revert back
>>to the original text if so agreed ..
>>
>>Finally I just want to note that this does not exclude that feedback from
>>the GAC may still be received when GAC discussions are concluded ..
>>
>>Kind Regards
>>--Manal
>>
>>-----Original Message-----
>>From: internal-cg-bounces at icann.org
>>[mailto:internal-cg-bounces at icann.org]
>>On Behalf Of Lynn St.Amour
>>Sent: Monday, August 18, 2014 2:48 AM
>>To: Internal-cg at icann.org
>>Subject: Re: [Internal-cg] Consensus building process
>>
>>Hi everyone,
>>
>>as someone just coming back online, thanks to all who have been so
>>thoughtful (and active).
>>
>>I would really like to support Martin's points.  Also noting, that if we
>>have substantial and consequential differences with respect to the final
>>proposal -  there will not be any agreement (whether we vote or call
>>consensus).
>>
>>At the same time, it seems we might be slipping into thinking that we
>>will 
>>have major autonomous decisions to make.   Given our task is to
>>coordinate/assimilate proposals from 3 different communities (for largely
>>administrative work that is being done very well today), the main work of
>>reaching agreement should be in the communities.  If there are
>>substantial differences, they will have to sort them out at the source.
>>
>>What am I mis-understanding?
>>
>>Best,
>>
>>Lynn
>>
>>
>>On Aug 15, 2014, at 1:10 PM, Martin Boyle <Martin.Boyle at nominet.org.uk>
>>wrote:
>>
>>> Hi Joe,
>>>
>>> I am concerned by the return to the idea of supermajorities overruling
>>> significantly affected parties.  I do not like recourse to voting (for
>>> reasons that I have already explained), and certainly not when it can
>>> be used to overrule legitimate concerns.
>>>
>>> First, I agree with your division between non-substantial (those not
>>> related to the final proposal, but focussed on our ways of working,
>>> charter, even the RFP) and the substantial (related to proposals).
>>>
>>> For your hyper-majority proposal (which reminds me of EU formulae for
>>> Council decisions - and that's not an accolade!), what is the
>>>percentage?
>>> I gave some thresholds in my original mail on this issue.  What
>>> happens if one of the dissenting organisations were to be the gTLDs?
>>>Or the ccTLDs?
>>> (Interestingly, I don't think such a mess would happen in the case for
>>> numbers or protocols.)
>>>
>>> And being voted against won't solve the problem because you won't have
>>> addressed the specific concerns of the beaten party who would then
>>> lobby against the solution showing that we do not have a consensus
>>>proposal.
>>>
>>> Essentially, I see a distinct risk of a formulaic approach leading to
>>> a risk of marginalising particular interests simply because they don't
>>> fit the model others might prefer.
>>>
>>> I would note that the role of the ICG is to represent the wider
>>>community. 
>>> However, we are not elected by them, but appointed by our communities
>>> and accountability to those communities.  The chair's role is to try
>>> to pull together consensus, ensuring that serious concerns are
>>> properly considered and that the output is something that works for
>>> all and where there are appropriate safeguards.  I agree that the
>>> discussion can't keep going around in loops (hence the need for us to
>>> justify our positions) and sometimes there will be a final dissenting
>>> voice who does need to be given a say in the final document.
>>>
>>> Cheers
>>>
>>> Martin
>>>
>>>
>>> From: internal-cg-bounces at icann.org
>>> [mailto:internal-cg-bounces at icann.org]
>>> On Behalf Of joseph alhadeff
>>> Sent: 14 August 2014 20:07
>>> To: internal-cg at icann.org
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Colleagues:
>>>
>>> Perhaps we can consider a different dividing line on consensus.  I
>>> would suggest that we have two main buckets, that which is related to
>>> a proposal and that which is related to our operations.  For
>>> operations 2/3 of those expressing an opinion is sufficient to arrive
>>> at decisions, but for issues related to proposals we need more than
>>> 2/3 (other percent?) of all members with no more than 2 participating
>>> organizations dissenting. The role of the chair would thus be
>>> constrained by rules regarding when consensus is achieved, but the
>>> chair would have the ability to manage discussion or call for a formal
>>> vote if they believed it would help move us towards consensus.
>>>
>>> Slightly less complex and perhaps more action-oriented.
>>>
>>> Joe
>>> On 8/14/2014 2:26 PM, James M. Bladel wrote:
>>> Agree.  "Consensus" is not equivalent to "Unanimity."
>>>
>>> J.
>>>
>>>
>>> From: <Drazek>, Keith Drazek <kdrazek at verisign.com>
>>> Date: Thursday, August 14, 2014 at 13:10
>>> To: ICG List <internal-cg at icann.org>
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Just so I'm clear...
>>>
>>> Looking ahead....if we end up with 29 ICG reps in favor of a final
>>> recommendation and one person who unreasonably refuses to compromise,
>>> will that be deemed "consensus" or "no consensus?"
>>>
>>> Hypothetically speaking, if one holdout among us can obstruct a
>>> decision that has received support from all other members, and would
>>> prevent delivery of a recommendation....I find that very troubling.
>>>
>>> Keith
>>>
>>>
>>>
>>> From: internal-cg-bounces at icann.org
>>> [mailto:internal-cg-bounces at icann.org]
>>> On Behalf Of WUKnoben
>>> Sent: Thursday, August 14, 2014 1:47 PM
>>> To: Kavouss Arasteh
>>> Cc: Coordination Group
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Dear Kavouss,
>>>
>>> you make the same point I expressed by saying that "I'm still
>>> uncertain with "non-substantive" issues which level of substance may
>>> depend on different views". I would welcome you providing other more
>>> useful criteria to decide in which rare cases a "poll" or "voting"
>>>could apply.
>>>
>>> As you may have seen in my latest draft I removed the "adjectives"
>>> from consensus. So I would appreciate your written suggestion for an
>>> acceptable text that I could better understand your disagreement with
>>> the present proposal.
>>>
>>> Best regards
>>>
>>> Wolf-Ulrich
>>>
>>>
>>> From:Kavouss Arasteh
>>> Sent: Thursday, August 14, 2014 7:22 PM
>>> To: WUKnoben
>>> Cc:Milton L Mueller ; Martin Boyle ; Coordination Group
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Dear All,
>>> I am not comfortable to any of these measures.
>>> The more we discuss and analyze ,the more problem is created.
>>> I strongly disagree to make any discrimination among the contstituent
>>> groups in ICG ,WHEN IT IS PROPOSED qUOTE "For substantive issues, at
>>> least none of the "customer groups" (numbers, protocols, gTLDs or
>>> ccTLDs) of the IANA remains strongly opposed"
>>> What is considered by someone " substantive" may be considered by
>>>others " 
>>> non substantive,
>>> NO ADJECTIVE FOR OPPOSITION .NO ADJECTIVE FOR SCONSENSUS.
>>> If you want instead of making progress to draft another chatter or
>>> convention for decision making ,I disagree with that .
>>> It ios incumbent to the chair and the two vice chairs to make utmost
>>> efforts to build consensus- Pls end this discussion Regards Kavouss
>>>
>>>
>>>
>>>
>>> 2014-08-14 18:32 GMT+02:00 WUKnoben <wolf-ulrich.knoben at t-online.de>:
>>> Thanks all for your valuable input.
>>>
>>> Milton is right calling for verbal clarity. But differentation is also
>>> needed and there are different approaches to achieve it. And as I said
>>> before the suggestion so far was based on GNSO habit.
>>>
>>> I tried to accomodate the discussion and therefore suggest to
>>> differentiate between "recommendation by consensus" (highest level,
>>> 100%) and "recommendation" (all remaining discussion results leading
>>> to a recommendation).
>>>
>>> I agree to all basic principles Martin came up with and incorporated
>>>them.
>>> I'm still uncertain with "non-substantive" issues which level of
>>> substance may depend on different views.
>>>
>>> I would appreciate further fruitful discussion on the list and we will
>>> hopefully see an end at our call next week.
>>>
>>> See my edits attached.
>>>
>>> Best regards
>>>
>>> Wolf-Ulrich
>>>
>>>
>>> From:Milton L Mueller
>>> Sent: Tuesday, August 12, 2014 8:12 PM
>>> To: 'Martin Boyle' ; Coordination Group
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> I think Martin makes very good points here.
>>> I like his proposed principles, every one of them.
>>>
>>> I must confess that I have been wincing at the way the word
>>> "consensus" is (ab)used routinely in these circles. Either it is truly
>>> consensus, and everyone either agrees or agrees not to object, or it is
>>>_something else_.
>>> Will we please stop trying to apply the term "consensus" to
>>> supermajority voting processes? My academic commitment to verbal
>>> clarity and directness is screaming at me that this is wrong.
>>>
>>> The IETF concept of "rough" consensus is an informal mechanism that is
>>> suitable for a more homogeneous environment in which adherence to
>>> standards is voluntary anyway, but in an environment with binding
>>> outcomes and political factions, it can and, in the ICANN context,
>>> frequently HAS merely provided a rationalization for ignoring
>>> significant minority points of view.
>>> --MM
>>>
>>> From:internal-cg-bounces at icann.org
>>> [mailto:internal-cg-bounces at icann.org]
>>> On Behalf Of Martin Boyle
>>> Sent: Tuesday, August 12, 2014 1:24 PM
>>> To: Coordination Group
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Hi All,
>>>
>>> First thanks to Wolf-Ulrich for his paper.  I greatly like the idea of
>>> standards of good behaviour and mutual respect - and I'm pleased to
>>> see that this is already very much the framework for the way that the
>>> ICG works.  I'd also note that the analysis of shades of grey in
>>> levels of support is interesting - was it Patrik who first noted the
>>> two extremes (non-substantial and substantial issues) and the level of
>>> consensus that might be needed?  I'm just not sure I know how to use
>>>them...
>>>
>>> I'd firmly endorse the aim that "the ICG ... reach at least Consensus
>>> on the Proposal for the IANA Stewardship Transition to be forwarded to
>>> the NTIA" subject to our continued effort to try to achieve
>>> full/unanimous consensus or (at least) to have addressed address points
>>>of concern.
>>>
>>> However, I do not like processes that are supposed to be by consensus
>>> being resolved by voting (cf WCIT):  voting leaves winners and losers.
>>> It also means that people get lazy and fail to look for compromise or
>>> common ground or ways to address "reasonable" concerns.  That aversion
>>> is not really addressed by supermajorities:  even at an 80%
>>> supermajority, all the domain name registries or all the government
>>> representatives or all GNSO members could be overruled.  At 85% all
>>> the ccTLD registries, at 90% all the gTLD registries could be ignored.
>>>
>>> I do recognise the need for a mechanism that allows us to come to a
>>> final recommendation and I'm afraid that I do not see any magic wand.
>>> But I would suggest a number of basic principles:
>>>
>>> ·         The aim of the discussion should be to try to find a solution
>>> where *no member of the ICG still maintains serious opposition to the
>>> outcome.*  Reasons for objections should be given, allowing the ICG
>>> wherever possible to try to address those concerns.
>>>
>>> ·         *Recourse to any form of voting should be the exception.*
>>>Its 
>>> use might be fine for non-substantive issues.  For substantive issues,
>>> at least none of the "customer groups" (numbers, protocols, gTLDs or
>>> ccTLDs) of the IANA remains strongly opposed.
>>>
>>> ·         Group members who still have problems with the evaluation
>>>should 
>>> be invited to *identify possible ways in which the proposal could be
>>> modified to make it acceptable to them.*
>>>
>>> ·         Discussions should continue until *no "IANA customer" group
>>>is 
>>> firmly opposed.*
>>>
>>>
>>> One final point:  I would be willing to allow anyone who feels that
>>> they have not been heard to put a minority view into the final report.
>>> I'd rather that did not happen, but if the views are strong enough, it
>>> would be best to have then documented in the report than to be first
>>> aired in the discussion that follows the publication of our final
>>>report.
>>>
>>> Cheers
>>>
>>> Martin
>>>
>>>
>>>
>>> From:internal-cg-bounces at icann.org
>>> [mailto:internal-cg-bounces at icann.org]
>>> On Behalf Of Kavouss Arasteh
>>> Sent: 11 August 2014 20:48
>>> To: Drazek, Keith
>>> Cc: Coordination Group
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Dear All,
>>> Undoubtedly, it would be super majority either 2/3 or 4/5 .
>>> Kavouss
>>>
>>>
>>> 2014-08-11 18:18 GMT+02:00 Drazek, Keith <kdrazek at verisign.com>:
>>> I agree that we will need a clear process for determining consensus
>>> that falls somewhere on the spectrum between humming and requiring a
>>> unanimous vote.
>>>
>>> If we get in to discussions of voting, we'll also need to address the
>>> thresholds required to establish consensus. Is it a simple majority?
>>> Super-majority?  Unanimous voting is an unhelpful requirement that
>>> would likely obstruct our work and our ability to deliver, so I
>>> believe that should be a non-starter for the ICG. We need to avoid the
>>> possibility of one dissenting vote undermining an otherwise strongly
>>> supported recommendation that represents broad community consensus.
>>>
>>> However, if/when there is not full consensus, it will be important
>>> that we have a mechanism for expressing dissenting opinions. The GNSO
>>> Registries Stakeholder Group employs a "minority statement" mechanism
>>> to allow for all views to be expressed when there is consensus but not
>>> unanimity on a particular topic. Perhaps we should consider a similar
>>> mechanism for the ICG.
>>>
>>> Keith
>>>
>>> -----Original Message-----
>>> From: internal-cg-bounces at icann.org
>>> [mailto:internal-cg-bounces at icann.org]
>>> On Behalf Of Subrenat, Jean-Jacques
>>> Sent: Monday, August 11, 2014 6:09 AM
>>> To: Kavouss Arasteh
>>> Cc: Coordination Group
>>> Subject: Re: [Internal-cg] Consensus building process
>>>
>>> Hello Colleagues,
>>>
>>> From the experience of the past few weeks, unfortunately we can
>>> conclude that the current process is not successful. Rather than
>>> meting out blame or praise, we need to understand why it's not
>>> working. Group dynamics and a bit of sociology can help.
>>>
>>> Our Coordination Group is different from what some of us/you have come
>>> to consider as "normal". The technical bodies (IETF, IAB) have
>>> developed an efficient process where "rough consensus" is understood
>>> and accepted. But other components of the ICG have different habits,
>>> and also a different accountability mechanism: however attractive
>>> "rough" may be, it is insufficient. For example, the GAC has its own
>>> rules (a joint position can only be reached by unanimity), and the
>>> ALAC routinely conducts all its votes on a full-membership basis (each
>>> member has to say ay, nay, abstain, or be noted down as not having cast
>>>a vote).
>>>
>>> So the challenge is this: is the "rough consensus" really adapted to
>>> all the needs of our group? With the experience gained collectively in
>>> London, and especially since then, I would recommend a dual approach:
>>>
>>> A/ MATTERS REQUIRING ALL MEMBERS TO VOTE (typically, to be decided as
>>> soon as possible, with the exception of our Transition plan)
>>>    - Chair structure and membership,
>>>    - Charter of the ICG,
>>>    - choice of Secretariat (ICANN or outside of ICANN, or a mixture of
>>> both),
>>>    - choice of near-final drafts and approval of final draft of our
>>> Transition plan, before presentation to the NTIA.
>>>
>>> B/ MATTERS WHERE OTHER FORMS OF DECISION-MAKING ARE ACCEPTABLE
>>>    - Appraisal of specific community input, as a contribution to the
>>> ICG's recommended plan (e.g. ALAC should appraise input from its own
>>> community before submitting it to the whole ICG),
>>>    - external relations and communications of the ICG (once the Chair
>>> structure has been chosen and populated, it may wish to ask Chair, or
>>> another of its members, to be the point of contact),
>>>    - administrative & logistic matters, in conjunction with the chosen
>>> Secretariat (here too, delegation would be possible).
>>>
>>> I'm prepared to provide a more detailed proposal for the above items.
>>>
>>> Best regards,
>>> Jean-Jacques.
>>>
>>>
>>>
>>> ----- Mail original -----
>>> De: "Kavouss Arasteh" <kavouss.arasteh at gmail.com>
>>> À: "Patrik Fältström" <paf at frobbit.se>
>>> Cc: "Coordination Group" <internal-cg at icann.org>
>>> Envoyé: Lundi 11 Août 2014 10:40:08
>>> Objet: Re: [Internal-cg] Consensus building process
>>>
>>>
>>>
>>>
>>> Dear Wolf
>>> Thank you very much for reply
>>> My point is that if one or more ICG Mmember(s) is7are againszt the
>>> ruling of the Chir ,They could raise their issue and the matter must
>>> be settled by simple explanation or if not resolved by voting . I.E.
>>> CHAIR DOES NOT HAVE DECISION MAKING POWER ON HE OR HIS OWN WISHES
>>> RATHER TO TAKE INTO ACCOUNT VIEWS OF MEMBERS Regards KAVOUSS Regards
>>>
>>>
>>>
>>>
>>>
>>> 2014-08-11 8:33 GMT+02:00 Patrik Fältström < paf at frobbit.se > :
>>>
>>>
>>>
>>>
>>> On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben at t-online.de >
>>> wrote:
>>>
>>> > The chair's designation that consensus is reached is not her/his own
>>> > decision rather than a wrap-up of extensive discussions. Of course
>>> > this designation can be challenged by members. And this is what
>>> > triggers your question about "If several participants in the ICG
>>> > disagree with the designation given ...". I'm open to any helpful
>>> > suggestion on how we could procede in such a case.
>>> > In the end consensus - as defined - has to be achieved.
>>>
>>> Let me emphasize what you say here, which I strongly agree with.
>>>
>>> We must deliver.
>>>
>>> This implies we must be able to reach consensus.
>>>
>>> The last couple of weeks discussions on various topics makes me a bit
>>> pessimistic on the ability for us to reach consensus, but I am
>>> optimistic, always optimistic, on peoples ability and interest in
>>>actually deliver.
>>>
>>> Remember that the chair is calling on the consensus question, not the
>>> substance. That way the power of the chair is decreased to a minimum
>>> and process issues.
>>>
>>> Patrik
>>>
>>>
>>>
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>>
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>>
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>>
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at icann.org
>>> https://mm.icann.org/mailman/listinfo/internal-cg
>>
>>_______________________________________________
>>Internal-cg mailing list
>>Internal-cg at icann.org
>>https://mm.icann.org/mailman/listinfo/internal-cg
>>_______________________________________________
>>Internal-cg mailing list
>>Internal-cg at icann.org
>>https://mm.icann.org/mailman/listinfo/internal-cg
>>
>>_______________________________________________
>>Internal-cg mailing list
>>Internal-cg at icann.org
>>https://mm.icann.org/mailman/listinfo/internal-cg
>
>_______________________________________________
>Internal-cg mailing list
>Internal-cg at icann.org
>https://mm.icann.org/mailman/listinfo/internal-cg