[ispcp] DRAFT -- comment on the Straw Man Proposal -- DRAFT
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">hi all,<div><br></div><div>here's a first draft of a comment. there is plenty of time before comments are due, so feel free to make massive changes. :-)</div><div><br></div><div>i've included it in the email, and also attached the Word version. </div><div><br></div><div>mikey</div><div><br></div><div><div><b>DRAFT </b></div><div><b> </b></div><div><b>ISPCP Comments on:</b></div><div><b><br></b></div><div><b>Trademark Clearinghouse “Straw Man Solution”</b></div><div><br></div><div><b>1.<span class="Apple-tab-span" style="white-space:pre"> </span>Background</b></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>The ISPCP Constituency;</div><div><br></div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Endorses the intent and critical importance of preventing fraudulent registrations and reducing costs of defensive measures;</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Agrees that the rights protection mechanisms currently in the Guidebook are insufficient to meet these goals; and</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Wishes to remain neutral on the specific Rights Protection Mechanisms necessary to achieve those goals. </div><div><br></div><div>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.</div><div><br></div><div><b>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Policy vs. Implementation</b></div><div><br></div><div>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?”</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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:</div><div><br></div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Vertical Integration </div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>IRT</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>STI</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Protection for IOC/RC names </div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>WHOIS review team recommendations</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>TMCH design</div><div><br></div><div>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.</div><div><br></div><div><b>3.<span class="Apple-tab-span" style="white-space:pre"> </span>A proposed framework for deciding what is “implementation” vs. “policy”</b></div><div><br></div><div>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.</div><div><br></div><div>A proposed action:</div><div><br></div><div>Is an "implementation change" if…</div><div><br></div><div>Criteria</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>It is not a result of a policy discussion</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Does not materially change community proposed approach</div><div><br></div><div>Process</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Depends on scope/nature of proposed change</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Must include public comment or input that is informed by analysis</div><div><br></div><div>Safeguard</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>If public comment indicates Policy Guidance is required, then move it into the "policy guidance" column</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span> </div><div>Is in the "policy guidance required" column if it's either </div><div><br></div><div>An issue that can be addressed by a "policy guidance working-group" </div><div><br></div><div>Criteria</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Affects limited parties or for limited period</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>New information available or original approach not workable</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Does not change intent of policy</div><div><br></div><div>Process (recommended)</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>SO/AC forms "Policy Guidance" working group</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>SO/AC consideration of Policy Guidance working group recommendation (including public comments)</div><div><br></div><div>An issue that should use the full PDP (policy development process) </div><div><br></div><div>Criteria</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>New issue</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>One affecting all registry and registrar agreements</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Long lasting impact on multiple parties</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Alters policy intent</div><div><br></div><div>Process</div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>PDP process as described in ICANN bylaws and GNSO PDP manual</div><div><br></div><div><br></div><div><b>4.<span class="Apple-tab-span" style="white-space:pre"> </span>Meeting our commitments</b></div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>The Board has announced that the rights protection issue has been finalized for new gTLDs. </div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>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. </div><div>•<span class="Apple-tab-span" style="white-space:pre"> </span>Applicants have signed contracts with ICANN that are based on the language in the Applicant Guidebook. </div><div><br></div><div>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. </div><div><br></div><div><b>5.<span class="Apple-tab-span" style="white-space:pre"> </span>The ISPCP position</b></div><div><br></div><div>Having weighed these issues and discussed them among our membership, the ISPCP concludes that:</div><div><br></div><div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>The bottom-up policy process is important and we bypass it at our peril</div><div><br></div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>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</div><div><br></div><div>3.<span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br></div><div>4.<span class="Apple-tab-span" style="white-space:pre"> </span>The work of rolling out the new gTLD program needs to proceed and is on a very tight schedule</div><div><br></div><div>5.<span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div></div><div><br></div><div></div></body></html> Attachment:
ISPCP -- Strawman comments v1.doc <html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><div apple-content-edited="true"> <br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com";>www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)</span> </div> <br></div></body></html> |