Hi,
For what it’s worth…, I just learnt that this is not the first board-initated PDP. The Privacy/Proxy Services Accreditation (PPSAI) PDP was also initiated by the board.
To learn more about GNSO processes and working group guidelines, check this page out: http://gnso.icann.org/en/council/procedures
Thanks again.
Amr
On Jul 20, 2015, at 4:38 PM, Sam Lanfranco <[log in to unmask]> wrote:
> Thanks Amr,
>
> That clears up a lot of the process for me. Hope it helps others too.
>
> Sam
>
> On 20/07/2015 10:39 AM, Amr Elsadr wrote:
>> Hi Sam,
>>
>> Thanks for the great questions. I’ll try to answer them inline below:
>>
>> On Jul 20, 2015, at 3:52 PM, Sam Lanfranco
>> <[log in to unmask]>
>> wrote:
>>
>>
>>> For the benefit of those in NCSG not familiar with the history or technical details here let me see if I understand this correctly (in layman’s/layperson’s terms). The ICANN board can request an Issue Report on a policy issue and the GNSO Council cannot reject that request. The Issue Report, once produced and accepted, also requires that the GNSO Council initiate a Policy Development Process (PDP) based on the content of the Issue Report.
>>>
>>
>> Yes…, but that is not really the issue. The GNSO council cannot reject a request for an issues report regardless who asked for it. The main difference between when the GNSO council (or anyone apart from the board) requests a preliminary issues report and when the board requests one, is that when the GNSO council requests one, it can vote to not proceed to a PDP following the final issues report’s publication. The council cannot do that when the board requests a preliminary issues report.
>>
>>
>>> Is this a correct characterization of the process? If so, is it correct that the scope and focus (charter?) for the resulting PDP get refined in the deliberations in the development of the Issue Report? If this is correct what is the dialogue between the GNSO Council and the Board within the development of the Issue Report?
>>>
>>
>> ICANN policy staff draft the issues reports whether this is in response to a request from the GNSO council or the board. A draft charter for a PDP working group is included in the final issues report, but the GNSO council can determine that a charter drafting team is required if it feels the draft charter is lacking in some way. This is irrespective of who requested the issues report in the first place.
>>
>>
>>> Since the GNSO Council is bound to initiate a PDP based on the Issue Report, does the Board have the ability to reject, or refer back, a GNSO Council produced Issue Report? If yes, this seems to leave the Board in the driver’s seat with regard to PDP scope and focus. If no, while the GNSO Council must initiate the PDP, it leaves the GNSO Council in the driver’s seat with regard to PDP scope and focus.
>>>
>>
>> The answer to this question is “no”. The board cannot (or rather should not in any way) influence the outcome of the final issues report. This is also irrespective of who requested the issues report in the first place. Remember that the purpose of an issues report is not to work out any substantive policy issues. It is only meant to scope the issue in a way that identifies any and all topics that should be considered by the ensuing PDP working group.
>>
>>
>>> In either case the Board has the power to initiate the process. Does it have the power to stop the process (by objecting to the Issue Report)?
>>>
>>
>> Again…, the answer to this is “no”.
>>
>> I should also add here that requesting an issues report is not exclusive to the GNSO council and the ICANN board. Any Advisory Committee (such as ALAC) may request an issues report. The only thing that makes a board-requested issues report special is that it will proceed to a PDP without a GNSO council vote. An issues report requested by the GNSO council requires a vote to proceed to a PDP following the publication of the final issues report (after public comments to the preliminary issues report have been reviewed).
>>
>> I hope this helps.
>>
>> Thanks.
>>
>> Amr
>>
>
>
|
