Policy and Implementation Principles for Consideration (Updated 23 30   January 2014)

A. 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.” [1] “Multistakeholder Model” is an organizational framework or structure for organizational governance or policymaking which aims to bring together all stakeholders affected by such governance or policymaking to cooperate and participate in the dialogue, decision making and implementation of solutions to identified problems or goals. A “stakeholder” refers to an individual, group or organization that has a direct or indirect interest or stake in a possible outcome. [2]

 

The “ICANN Multistakeholder Model” is a Multistakeholder Model composed of different Internet stakeholders from around the world organized in various Supporting Organizations, Stakeholder Groups, Constituencies and Advisory Committees, and utilizes a bottom-up, consensus-based policy development process, open to anyone willing to participate.

 

GNSO policy development processes and in particular the Policy Development Process [3] (PDP) enshrine this concept of a robust MSM and to that end the following Principles apply.

 

B. Principles

 

I. Discussed Principles:

 

Both GNSO Policy and Implementation processes must be based o n the ICANN multi-stakeholder model. To ensure this, the following Principles are proposed:

  • Policy d evelopment p rocesses must function in a bottom-up manner . T he process must not be conducted in a top-down manner and then imposed on stakeholders [4] , although an exception may be made in emergency cases such as where there are risks to security and stability, as defined in ICANN’s SSR framework.  
  • Implementation should be regarded as an integral and continuing part of the policy process rather than an administrative follow-on, and seen as a process that allows for dialogue and collaboration between those implementing the policy and those affected by the implementation .  
  • Whilst Implementation Processes as such, need not always function in a purely bottom-up manner, in all cases the relevant policy development body (e.g. the chartering organization) must have the opportunity to be involved during implementation to confirm that policies are implemented as intended .
  • In cases where new or additional policy issues are introduced during an implementation process, these issues should be communicated to the relevant policy development body (e.g. the chartering organization)   prior to the completion of the implementation process . [ T his will be a point further deliberated by the WG – any WG recommendations in this regard will eventually need to be reflected in the final   version   of this principle ]

 

II. Additional Proposed Principles :

Proposed Principles Relating to Policy

1.)      Policy Standards :

a)        GNSO policy recommendations should be clear and unambiguous with performance targets and standards.

b)        GNSO Policy development should be based on principles of fairness, notice, transparency and due process as well as predictability.

The processes must be designed to be time-sensitive. The resolution of unexpected policy related processes identified during the implementation phase need to delay implementation as little as possible.

 

2.)      Policy and the Community:

 

a)        In policy development efforts:  “ It is the responsibility of the originating SO to do a stakeholder impact analysis [5] as part of its policy process. The SO must provide timely notification to the rest of the community about policy development efforts and/or implementation process es in which it is engaged 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. The originating SO is responsible for reviewing and considering all such input. Final documents should include reference s to the input received and its disposition in the final outcome. [Formerly Principle 3.]  

 

 

 

 

 

b)        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.

 

  1. Concepts not in overarching:
    1. participation reflecting the functional, geographic, and cultural diversity of the Internet

 

  1. Comments:
    1. Need to rephrase to reflect it as a principle; consider adding it as a footnote to the overarching principle instead?

 

 

Proposed Principles Relating to Implementation

[MOVED FROM POLICY SECTION: There should be a methodology to recognize [or determine?] when an implementation decision may [substantively] [or substantially] [or materially] impact the community.

Comment: Which sub-section under Implementation does this belong in?]

