hi all, here's a first draft of a comment. there is plenty of time before comments are due, so feel free to make massive changes. :-) i've included it in the email, and also attached the Word version. mikey DRAFT ISPCP Comments on: Trademark Clearinghouse “Straw Man Solution” 1. Background The ISPCP is responding to ICANN’s request for community feedback on a “straw man solution” that was developed by a group of stakeholder representatives who met at ICANN’s offices in Los Angeles, CA on 15 and 16 November, 2012. Representatives of four members of the ISPCP participated in the meeting, two in person and two via remote participation. The ISPCP is on record with the following comment, made in the Toronto meeting in response to the proposal put forward by the BC and IPC: The ISPCP Constituency; • Endorses the intent and critical importance of preventing fraudulent registrations and reducing costs of defensive measures; • Agrees that the rights protection mechanisms currently in the Guidebook are insufficient to meet these goals; and • Wishes to remain neutral on the specific Rights Protection Mechanisms necessary to achieve those goals. In keeping with that position, our comments will focus on issues of process and the ISPCP will continue to remain neutral on the subject of specific RPMs. 2. Policy vs. Implementation The fundamental issue that underlies the debate about the Straw Man Solution has to do with the process by which it was developed and the question “which of these things are issues that need to go through some form of GNSO policy-making process, and which are implementation issues that do not?” Alan Greenberg made a telling comment when, on the first day of discussion, he posted to the Adobe chat “My working definition is that if you want the change, it is implementation. If you are against it, it is policy.” That comment, while made somewhat in jest, nevertheless frames up our concern fairly well. The ISPCP expresses its continued wholehearted support for the bottom-up consensus-based policy making process of the GNSO and cautions that ICANN (both the corporation and the community) bypasses that process at its peril. History shows that ICANN (the corporation and the community) have an inconsistent track record when we shortcut the policy making process to meet a tight timetable. The Straw Man Solution is just one example of this situation, other examples include: • Vertical Integration • IRT • STI • Protection for IOC/RC names • WHOIS review team recommendations • TMCH design The ISPCP supports the bottom-up policy making process because we think it is a useful and effective way to conduct deep analysis and bring about agreement across diverse interests and points of view. It is true that the GNSO policy process takes longer, but we do not find that to be a compelling argument to look for shortcuts. 3. A proposed framework for deciding what is “implementation” vs. “policy” Early in the first day of the Los Angeles meeting, ICANN’s Senior Policy Counselor Margie Milam led a discussion of a framework that can be used to sift issues between policy and implementation. We feel that this framework (summarized below) is a good one and we encourage the GNSO (and the rest of ICANN) to quickly refine and endorse a process of this type. A proposed action: Is an "implementation change" if… Criteria • It is not a result of a policy discussion • Does not materially change community proposed approach Process • Depends on scope/nature of proposed change • Must include public comment or input that is informed by analysis Safeguard • If public comment indicates Policy Guidance is required, then move it into the "policy guidance" column Is in the "policy guidance required" column if it's either An issue that can be addressed by a "policy guidance working-group" Criteria • Affects limited parties or for limited period • New information available or original approach not workable • Does not change intent of policy Process (recommended) • SO/AC forms "Policy Guidance" working group • SO/AC consideration of Policy Guidance working group recommendation (including public comments) An issue that should use the full PDP (policy development process) Criteria • New issue • One affecting all registry and registrar agreements • Long lasting impact on multiple parties • Alters policy intent Process • PDP process as described in ICANN bylaws and GNSO PDP manual 4. Meeting our commitments But what about the urgent issues that simply can’t wait for the stately wheels of GNSO policy making to turn? ICANN (especially ICANN the corporation) has commitments that need to be met. The executive management team is acutely aware that it needs to deliver a number of pre-defined target deliverables to widely publicized dates, especially in the rollout of the New gTLD Program. While the ISPCP endorses the intent and critical importance of preventing fraudulent registrations and reducing costs of defensive measures, and that the rights protection mechanisms currently in the Guidebook are insufficient to meet these goals, we feel that there are other commitments that need to be met as well. • The Board has announced that the rights protection issue has been finalized for new gTLDs. • Fadi and his team have hard dates that they have to meet and need to have a solid set of “requirements” from which to work. • Applicants have signed contracts with ICANN that are based on the language in the Applicant Guidebook. When we weigh these commitments against our view that rights protection mechanisms still need improvement, we view “scope management” as a tool to apply in order to find a way out of this dilemma. 5. The ISPCP position Having weighed these issues and discussed them among our membership, the ISPCP concludes that: 1. The bottom-up policy process is important and we bypass it at our peril 2. The proposals in the Straw Man need an expedited "policy vs. implementation" discussion/decision by the Council, preferably following a process similar to the one described in Margie Milam’s presentation 3. There is very uneven support for the various proposals at this point, ranging from tepid agreement to strong opposition. The ISPCP remains in the middle – interested in finding a good solution, but not at the expense of meeting our other commitments and responsibilities. 4. The work of rolling out the new gTLD program needs to proceed and is on a very tight schedule 5. Thus, there should be minimal changes to the TMCH, the AGB and RPMs in this round and the GNSO should take up most of the proposals in due order. PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)