Comment Close
Date
Statement
Name 

Status

Assignee(s)

Call for
Comments Open
Call for
Comments
Close 
Vote
Announcement 
Vote OpenVote
Reminder
Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
12.09.2014Feedback Request: Policy & Implementation Working Group (PIWG)SUBMITTEDn/a28.08.201411.09.2014 23:59 UTCn/an/an/an/a12.09.2014

Glen de Saint Géry Glen@icann.org

n/a


For information about this Feedback Request, please click here 

Dear Olivier,

 

One of the questions that the Policy & Implementation Working Group (PIWG) was tasked to consider is: “Under what circumstances, if any, may the GNSO Council make recommendations or state positions to the Board on matters of policy and implementation as a representative of the GNSO as a whole?”  In consideration of this question, the PIWG is currently developing possible recommendations for new processes in addition to the existing Policy Development Process (PDP) by which the GNSO Council can provide input on behalf of the GNSO community on policy and related questions brought to its attention by the ICANN Board, other ICANN Supporting Organizations and/or Advisory Committees (SO/ACs) and by GNSO participants. As these proposed mechanisms are likely to be of great interest to the GNSO community, the PIWG would very much like to seek your group’s feedback on the attached flow charts outlining these potential processes.  We have not yet developed detailed descriptions of these processes so we are not looking for feedback at that level (although that would be accepted) but rather, we would like to know whether or not you think we are headed in a constructive direction in considering new processes like these.

Attached are flow charts that show the two additional processes: a proposed GNSO Guidance Process (GGP) and a proposed GNSO Input Process (GIP). They are intended to supplement the existing mechanisms by which the GNSO Council performs its work and manages that of the GNSO community.  The processes are intended to add to the flexibility and responsiveness of the GNSO and the Council. They represent our attempt to balance the need for such nimbleness with the need for codified processes that will allow the GNSO and the Council to deal with requests other than on an ad-hoc basis. The possibility of a “fast track” PDP is also included in some of the flow charts to try to address situations where policies already adopted by the ICANN Board may need clarification or updating.

The flow charts are organized as follows:

  1. An overview of the GNSO Process Options including the new processes
  2. An outline of the GNSO Guidance Process (GGP) without a Fast Track PDP option and with voting thresholds as follows: i) to initiate a GGP, the same as required to initiate a PDP; ii) to approve GGP recommendations, supermajority as currently defined for the GNSO Council
  3. An outline of the GNSO Guidance Process (GGP) with a Fast Track PDP option and with voting thresholds as follows: i) to initiate a GGP, supermajority as currently defined for the GNSO Council; ii) to approve GGP recommendations, supermajority as currently defined for the GNSO Council
  4. An outline of the GNSO Input Process (GIP).

Note that flowcharts 2, 3 & 4 contain boxes that are colored in orange.  These indicate that those are specific areas that the WG will further review and discuss once a more detailed description of these processes is available. If you already have any specific input you would like to provide on these areas (or any other), you are more than welcome to do so, but please note that there will of course be further opportunities to provide input as further details are developed by the WG.

The PIWG will be grateful if your group could provide its feedback to us by Friday 12 September 2014. At a minimum we would like to know whether you think the PIWG is heading in the right direction with regard to its consideration of recommending two new processes similar to the GGP and GIP shown in the flowcharts.  In addition, feedback would also be welcome at your option regarding the orange colored boxes in the flow charts.

We will be happy to address any questions that your members may have in the meantime.  Your questions and your feedback may be provided via your WG representative(s) or via email in response to this message.

 

Best regards,

J. Scott Evans & Chuck Gomes (Co-Chairs), Michael Graham & Olevie Kouami (Co-Vice-Chairs)

 

Resource: GNSO Policy & Implementation Working Group Home 

 

Below is the feedback submitted by Olivier Crepin-Leblond to the GNSO Secretariat.

 

 

  • No labels

2 Comments

  1. The charts that accompany this request for feedback are somewhat cryptic, so I will try to give an overview of the work the group has done to date, and the direction we are going in.

    You may recall that the fuss that triggered this was whether certain new intellectual properties rights that were incorporated into the new gTLD program at a very late date were in fact "implementation", and thus fair game to be added by staff, or "policy" and thus potentially required GNSO involvement. In my mind, the specific issues were indeed "implementation" based on the used of the word up until that time (they were variations of other IP rights and processes which were explicitly deemed to be "implementation" by the GNSO itself. But the history of how we got here is to some extent irrelevant.

    Among the conclusions so far, is that regardless of the nomenclature, if stakeholders are going to be affected by a decision (at any stage of the process), they must have an opportunity to influence that outcome. This Is another way stating Principle #1 from the ALAC input into the WG (https://community.icann.org/x/-hSMAg):

    There must be a methodology to recognize when a decision will impact the community, and such decisions must involve a bottom-up process in addressing those decisions.

    The implication is that it is inevitable that after a policy is developed and approved by the Board, it is inevitable that on occasion, issues will arise during "implementation" that will need additional community input (regardless of whether it is labelled "policy" or not).

    ALAC Principle #2 said:

    The processes must be designed to be time-sensitive – unending debate should not be an option.

    This too has been accepted by the WG, and work is underway to design policy development processes which can be used to address such issues. They must be sufficiently "light-weight" as to not take the time that a full-blown PDP does, but at the same time, need to provide opportunities for community input and involvement. The Policy Guidance Process and Policy Input Process described in this PC are among one of the alternatives being worked on.

    I do not think that the ALAC needs to provide any explicit input at this stage. Our original input was very applicable, and in fact, the WG is in the process of sending the feedback to the ALAC on that input.

    Both Cheryl and I have been very active (and very vocal!) in the WG. Although I had some doubts at the start, I am very optimistic that the results that come out of the WG will help ensure that the bottom up process can respond to the complexities of today's policy requirements.