Registrar Stakeholder Group Position Regarding PDP Process Work Team Initial Report and Draft Recommendations
April 1, 2011 Registrar Stakeholder Group Position Regarding PDP Process Work Team Initial Report and Draft Recommendations BACKGROUND The Registrar Stakeholder Group ("RrSG") is providing feedback regarding the Initial Report and Draft Recommendations from the Policy Development Process Work Team. This paper captures the sentiment expressed by RrSG members who provided feedback on the issue. No formal vote regarding the position was taken. RrSG OVERALL POSITION The RrSG applauds the work of the WT. Over the past one to two years, the RrSG has grown concerned about an increasingly overtaxed community and ICANN staff and believes it's important to both refine the PDP and find a responsible way to prioritize the GNSO's work. Broadly speaking, the RrSG believes: * PDPs should be based on responsibly documented evidence of an issue to be addressed. Anecdotal evidence is insufficient. A reasonable data-driven threshold for introduction of a PDP is a necessary step to concentrating community resources on PDPs where there is evidence to justify a PDPs initiation. * Our SG, and we suspect others, sometimes struggle between the demands of daily business responsibilities and the significant burden of thoroughly contributing (sometimes concurrently) to all issues under GNSO consideration. SGs often rely on "volunteer" leadership and work production, which is not infinite. * Particularly in light of the constraints on ICANN's predominately volunteer community, some PDPs, while possibly well-intentioned, have proven impractical and have needlessly consumed staff and community resources to the detriment of more timely and critical issues. * ICANN staff resources also are finite. All members of the GNSO community should be responsible stewards of ICANN's time and resources, including respectful use of the staff's time. The current level of work now being handled is not sustainable in the long term. RrSG positions on specific recommendations of the WT With the above context in mind, the RrSG takes positions on each of the following points or recommendations of the WT: Recommendation 4: The PDP-WT recommends that a 'request for an issues report' template should be developed including items such as definition of issue, identification of problems, supporting evidence, and rationale for policy development. Further consideration would need to be given as to whether some of these elements should be required before a request is considered by the GNSO Council. Such a template should become part of the above mentioned Policy Development Process Manual or Guidebook. The RrSG believes this is a responsible step toward making future polices based on evidence and facts, and not on "what-ifs." ICANN, as a technical coordination body, cannot reasonably anticipate all the potential ills that could befall the DNS. The WT's recommendation for a template that includes a clearly defined problem, well-documented supporting evidence, and a rationale for the use of increasingly very limited resources for development of policy, would be a useful tool. In alignment with this recommendation, the RrSG recommends that any manual or guidebook encourage that ICANN participants be mindful and respectful of ICANN's limited resources. The RrSG looks forward to a continued discussion of what would constitute a reasonable threshold for initiating a PDP. Recommendation 7: The PDP-WT recommends better information and communication with Working Group members on the potential outcomes of a policy development process. Contrary to the belief of a number of members of the community, there are more potential outcomes of the PDP process than just the formation of "consensus policies" as defined under the applicable gTLD Registry and Registrar agreements. Acceptable outcomes include the development of best practices, recommendations to other supporting organizations, recommendations for future policy development, etc. This information could be included in the Charter of a Working Group or in the instructions to a WG. It is also an element that should be included in the Policy Development Process Manual or Guidebook. The RrSG welcomes this recommendation. Issues should be met with the solution that most appropriately resolves them, and over-reliance on strict regulation is detrimental to the growth and health of the DNS and the industry. The business advice to "begin with the end in mind" is reflective of the above recommendation, and the RrSG believes it would help a PDP be correctly focused and more efficient. Recommendation 13: The PDP-WT recommends that the Policy Development Process Manual or Guidebook describe the option for the GNSO Council to require that an impact analysis be conducted if appropriate or necessary prior to the vote for the initiation of a PDP. Such an impact analysis could include the assessment of the economic impact, the impact on competition, the impact on consumer choice and/or protection, etc. The RrSG agrees with this recommendation and believes it would be a prudent step in a PDP. Those proposing policy or regulation are obligated to responsibly, and respectfully, consider their impact on all affected parties. The RrSG recommends that the PDP-WT add to this recommendation that impact analyses include, to the extent possible, an assessment of impact to the following: * Operations of registries, registrars, and service providers * ICANN as an entity (including ICANN's revenue) * End-users and customers of the DNS Recommendation 14: The PDP-WT believes that the GNSO Council should prioritize PDPs and ensure that the resources exist (both staff and volunteer) upon the initiation of a PDP. In light of the upcoming GNSO Council Prioritization activity, the PDP-WT is deferring the specifics of how such prioritization can be achieved pending the outcome of such activity. The RrSG concurs with this recommendation as well. At present, the community and staff are obliged to address all open issues simultaneously, probably to the detriment of final outcomes. There simply isn't enough time or resource available to thoughtfully consider each issue. Further, it's apparent that established models are suffering-an example is the recent need to extend many of the open comment periods to give the community time to "catch up" with the workload. The RrSG is aware of the GNSO's recent effort to find a way to prioritize its agenda. Whatever final method is decided on, the RrSG firmly believes it should be as free from possible "gaming" as practical. GNSO groups must act more in cooperation on important issues. The RrSG looks forward to continued discussion of prioritization methods. Recommendation 24: The PDP-WT recommends modifying clause 3 - Initiation of a PDP to clarify that within scope means 'within scope of ICANN's mission and more specifically the role of the GNSO' as opposed to within scope of the contracted parties' definition of "consensus policies." The RrSG found this language to be confusing and would appreciate clarification from the WT. With regard to the general issue, however, the RrSG believes ICANN's role, as it has been historically, is that of a technical coordination body, and that it should limit itself to its role and resist "mission creep." Further, the SG believes the GNSO is a policy development body and should honor its role as such and not confuse policy development with policy implementation. Recommendation 32: the PDP-WT recommends that staff resources needed or expected in order to implement the policy recommendations should be evaluated as part of the WG recommendations, and as part of the Council's review of those recommendations, as part of the feasibility analysis and/or impact statement (see recommendation 31). The RrSG concurs with this and encourages adoption of this provision as part of PDP reform. Recommendation 38: The PDP-WT recommends to (sic) provide additional guidance to GNSO Council in the Policy Development Process Manual or Guidebook on how to treat Working Group recommendations, especially those that have not received full consensus and the expected / desired approach to adoption of some, but not all, or rejection of recommendations. There is discussion within the PDP-WT whether the GNSO Council should have the flexibility to 'pick and choose' recommendations. There is no agreement yet on what guidance, if any, should be given on recommendations that have not received full consensus. The PDP-WT hopes to receive further input on this issue during the public comment period. The RrSG has no currently formed position on this issue but agrees it's an issues that deserves attention, and looks forward to contributing to further discussion. Recommendation 42: The PDP-WT recommends creating a WG Implementation Review Team, which would be responsible in (sic) dealing with implementation issues. The PDP-WT has not arrived yet at a possible recommendation in relation to how the process for reviewing and addressing implementation questions would work and hopes to receive further input on this issue during the public comment period (see also recommendation 31). The RrSG has no objection to this recommendation; however, it should be considered in the context of the RrSG's abovementioned concerns about an overtaxed staff and volunteer community. A team could be very useful, but only if a commensurate amount of work is reduced to accommodate the demands of such a review team. RrSG position on Section 3 of the report: Planning and Request for an Issues Report With regard to area 3 of the report, as noted/asked by the WT: 3.a. In theory, there is currently no limit on these issues that can be raised as there is no requirement for the issue to be 'within scope' (i.e. either within the "picket fence" of the gTLD Registry and Registrar agreements or within the parameters of ICANN's mission as it relates to the GNSO in general). This assessment is carried out as part of the issues report. Should an initial assessment take place when an issue is raised. The WT reported: It was suggested that ICANN staff should be willing to do an initial assessment of scope if requested by the body that is planning to raise an issue. ICANN staff has expressed a concern that assessing whether an issue is in scope may be difficult, but at the very lease would require that issues are narrow and defined or order for this determination to be made. The RrSG replies: ICANN was established with parameters for good reasons - to keep the organization from overreaching and causing disruption, to clearly define its role, etc. If the GNSO is willing to continue accepting every issue that's raised, whether in scope or not, ICANN will continue to experience the difficulties it now does. Many things that have to do with ICANN's work are difficult, but setting reasonable boundaries about its scope should not be one of them. 3.b. Should the requestor identify the desired goal/outcome of a PDP? The WT reported: It was suggested that those requesting the issues report should be encouraged to identify potential outcomes, if possible, as long as this would not bias or restrict the Working Group in its activities and recommendations. The RrSG replies: No potential outcome should be dictated as part of a PDP, though the SG agrees a requestor should identify potential outcomes if possible, without bias. It would be helpful and would encourage efficiency if the requestor would clearly state the objective of a PDP. 3.c. What actions are needed in order to ensure a precise and narrow definition of an issue? The WT reported: ...A suggestion was made that there should be a mechanism by which there is not sufficient information available an issue does not pass to the next stage. The RrSG replies: That is a reasonable suggestion. Proceeding blindly on policy development without sufficient information is irresponsible. 3.d. Should an initial assessment be foreseen whether GNSO policy development is the appropriate response to the issue raised or whether other alternatives are deemed more efficient to achieve the desired outcome? The WT reported: Some suggested this could be part of the staff response if requested, but it should not affect the ability to raise an issue. It was also noted that a policy development process can cover a broad range of issues and have a variety of outcomes. The RrSG replies: The RrSG agrees a variety of alternatives should be employed to address issues of concern to the community. A PDP may or may not be the appropriate method. CONCLUSION The opinions expressed by the RrSG in this position paper should not be interpreted to reflect the individual opinion of any particular RrSG member.