Policy and Implementation Principles for Consideration (Updated 19 December 2013)
Overarching Principle :
Since its inception,
“ICANN has embraced the multi-stakeholder model (MSM) as a framework for the development of inclusive, global Internet governance policy.”
, which aims to bring together
businesses, civil society, governments, research institutions
to cooperate and participate in the dialogue, decision making and implementation of solutions to common problems or goals.
A stakeholder refers to an individual, group or organization that has a direct or indirect interest or stake in a particular
action has the ability to influence the
actions, decisions and policies to achieve results.
The GNSO Policy Development Process enshrines
the concept of a robust bottom up consensus
MSM and to that end the following Overarching Principles apply
GNSO Policy & Implementation processes
based in the ICANN multi-stakeholder model,
to ensure this:-
Policy Development Processes must function in a bottom-up manner
;except in emergency cases such as risks to security and stability, and the process must not be made by a top-level group and then imposed on stakeholders. **
- Implementation Processes need not function in a bottom-up manner except in cases where new policy is introduced, and in all cases the policy development body must be involved to confirm that policies are implemented as intended. **
** Please Note these are words are from Chuck's original text of Dec 2nd and should be modified where required to match any agreed text we developed in the last Ob Sub Team call whilst discussing these matters => I assume Staff has access to records of these where applicable... so it can just be a simple copy cut and paste...
Additional Proposed Principles :
- Policy & implementation processes must both be based in the multi-stakeholder model. (This is a principle that was discussed in the P&I DT.) [CG3]
- From Marika : Should it be defined what ‘be based’ means here? The Staff discussion paper noted that ‘ ICANN may continue to refine the implementation of the requirement over time as more experience is gained - without having to go back to a requirement defined in the policy as recommended, so long as public comment is solicited with regard to those proposed implementation refinements. The community can assess the success of the implementation against the requirement’. Is that considered ‘based in’?
- Response from Chuck : Simply soliciting public comments does not make a process multi-stakeholder. It depends on what is done with those comments and who decides. It also depends on the significance of the refinements made in implementation. See principles 7 & 8. If you have a suggestion for rewording, please provide it; my intent for 1 was that all stakeholders should still be involved in implementation, i.e., it doesn’t suddenly become a staff/Board issue.
- The GNSO policy development process must function in a bottom-up manner; except in emergency cases such as risks to security and stability, the process must not be made by a top-level group and then imposed on stakeholders. (This is a personal opinion.)
- From Marika : It was suggested to the definitions sub-team that as this effort is focused on GNSO related aspects of the policy & implementation discussion that this should also be reflected in the terminology used. This sub-team may consider doing the same.
- Response from Chuck : I am not sure what you are suggesting here. What should be reflected in this sub-team’s work?
- Response from Marika : In a couple of places I’ve suggested adding the term ‘GNSO’ to make clear that these working principles are specific to the GNSO for the purpose of this discussion.
- From Nic : In relation to ‘except in emergency cases such as risks to security in stability - Is there an objective criteria for this? I agree in principle to this principle, but this exception seems like it has the potential for abuse if left this broad. Maybe something like “except where there is broad community consensus that there is an emergency case related to security and/or stability”.
- From Chuck @ Nic: The problem as I see it with your suggestion is that if there is an emergency SSR issue, there is not time to check for community consensus. Maybe we could add something like this: “ except in emergency cases such as risks to security and stability as defined in ICANN’s SSR framework ”.
- Implementation processes related to GNSO policy recommendations need not function in a bottom-up manner except in cases where new policy is introduced, and in all cases the policy development body must be involved to confirm that policies are implemented as intended. (This is a personal opinion.) “ ICANN Staff should inform the GNSO of its proposed implementation of a new GNSO recommended policy. If the proposed implementation is considered inconsistent with the GNSO Council’s recommendations, the GNSO Council may notify the Board and request that the Board review the proposed implementation. Until the Board has considered the GNSO Council request, ICANN Staff should refrain from implementing the policy, although it may continue developing the details of the proposed implementation while the Board considers the GNSO Council request. ” (Section 14 of the GNSP PDP Manual)
- From Marika : In relation to ‘to confirm that policies are implemented as intended’ - What does this mean? This makes it sound as if the GNSO needs to sign off on the implementation plan which is currently not inline with the language of the PDP Manual (which gives the GNSO Council the option to notify the Board if it believes the proposed implementation is inconsistent with the policy recommendations).
- Response from Chuck : The GNSO developed the policy so it should be the GNSO’s responsibility to ensure that it is implemented as intended. We can discuss what that looks like; see principle 3. If we agree with this principle, then we would need to recommend that the PDP manual be changed.
- Response from Marika : It may be worth noting that the PDP-WT when developing the revised PDP discussed this question in detail, whether the GNSO Council should be required to approve the implementation plan. If I recall well, one of the main reasons for not doing so, was that this would create a backdoor to opposing the policy recommendations by voting down the implementation plan. Also, it would give the GNSO the final say on the implementation, while under principle 1 we state that implementation should also be the based in the multi-stakeholder model.
- From Nic : I think Marika is correct that this is a deviation of the current process, but it is a principle that makes a lot of sense. Agree with this opinion.
- From Chuck @ Nic : What opinion do you agree with? I got the impression that you agree with the principle regardless of whether it differs with the current PDP manual. Is that correct? If so, then I think you and I are in agreement (see my response to Marika above).
“. . Implementation should be regarded as an integral and continuing part of the political policy process rather than an administrative follow-on, and seen as a policy-action dialectic involving negotiation and bargaining between those seeking to put policy into effect and those upon whom action depends.” (“Implementation Studies: Time for a Revival? Personal Reflections on 20 Years of Implementation Studies” by Susan Barrett,
, Vol. 82 No. 2, 2004, p. 253, 1
- Note that this is from a document that Marika provided early in the WG efforts.
- This principle relates fairly closely to # 1 above.
- From Marika : In relation to ‘negotiation and bargaining’ - This makes it sound like a negotiation which is usually not what happens during the implementation process. Is it the intent that the implementation process would become a negotiation between staff and affected parties?
- Response from Chuck : Yes, when needed. In fact, that has happened a lot with new gTLDs. There are several cases where staff did not do this and the results then later needed to be changed and the process took longer than needed. We need to realize that we are all on the same team; it is not staff vs. impacted parties; sometimes the impacted parties are the only ones who have the expertise needed.
- As much is possible within time constraints, GNSO policy recommendations should be clear and unambiguous with performance targets and standards. (“Implementation Studies: Time for a Revival? Personal Reflections on 20 Years of Implementation Studies” by Susan Barrett, Public Administration , Vol. 82 No. 2, 2004, p. 258 last full paragraph) “. . the underlying policy statement should be specific and concrete enough to put stakeholders on notice about possible implementation parameters.” (( GNSO gTLD Registries Stakeholder Group Statement on the Policy versus Implementation - Draft Framework, 21 Feb 2013, last paragraph on p.3)
- In policy development efforts: “ It is the responsibility of the originating SO to provide timely notification to the rest of the community about policy development and/or implementation process. But it is the responsibility of the other SOs and ACs and stakeholders in general to determine whether or not they are impacted by that activity, and to provide their input in a timely manner. ” ( GNSO gTLD Registries Stakeholder Group Statement on the Policy versus Implementation - Draft Framework, 21 Feb 2013, bottom of p.1)
- “. . . a proposed change (in policy implementation) is treated as an implementation change unless the objective is to create new obligations on certain parties.” (“ POLICY VERSUS IMPLEMENTATION – DRAFT FRAMEWORK ”, 31 Jan 2013, p.5, last paragraph) “. . . creation of new obligations on parties would automatically put a proposal in the policy category . . . “ (Summary of Public Comments on Policy vs. Implementation, 25 March 2013, Characteristics of the framework, Policy Development)
- From Nic : In relation to ‘creation of new obligations on parties’ - Any and all new obligations? In the past, specific implementation obligations have come out of broader policy recommendations. Are we comfortable opening the door this wide? It seems like it would be very easy to push back on any implementation under the guise of it creating new obligations.
- From Chuck @ Nic: Note that this suggestion was in the Policy Framework that staff wrote so maybe Marika can respond on this issue. I agree that we want to avoid on creating an easy way to cause delays so maybe we can come up with some qualifying language that would help here.
- Administrative updates, error corrections and clarifications to approved GNSO policy should be treated as implementation issues without any requirement for public consultation. (“ POLICY VERSUS IMPLEMENTATION – DRAFT FRAMEWORK ”, 31 Jan 2013)
- “ All GNSO PDP WGs should be encouraged to provide as much implementation detail as possible within a reasonable timeframe. . . . To the extent implementation detail cannot be provided, the PDP recommendations should strive to identify areas where additional policy work may be needed based on issues that become evident only in the first cut at implementation. ” ( GNSO gTLD Registries Stakeholder Group Statement on the Policy versus Implementation - Draft Framework, 21 Feb 2013, second bullet under item a) on p. 4)
- GNSO Policy development should be based on principles of fairness, notice and due process as well as predictability. (Summary of Public Comments on Policy vs. Implementation, 25 March 2013, Characteristics of the framework)
Three principles from the
Statement on the Policy & Implementation Working Group, 21 Nov 2013:
- 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 processes must be designed to be time-sensitive – unending debate should not be an option.
- There must be a way to come to closure when the community is divided, and this should not simply give executive powers to ICANN Staff.
- From Nic : in relation to the last bullet point - Personally, I think that this is a major issue that should be addressed in this subteam and with the larger group. Just flagging as a point of discussion.
The following Core Values from Section 2 of the ICANN Bylaws are principles that seem to be directly applicable to policy and implementation:
- Core Value 4. Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making.
- Core Value 7. Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process.
- Core Value 8. Making decisions by applying documented policies neutrally and objectively, with integrity and fairness.
- Core Value 9. Acting with a speed that is responsive to the needs of the Internet while, as part of the decision-making process, obtaining informed input from those entities most affected.
- The GNSO WG Guidelines contain the following that could contain possible policy and implementation principles with highlighting provided by me: “ICANN Staff performs the following two basic functions for any WG, namely secretariat (fundamentally a support function covering logistics) and policy liaison (a support function providing WG assistance in a neutral manner, including drafting, if required, which should reflect faithfully the deliberations of the Working Group).”
 See Blog by David Olive: http://blog.icann.org/2013/10/advancing-icanns-multi-stakeholder-model-through-community-engagement/#sthash.LNVQ8JNO.dpuf
 Lawrence E. Strickling, U.S. Assistant Secretary for Communications and Information, and NTIA Administrator, quoted in Wikipeadia see http://en.wikipedia.org/wiki/Multistakeholder_Governance_Model
[CG1] Should we add individuals or is that covered sufficiently in the next sentence?
[CG2] Recognizing that we cannot change the wording of a quote, how can we add the concept of equitable participation by all parties? Should we do that? Is there a better word than ‘equitable’? I intentionally avoided the word ‘equal’.
[CG3] This is covered above so does not seem to be needed again.