[council] Conversation Wrap-Up & Next Steps

Wed Mar 12 20:57:48 UTC 2014

Hi,

For some reason, I just don’t understand the danger this panel is posing. It reads a lot to me like the opinion of someone who is largely uninformed on the nature of the multistakeholder bottom-up consensus building nature of the GNSO processes, and what it takes to make changes to them. Does anyone here actually believe that radical changes in GNSO operating procedures can be unilaterally imposed by Fadi or the ICANN BoDs because the GovLab said so??

I really would like to hear concerns based on concrete actions you all feel might actually take place. Better yet…, instead of speculating, why not ask the ICANN BoDs to clear this up once and for all? In BA, the phrase “non-binding Board action” was floated around, and I have no idea what a non-binding Board action is.

I certainly feel that we, the GNSO Council, should do our duty of managing the GNSO's PDP in accordance with the ICANN by-laws, the PDP manual and the WG guidelines. We’ve been elected by our stakeholder groups and constituencies to do just that, and so far, I don’t see an impending assault. I’ve gone through the MSI Panel report and some of the proposals (not all of them), and I am lead to believe that the authors are in no way experts. In fact, ICANN aside, they seem to have a great deal of misguided assumptions on the principles of the ethnography of multistakeholder organisations, and how the introduction of collaborative tools influences them.

Volker makes some very logical observations:

On Mar 12, 2014, at 3:41 PM, Volker Greimann <vgreimann at key-Systems.net> wrote:

[SNIP]

> With regard to the various recommendations:
> 
> > From their perspective and having made themselves aware of the work of the GNSO, the suggested sub-set (from them) for further condensation is as follows:
> > 1.       Move from "Stakeholder" engagement to Global Engagement: http://bit.ly/1k7FDNj
> The current stakeholder engagement model provides some form of balance of interests and promotes cooperation and compromise solutions. Global engagement carries the danger of blurring the lines and favoring those who have the funds or time to contribute most and drowning out "lesser" voices. As a matter of fact, the public comment phases already provide a forum for global engagement and for parties independant of the existing stakeholder groups to make their voices heard.

Exactly…, and they make that completely unfounded assumption that the introduction of more collaborative tools will achieve more global engagement. Perfectly ridiculous.

> > 2.       Use expert networking: http://bit.ly/1lof1c5
> This is one I am actually more inclined to support than others, mostly because this is something the ICANN community has already been saying for ages. ICANN needs to be more inclusive of expert opinion. The most recent example is the failure of ICANN staff to grasp the concept of European data protection law and their attempts to negotiate what the law actually means. That said, as we knew this already, this recommendation is not really news, but if it helps ICANN understand, I am all for it.

No way I’m going to argue with you on that one!! :) I would also add to that - encouraging the trend of commissioning studies such as the recent WHOIS studies provided that the community sets the terms of reference.

> > 3.       Get Broad-based input/crowdsource at each stage of decision-making: http://bit.ly/1czpNXn
> Last I heard the public comment forums, ICANN participation and PDP participation were not exclusive to ICANN stakeholder groups.

True…, but apparently the “experts” haven’t heard what you’ve heard.

> > 4.       Use Open Data and open contracting: http://bit.ly/1jcv3Rt
> Is this not already in place?

Yes again, but the “experts” don’t seem to know how to find the contracts ICANN has with its contracted parties, nor understand how they came to be.

> > 5.       Experiment with Innovative Voting Techniques: http://bit.ly/1nwta2H
> This would be a topic for GNSO reform/innovation.

If you mean how the GNSO is structured, maybe. But my understanding was that they not only recommend that the GNSO’s decision-making guidelines be changed, but also decision-making guidelines on the stakeholder group and constituency levels currently defined in their respective charters/by-laws. I just don’t see that happening because they said so.

> >6.       Impose Rotating Term Limits: http://bit.ly/1nUmkEr
> - This reminds me of the Russian shuffle: Putin-Medvedev-Putin
> While I agree that ICANN needs to be more inclusive and outreach remains one of its weak points, I am not sure Rotating Term Limits are the solution. 
> 
> All in all, I still think that reform of ICANN should come from within.

Sure, but by definition, that means public comment and everyone is entitled to express an opinion.

I feel that if we want to take a serious step to settle the issue of (specifically) this panel, we need a clear answer from Fadi and the ICANN Board on what their intentions are regarding the proposals being made. For example, if they are in any way related to the work of the SIC and the forthcoming GNSO review, I would like to know about it. My understanding is that the last GNSO review was initiated by the GNSO Council as opposed to the upcoming one, which will be a Board-initiated review. Getting some answers would provide the context we need to decide the appropriate position we need to take.

Thanks.

Amr

>  
> 
> Volker
> 
>> 
>> On 3/5/2014 12:11 PM, Jonathan Robinson wrote:
>>> All,
>>>  
>>> In discussion with Beth Novek and colleagues from the Governance Lab last week, a suggestion emerged that we could potentially narrow down the list of MSI Panel proposals for more detailed discussion.
>>>  
>>> It is not yet 100% clear to me as to whether or not we will be able to meet with one or more of the team from the Gov Lab in Singapore but it seems likely and, in any event, it’s useful to consider how we might respond to the output of the panel, in particular where it seems to link most closely with our own work.  We discussed condensing their work into a most relevant sub-set for further discussion
>>>  
>>> From their perspective and having made themselves aware of the work of the GNSO, the suggested sub-set (from them) for further condensation is as follows:
>>> 1.       Move from "Stakeholder" engagement to Global Engagement: http://bit.ly/1k7FDNj
>>> 2.       Use expert networking: http://bit.ly/1lof1c5
>>> 3.       Get Broad-based input/crowdsource at each stage of decision-making: http://bit.ly/1czpNXn
>>> 4.       Use Open Data and open contracting: http://bit.ly/1jcv3Rt
>>> 5.       Experiment with Innovative Voting Techniques: http://bit.ly/1nwta2H
>>> 6.       Impose Rotating Term Limits: http://bit.ly/1nUmkEr
>>> I also talked with the Gov Lab people about considering the above proposals through a (non-exhaustive) list of criteria as follows:
>>>  
>>> A.      Is the proposal relevant to us?
>>> B.      Is it currently applicable to our work?
>>> C.      How could the proposal be modified/amended/advanced to be applicable or more applicable to our work?
>>> D.      How might we pilot/test these proposals in order to determine whether and how the proposal could be a useful amendment or reform for ICANN?
>>>  
>>> None of this pre-supposes that this work was commissioned, initiated or executed in a way which we consider optimal.
>>> It simply takes a “we are where we are” view of the work and recognises that we have the opportunity to potentially engage with the team that undertook the work.
>>>  
>>> In addition, we will still have the opportunity to provide formal public comment on this and engage through any other applicable forums at the ICANN meeting in Singapore.
>>>  
>>> Thoughts or input welcome.
>>>  
>>>  
>>> Jonathan
>> 
> 
> -- 
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
> 
> Mit freundlichen Grüßen,
> 
> Volker A. Greimann
> - Rechtsabteilung -
> 
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
> 
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken 
> Umsatzsteuer ID.: DE211006534
> 
> Member of the KEYDRIVE GROUP
> www.keydrive.lu 
> 
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
> 
> --------------------------------------------
> 
> Should you have any further questions, please do not hesitate to contact us.
> 
> Best regards,
> 
> Volker A. Greimann
> - legal department -
> 
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
> 
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken 
> V.A.T. ID.: DE211006534
> 
> Member of the KEYDRIVE GROUP
> www.keydrive.lu 
> 
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20140312/ac4839af/attachment.html>