Skip to main content

Policy vs. Implementation

Comment/Reply Periods (*) Important Information Links
Comment Open: 31 January 2013
Comment Close: 21 February 2013
Close Time (UTC): 23:59 Public Comment Announcement
Reply Open: 22 February 2013 To Submit Your Comments (Forum Closed)
Reply Close: 14 March 2013 View Comments Submitted
Close Time (UTC): 23:59 Report of Public Comments
Brief Overview
Originating Organization: ICANN Staff
Categories/Tags: Policy Processes
Purpose (Brief): In order to encourage feedback on the ICANN Staff Paper Policy vs. Implementation – Draft Framework for Discussion [PDF, 195 KB], a public comment forum has now been opened.
Current Status: ICANN Staff has developed a paper outlining a draft framework for community discussion that identifies a number of steps and criteria that might facilitate dealing with questions relating to policy vs. implementation in the future.
Next Steps: The received comments are expected to feed into the session that is being planned on this topic at the ICANN meeting in Beijing.
Staff Contact: Marika Konings Email:
Detailed Information
Section I: Description, Explanation, and Purpose

Mainly as a result of discussions stemming from implementation related issues of the new gTLD program, there is increased focus on which topics call for policy and which call for implementation work, including which processes should be used, at what time and how diverging opinions should be acted upon. In order to facilitate these discussions, ICANN Staff has developed a draft framework for community discussion that identifies a number of steps and criteria that might facilitate dealing with similar questions in the future. The paper [PDF, 195 KB] identifies a number of questions that the community may want to consider further in this context, as well as a couple of suggested improvements that could be considered in the short term. While developing a bright-line rule as to what is policy or implementation may not be possible, the hope is that by developing clear processes and identifying clear roles and responsibilities for the different stakeholders, it will become easier to deal with these issues going forward and allow for broad participation and involvement. In order to facilitate discussions on this topic, a session is being scheduled at the ICANN meeting in Beijing. Input received as a result of this public comment forum is intended to feed into those discussions, which are also intended to identify next steps.

Section II: Background

There are multiple kinds of "policy" within the ICANN world. There are formal policies developed through the policy development processes as set forth in the Bylaws. There are operational policies generally not subject to a PDP or considered implementation, such as the Conflicts of Interest Policy, but for which public comment is sought and considered. Finally, there are general practices that are sometimes referred to as "little p" policies or more accurately "procedures", such as the 30-day public comment requirement for Bylaw changes. Within this category again there are a variety of considerations. There could be established practices, for example, on topics that although within scope of a policy development process (PDP) have not resulted in a formal recommendation to the Board that could serve as authoritative "Policy." In some of those instances, for example vertical integration or registrar accreditation procedures, ICANN identified a path forward and if a policy recommendation on these topics were to later arise through a PDP, ICANN would then consider how that policy might impact or require change to established practice(s) (resulting in "Policy").

One area that is ripe for further discussion within the ICANN community is identifying the proper process to follow when there are changes to policy recommendations that have already been adopted by the Board, or to the proposals related to the implementation of approved policy recommendations. Questions have been raised about when those issues need to be vetted using a new PDP and when it would suffice to use public comment to vet a proposed change for public comment and for the Board and/or staff to act on that based on the comment received. Such questions arose, for example, during the evolution of the applicant guidebook for the New gTLD Program, and also during the negotiation of key contracts such as the .com and .net registry agreements regarding the impact of potential incorporation of a "thick" Whois registry model.

Another, associated issue is when resolution of a new issue should be supported by a consensus of the ICANN community, and when an issue arising from the implementation of a policy may be effectuated by the ICANN Board or ICANN Staff upon taking a range of advice even if there is no consensus within the ICANN community.

In order to better deal with the issues outlined in this paper, ICANN Staff has outlined a number of proposed principles to serve as a basis for this discussion as well as developed a proposed framework which can be found in the annex to the paper.

Section III: Document and Resource Links
Policy versus Implementation – Draft Framework for Discussion [PDF, 195 KB]
Section IV: Additional Information

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."