At-Large Policy vs. Implementation Workspace

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.

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, ICANNwould 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 ICANNcommunity, and when an issue arising from the implementation of a policy may be effectuated by the ICANN Board orICANN 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.