[ALAC] Fwd: Re: [council] Discussion Item: Changes to ICANN Bylaws

[Alan Greenberg]

My reply (issued purely on my own behalf).

I strongly support this move, since to not do so 
implies that the GNSO PDP is the ONLY way to 
enact gTLD policy, and I strongly feel that this 
should not be the case. There must be faster 
methods when the rigour of the PDP is not 
required, or where the WG model has proven to be unsatisfactory.

As you will see, I am also supporting the de 
facto process of having the community involved in 
substantive implementations. This has been the 
practice until the recent TM+5o proposal, and it 
is essential that staff do not have the option of 
ignoring the community if something does not meet 
the "policy" definition. That makes it a 
"multi-stakeholder unless we want to ignore them 
model" and that is not what we all put our time and effort in for.

I request that the ALAC take time in its future 
discussions (whether e-mail, wiki, teleconference 
or Durban) to discuss these issues and consider issuing advice to the Board.

Alan

>Date: Thu, 06 Jun 2013 11:58:31 -0400
>To: "Neuman, Jeff" <Jeff.Neuman at neustar.us>, 
>"'GNSO Council (council at gnso.icann.org)'" <council at gnso.icann.org>
>From: Alan Greenberg <alan.greenberg at mcgill.ca>
>Subject: Re: [council] Discussion Item:  Changes to ICANN Bylaws
>Cc: "Neuman, Jeff" <Jeff.Neuman at neustar.us>
>
>As a member of the PDP development team and as 
>someone who has long preached that the formal 
>PDP should not be the only way to develop policy 
>(if it is not to be a picket-fence Consensus 
>Policy or utilized the 2/3 rejection clause), I support this.
>
>Although perhaps this is a separate discussion, 
>I would go further, and put an onus on ICANN and 
>the Board to discus substantive issues of 
>implementation with the GNSO and the community. 
>The multi-year New gTLD implementation and the 
>STI in particular establish this precedent, and 
>it should be enshrined in the Bylaws.
>
>Alan (speaking on my own behalf)
>
>At 06/06/2013 11:29 AM, Neuman, Jeff wrote:
>>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 / 
>><mailto:jeff.neuman at neustar.biz>jeff.neuman at neustar.biz  / www.neustar.biz
>>