Posted as requested by Barbara Roseman, ICANN Staff Manager GNSO Secretariat John and Dan, The GNSO Council working as the task force on the Approval Process for New or Changed Registry Services has developed a process flow that outlines the key decisions and processes involved in evaluating proposed changes to Registry services. These can be found at: http://gnso.icann.org/issues/registry-services/approval-process-24mar04.pdf, http://gnso.icann.org/issues/registry-services/quick-look-24mar04.pdf, and http://gnso.icann.org/issues/registry-services/detailed-review-24mar04.pdf. These are some of the questions that the task force has developed in their discussions. They fall into a few broad categories: 1) Approval of change requirements a) Do all changes that require approval require Board approval? b) If there are situations that do not require Board approval, are those clearly defined? 2) Criteria of evaluation a) Which of the broad criteria identified by the task force fall within ICANN's purview as determined by ICANN's Mission, Bylaws, and relevant contracts? b) How can these broad criteria be most usefully defined for ICANN staff to use in the approval process? (Bruce has suggested that I prepare a draft of how staff would like to see these criteria applied as elements of the "quick look" and "detailed look" processes. This is being prepared.) The list of criteria broadly outlined by the taskforce includes: Adherence to standards: - Does it comply with Internet standards or de-facto standards - Does it require open or closed standards to use - Consistency with the end-to-end Internet protocol principle (= de-facto nature) - Does it require users to use a closed standard software Security and stability - Does it disrupt the Internet - Does it affect other protocols - Does it cause cost at the edge - Could it be offered closer to the edge of the Internet - Are the effects to the users at large acceptable - Do overall benefits to the community outweigh any negative impact - Predictability, do we understand how it will affect applications and users, and how it affects stability - Reliability - Is the change reversible, what is the cost of reversing Impact on third parties - Consequences of third party reaction - Does it affect rights of stakeholders - e.g privacy, competition rights - Does it affect all users without choice - Does it change expectations of users - Does it only affect the registrant of the stld versus users of the stld - Could it harm legitimate interests (e.g intellectual property) - What is the cost of failure to third parties (impacted stakeholders) - Does it cause legal conflicts (e.g with local laws relating to disclosure of personal information) Degree of community support - Whether the service has been approved by sponsors community Market forces - Can the market measure whether good/bad idea, is there choice - Does size matter (market power) - competition analysis 3) Appeals process a) Are the existing appeals processes defined in the Bylaws sufficient to address the issues likely to arise during appeals related to the approval process (Reconsideration, IRP)? In which instances (as outlined in the process flow) would an appellant use Reconsideration as opposed to the IRP? b) In Reconsideration (Bylaws, Article IV, Section 2) while there is a defined period for determining whether to proceed with Reconsideration (30 days), there is no defined time for the work of the Reconsideration Committee once they have taken up an issue for review. Would it be possible to write specific timelines into either the Reconsideration process or the Approval process for Reconsideration appeals relating to the approval of new/changed registry services to facilitate timely evaluation of proposals? c) If the existing review processes are not appropriate for use in relation to the approval process, how should a new appeals process be developed?