Proposed Principles (from Staff Discussion Paper – see http://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf )

 

A proposed list of principles to guide these discussions could be:

 

  1. ICANN coordinates policy development that is reasonably and appropriately related to the technical functions of the allocation and assignment of domain names, IP addresses, and protocol port and parameter numbers, and the operation and evolution of the DNS Root name server system.

 

Where a policy will have a material impact on multiple Internet stakeholders, the ICANN Board seeks to determine whether there is a consensus amongst those Internet stakeholders before approving the policy. The determination of whether a consensus is present should consider the perspectives of all Supporting Organizations (SOs) and Advisory Committees (ACs) that have weighed in on the issue, not just the one where the policy originated.  

 

  1. ICANN has supporting organizations with specific responsibilities for areas of ICANN's policy development, including:

 

Generic Names Supporting Organization (GNSO) - responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains.

 

Country Code Names Supporting Organization (ccNSO) - responsible developing and recommending to the Board global policies relating to country-code top-level domains.

 

Address Supporting Organization (ASO) - responsible for advising the Board with respect to policy issues relating to the operation, assignment, and management of Internet addresses.

 

These supporting organizations have processes to determine whether consensus has been reached as applicable to their respective SO on a proposed policy before providing a report to the Board.

 

The Bylaws also recognize the important roles of advisory committees in the policy processes, including:

Governmental Advisory Committee (GAC) - considers and provides advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues.

 

Security and Stbility Advisory Committee (SSAC) - advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems.  In addition, SSAC makes policy recommendations to the ICANN community and Board.

 

At Large Advisory Committee (ALAC) - considers and provides advice on the activities of ICANN, insofar as they relate to the interests of individual Internet users. This includes policies created through ICANN's Supporting Organizations, as well as the many other issues for which community input and advice is appropriate.

 

Root Server System Advisory Committee (RSSAC) - advises the Board about the operation of the root name servers of the domain name system.

 

  1. Policies might apply to certain operational activities (as addressed in the ATRT Rec 6 Paper), or they might apply to Internet stakeholders such as gTLD registries and accredited gTLD registrars.

 

  1. When a policy applies to ICANN stakeholders - it could be expressed in high level terms such as a principle or high level requirement [1] . For example, the new gTLD policy recommendations approved in June 2008 included:

 

Principle D: A set of technical criteria must be used for assessing a new gTLD registry applicant to minimize the risk of harming the operational stability, security and global interoperability of the Internet.

 

A requirement: Strings must not be confusingly similar to an existing top-level domain or a Reserved Name.

 

ICANN staff will typically publish information on a proposed implementation of the principle or requirement - e g., the set of technical criteria, or the algorithm used to determine whether something is confusingly similar. The implementation information is published for public feedback, and the implementation is refined. 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.

 

In the case of GNSO PDPs, a recent development that originated from the overhaul of the PDP process is to form Implementation Review Teams [2] , which consist of members of the working group (WG) that developed the policy recommendations who are tasked to provide input and feedback as necessary to ICANN Staff as they develop the proposed implementation plan. This has provided a more collaborative environment in which Staff can develop the proposed implementation, instead of working in a silo trying to guess in certain cases what was meant with a policy recommendation.  

 

A further example are the proposals under discussion in the context of the Internationalized Domain Name (IDN) ccPDP. The latest draft recommends to:
 

-           Review the proposed policy within five years after implementation or at such time warranted by extraordinary circumstances. In the case such a review results in recommendation to amend the policy, the ccPDP rules as defined in the ICANN Bylaws apply. 

-           Verify the implementation - It is recommended that the ccNSO monitors and evaluates the planned implementation and the ccNSO Council reviews and approves the final planning, before implementation by staff.

-           A Permanent IDN ccTLD Advisory Panel is appointed to assist and provide guidance to ICANN staff and the Board on the interpretation of the overall policy in the event the overall policy does not provide sufficient guidance and/or the impact of the policy is considered to be unreasonable or unfair for a particular class of cases. 

 

  1. When a policy applies to a set of Internet stakeholders such as gTLD registry and gTLD registrars, the implementation of the policy is typically achieved through the agreements that ICANN has with those stakeholders. ICANN also manages a contractual compliance function to ensure that the stakeholders are complying with their agreements (including the policies incorporated into those agreements).

 

Through its contracts ICANN has the ability to add new policies or change policies during the term of a gTLD registry or gTLD registrar agreement. The contractual mechanism to do this is called "Consensus Policies", and there are defined procedures in the Bylaws for developing and approving such policies. The current set of Consensus Policies is available here:

http://www.icann.org/en/resources/registrars/consensus-policies .

 

In order to ensure compliance with a policy requirement, it is beneficial to include implementation details in the policy recommendation(s), and for that implementation guidance to also be part of the consensus policy as incorporated into the relevant contracts and/or agreements. This ensures that ICANN can clearly determine whether the policy is being followed.

 

For example ICANN has a transfer policy that aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. Recently, the GNSO Council adopted a new set of recommendations to improve and clarify the transfer policy and at the same time formed an Implementation Review Team to support ICANN Staff in the development of the implementation plan for these recommendations to ensure that the proposed implementation is consistent with the intent of the policy recommendations. Even though the recommendations themselves contain implementation details, it is expected that further questions and issues will arise that will need community input as ICANN Staff starts working on the proposed implementation.

 

  1. Where policies are documented:

 

Current policy is documented via a range of methods currently, including:

 

One area of improvement may be to clearly separate policies from documents such as the registrar accreditation agreement (RAA), so the community can clearly assess and help evolve current policies, although clearly the RAA and other contracts would need to be aligned with the new policies. For example, the WHOIS Review Team asked for all Whois policies to be consolidated in one place, so that these could be more easily found. If not cross-referenced appropriately, separation could add to confusion. Another improvement may be to clearly separate policies that apply to ICANN (e.g., as relates to the evaluation of new gTLD applicants), from policies that apply to Internet stakeholders such as registries, registrars, and registrants.


[1] Ideally policy recommendations contain as much detail as possible so that the implementation path is clear. However, experience has learned that this is not always the case. This can be the result of various circumstances, e.g. PDP WGs do not necessarily have the legal and technical expertise to anticipate all the possible information that needs to be provided to ensure a smooth implementation; there is only agreement on the high level principles and the details are punted to the implementation phase.

[2] This new concept of Implementation Review Teams applies to all pending PDPs, but not to PDP’s that were conducted under the prior PDP rules.