[ispcp] [council] Discussion Item: Changes to ICANN Bylaws

[Mike O'Connor]

this is a very dramatic expansion of the role of the GNSO Council -- from "managing the policy making process" to "making policy when the policy-making process is inconvenient."  

i think the original errors that underlie this issue were committed when a) the *Council* was consulted in this matter, and b) the Council accepted that request -- rather than relying on the policy-making process that's laid out in the bylaws.  

one of the errors in Jeff's draft is his reference to "the GNSO".  what does that mean?  the GNSO *Council*?  the constituencies?  the participants in the constituencies?  who decides?

what's the process by which issues are decided?  if it's by Council rules, then we are departing from the "bottom up, *consensus* based" language that we push out to the world -- because the Council is not consensus based, it's representational and based on various voting thresholds.  if the constituencies decide, what rules apply?  what if there isn't consensus?

and, at the end of the day, if the Board can ask the Council for policy decisions, who on earth would want to apply the care and rigor of the PDP to anything when we can be more "agile" by bypassing that process?

i am personally very uncomfortable with Jeff's idea.  i know it's appealing in this instance, but in my view two wrongs don't make a right.

mikey


On Jun 10, 2013, at 9:51 AM, "Novoa, Osvaldo" <onovoa at antel.com.uy> wrote:

> Dear All,
> I personally support Jeff Neuman’s proposal.
> Is there support for it in our community?
> Best regards,
> Osvaldo
>  
> De: owner-council at gnso.icann.org [mailto:owner-council at gnso.icann.org] En nombre de Volker Greimann
> Enviado el: Lunes, 10 de Junio de 2013 08:27
> Para: Neuman, Jeff
> CC: 'GNSO Council (council at gnso.icann.org)'
> Asunto: Re: [council] Discussion Item: Changes to ICANN Bylaws
>  
> I would also support such a motion. The suggested language keeps the door for alternative processes open while shutting the door for a complete bypass without accountability.
> 
> Best,
> 
> Volker
> 
>> All,
>>  
>> In the rationale used in the BGC’s recommendation against the NCSG’s Reconsideration Request, the BGC argues that:
>>  
>> “There is no defined policy process within ICANN that requires Board or staff consultation with the GNSO Council if the Board or staff is acting in contravention to a statement made by the GNSO Council outside of the Policy Development Process.  Therefore, even if staff’s action here was in direct contravention to the GNSO Council statement in a letter, the Bylaws requirement for consultation does not apply…”
>> 
>> Technically and legally, the BGC is correct.  As much as this goes against the very nature of the multi-stakeholder model (and frankly the message ICANN delivers to the world), the ICANN Board/staff is free to ignore the GNSO Council (and thus has no accountability for these actions).   This is true despite the fact that the Bylaws also state:  “There shall be a policy-development body known as the Generic Names Supporting Organization (GNSO), which shall be responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains.”  Therefore, what the BGC is telling us is that despite the fact that the Bylaws charges the GNSO with developing and recommending substantive policies, it can ignore the GNSO community at any time if the issue did not go through a formal PDP.
>>  
>> I personally believe that is broken.  Therefore, I would like for the Council to consider recommending to the ICANN Board a change to the Bylaws for an additional measure of accountability that at a minimum would require some form of consultation if the GNSO Council (on behalf of the GNSO Community) issues a recommendation or develops policy outside of a formal PDP.  As the former chair of the PDP Working Group that helped revise the PDP process, I can tell you that we were encouraged by the community to allow other mechanisms for developing policy outside of formal PDPs.  We spent countless hours on this very topic.  Yes, if it does not go through a formal PDP, it may not trigger a 2/3 Board vote to overturn the recommendation, but it was never our intention that after going through that process, the Board to IGNORE the GNSO Community.  At a time when the community is trying to find ways to develop policies outside of the stringent PDP, this is NOT an incentive for doing that.
>> 
>> Therefore, I would like to see the following changes made to the Bylaws (no pride in authorship here…so feel free to suggest other words).  This is language that is VERY similar to the language the GAC has in the Bylaws:
>>  
>>  
>> The substantive policies and recommendations of the Generic Names Supporting Organization relating to generic top-level domains shall be duly taken into account, both in the formulation and adoption of policies, whether or not the policy development process as set forth in Article X, section 6 were followed. In the event that the ICANN Board determines to take an action that is not consistent with the GNSO policies or recommendations, it shall so inform the GNSO and state the reasons why it decided not to follow that advice. The GNSO and the ICANN Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. If no such solution can be found, the ICANN Board will state in its final decision the reasons why the GNSO recommendations or policies were not followed.
>> 
>>  
>> If the multi-stakeholder model truly has any meaning, I view these changes as non-controversial and essential to preserve what so many have so long been advocating.
>> 
>> Thanks.
>>  
>> Jeffrey J. Neuman 
>> Neustar, Inc. / Vice President, Business Affairs
>> 46000 Center Oak Plaza, Sterling, VA 20166
>> Office: +1.571.434.5772  Mobile: +1.202.549.5079  Fax: +1.703.738.7965 / jeff.neuman at neustar.biz  / www.neustar.biz
>>  
>  
> 
> El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información
> 
> 
> This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.


PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20130610/4a64caa0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20130610/4a64caa0/smime.p7s>