1.)      Implementation Standards:

 

  1. Implementation should be regarded as an integral and continuing part of the policy process rather than an administrative follow-on, and seen as a policy-action dialectic involving dialogue and collaboration between those seeking to put policy into effect and those upon whom action depends. [6] [Formerly Principle [tb1] 1.]  

 

  1. Concepts not in overarching:
    1. Implementation should be regarded as an integral and continuing part of the policy process rather than an administrative follow-on
    2. should be seen as a policy-action dialectic involving dialogue and collaboration between those seeking to put policy into effect and those upon whom action depends

 

  1. Comments:
    1. 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?
    2. 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.
    3. Response from Avri : In the case of problems, some form of conciliation of the intent of the policy and the effect of the implementations needs to be done.
    4. From Mary : Is there a way to rephrase the sentence to capture the idea that Policy and Implementation are not two separate phases entirely, but require continuous dialogue and communication between those that determined the policy (e.g. GNSO) and those that are charged with operationalizing/implementing it (e.g. staff)?

 

  1. 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) [Formerly Principle 6.]  

 

  1. Concepts not in overarching:
    1. provide as much implementation detail as possible within a reasonable timeframe
    2. 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.

 

  1. Comments:
    1.  

 

  1. 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) [Formerly Principle 5.]  

 

  1. Concepts not in overarching:
    1. Administrative updates, error corrections and clarifications… should be treated as implementation issues without any requirement for public consultation.

 

  1. Comments:
    1. [tb] I would delete this , as it requires a judgment decision.  All changes sho u ld be published and the community will decide if the changes are material.

 

  1. Core Value 8. Making decisions by applying documented policies neutrally and objectively, with integrity and fairness.

 

  1. Concepts not in overarching:
    1. applying documented policies neutrally and objectively, with integrity and fairness

 

  1. Comments:
    1.  

 

2.)      Limitation of Implementation:

 

  1. “. . . a proposed change (in policy implementation) is treated as an implementation change unless the objective or result is to create s 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) [Formerly Principle 4.]  

 

  1. Concepts not in overarching:
    1. a proposed change (in policy implementation) is treated as an implementation change unless the objective is to create new obligations on certain parties.
    2. creation of new obligations on parties would automatically put a proposal  in the policy category

 

  1. Comments:
    1. 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.
    2. 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.
    3. Response from Nic: Sounds good Chuck. Not sure how to make this more concrete.  I more comfortable with something like: “is treated as an implementation change unless the change entails new obligations that place a materially burden on certain parties.”
    4. From Avri: in relation to ‘unless the objective is to create new obligations on certain parties’ - In this case I have difficulty with the word ‘ objective’ since we don’t always know the objective or indeed the objective may be solving a more practical and other problem. The obligation may just ensue. And yes, any new obligation on a Stakeholder is a policy matter. [tb] Agreed
    5.  

 

Proposed Principles Relating to ICANN Staff

1.)      ICANN Staff Involvement

 

  1. The GNSO WG Guidelines contain the following that could contain possible policy and implementation principles:  “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).” [Formerly Principle 10.]  

 

  1. Concepts not in overarching:
    1. ICANN Staff performs the following two basic functions for any WG:
      1. secretariat (fundamentally a support function covering logistics)
      2. 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)

 

  1. Comments:
    1.  

 

2.)      ICANN Staff Limitations

  1. 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. Three principles from the ALAC Statement on the Policy & Implementation Working Group, 21 Nov 2013: “ [Formerly Principle 8.]  

 

  1. Concepts not in overarching:
    1. 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. [tb] Or Board

 

  1. Comments:

Reminder: consider staff responsibilities in relation to communication (see previous comment from Tom Barrett re. Policy & Community - Ditto for ICANN staff and Board.  This is what is missing in implementation today – i.e. interim reporting)

 

C. Explanatory Notes to Principles

 

  1. What is the role of public comments (and their analysis and response to them) in the Policy Development Process?

 

Previous note from Marika: ‘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’ (to which Chuck and Avri noted that it is not enough to simply solicit public comment and then leave it to staff to analyze and implement)

 

  1. In relation to emergencies that justify not utilizing the bottom-up process, these should be the exception rather than the rule (based on a comment by Avri in an earlier version).

 

  1. What is the role of an Implementation Review Team?

 

Previous note from Marika: “ 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 [tb2] )

 

  1. Others?

 

 


[1] See Blog by David Olive: http://blog.icann.org/2013/10/advancing-icanns-multi-stakeholder-model-through-community-engagement/#sthash.LNVQ8JNO.dpuf

[3] See Annex A of the ICANN Bylaws .

[4] This Principle is applicable regardless of when a Policy Development Process is initiated, and who by. For example, under the ICANN Bylaws a GNSO PDP may be initiated by the Board, the GNSO Council or another ICANN Supporting Organization or Advisory Committee.

[5]   Stakeholder Impact Analysis means an assessment of the effect of policy and implementation outcomes in light of their possible consequences on ICANN stakeholders.

[6] adapted from the following statement: “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.”


[tb1] Nicely said.   I would like to see this said up-front.

[tb2] As a rule, The GNSO should go back to staff first.