Policy and Implementation Principles for Consideration (Status per 7 May meeting)

A. Overarching Principle

 

Since its inception, ICANN has embraced the bottom-up multistakeholder model (MSM) as a framework for the development of inclusive, global DNS policy. “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. [1]

 

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

 

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

 

B. Principles that apply to Policy & Implementation

 

Both GNSO Policy and Implementation processes must be based on the ICANN Multistakeholder Model. To ensure this, the following Principles are proposed:

  1. Policy development processes must function in a bottom-up manner. The process must not be conducted in a top-down manner and then imposed on stakeholders [3] , although an exception may be made in emergency cases such as where there are risks to security and stability, as defined in ICANN’s Security, Stability and Resiliency framework [4] .
  2. The development and implementation of policy   must have a basis in and adhere to standards of fairness, notice, transparency, integrity, objectivity, predictability and due process consistent with ICANN's core values (see http://www.icann.org/en/about/governance/bylaws#I )
  3. Implementation should be regarded as an integral and continuing part of the process rather than an administrative follow-on, and should be seen as a process that allows for dialogue and collaboration between those implementing the policy and those that developed it and/or are affected by the implementation.
  4. 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 provide guidance [5] on the implementation of the policies as recommended by the GNSO] .
  5. 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. In this regard, reference should be made to certain other Principles in this document that may be applicable in such situations (see e.g. Principles D-1(b), D-1(c) and D-2(a).)
  6. 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).

 

C. Principles that apply primarily to Policy

 

  1. Policy Standards :

a)        As outlined in the ICANN Bylaws, the GNSO is responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains. As such, gTLD policy development should not take place outside of the GNSO.

b)       GNSO policy recommendations should be clear and unambiguous with performance targets and standards [6] .

c)        Policy processes must be designed to be as time-sensitive as possible without compromising the multistakeholder process.

d)       Policy staff is expected to provide PDP WGs assistance, as outlined in the GNSO WG Guidelines, in a transparent and neutral manner, including drafting, if required, which should reflect faithfully the deliberations of the Working Group.

 

  1. Policy and the Community:

a)        An analysis of the impact on stakeholders is an essential part of the policy development process.

b)        The GNSO, with the assistance of Policy Staff, must provide timely notification to the rest of the community about policy development efforts and/or implementation processes 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 GNSO is responsible for reviewing and considering all such input. Final documents should include references to the input received and its disposition in the final outcome.

c)        Each of the principles in this document must be considered in terms of the degree to which they adhere to and further the principles defined in ICANN's Core Values as documented in article 2 of the ICANN by-laws ( http://www.icann.org/en/about/governance/bylaws#I ). Particular note should be made to   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”.

 

THIS SECTION IS STILL UNDER REVIEW BY THE WG:

 

[D. Principles that apply primarily to implementation

 

  1. Implementation Standards:
    1. All GNSO PDP WGs should be encouraged to provide as much implementation guidance as possible within a reasonable timeframe as outlined in the PDP Manual. To the extent implementation guidance cannot be provided, the PDP recommendations should strive to identify areas where additional policy work may be needed during implementation.
    2. Changes to GNSO implementation guidance need to be examined by the GNSO Council or another appropriate entity as designated by the GNSO Council on where they fall in the spectrum of policy and implementation. In all cases, the community maintains the right to challenge whether such updates need further review for policy implications.
    3. ICANN staff tasked by the Board with the implementation of the approved GNSO Policy recommendations should be able to make transparent changes to the proposed translation of the policy recommendations into an implementation plan as long as these do not affect the intent of the policy recommendations. Examples of such changes include administrative updates, error corrections and process details. In all cases, any such changes should be communicated to the GNSO Council or appropriate entity as designated by the GNSO Council, which maintains the right to challenge whether such changes did affect the intent of the policy recommendations.
    4. In all cases, all material changes that are made in the development of the implementation plan that affect the implementation guidance, intent of and/or policy recommendations as adopted by the GNSO Council must be communicated to the GNSO Council or appropriate entity as designated by the GNSO Council, which maintains the right to review the changes, determine whether or not they are supported by the intent of the policy recommendations, and modify the implementation plan accordingly.
    5. Each of the principles in this document must be considered in terms of the degree to which they adhere to and further the principles defined in ICANN's Core Values as documented in article 2 of the ICANN by-laws (see http://www.icann.org/en/about/governance/bylaws#I ).
    6. The resolution of unexpected policy related issues identified during the implementation phase should delay implementation as little as possible.

 

  1. Limitation of Implementation:
    1. There should be a mechanism to flag and address unanticipated outcomes of implementation decisions that may significantly impact [7] the community.
    2. There should be a mechanism to flag and address situations where there may be a deviation between the implementation and the policy as it was originally intended.
    3. If substantive policy implications are identified during implementation [8] , the GNSO Council should be notified and involved in the process of resolving the issue(s) and it should not be left to ICANN staff (or to whomever ICANN has delegated this task) to resolve by themselves.]

[2] See Annex A of the ICANN Bylaws.

[3] 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] The word “guidance” is being used here in its ordinary generic sense, and should not be read as referring to the phrase “Policy Guidance” as defined by this Working Group.

[6] These standards should be developed in coordination with, or with reference to, definitions and other work underway in relation to data gathering and metrics, e.g. by the GNSO’s Working Group on Data & Metrics for Policy Making.

[7] Some possible examples include but are not limited to: if new obligations are imposed on parties; substantive changes to burdens such as related privacy, accessibility, rights protections, costs, risks, etc.

[8] Identified via a process that is expected to be defined by the PI WG