Thanks Ariel - and thanks to Kristine, who said it better than I could. Susan Payne Head of Legal Policy Valideus 28-30 Little Russell Street London WC1A 2HN United Kingdom D: +44 (0) 20 7421 8255 T: +44 (0) 20 7421 8299 M: +44 (0) 7971 661175 E: susan.payne@valideus.com www.valideus.com Liability cannot be accepted for statements made which are clearly the sender’s own and not made on behalf of Valideus. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Valideus Ltd is registered in England and Wales with company number 06181291 and VAT number 272 9057 85. Our registered office is at 28-30 Little Russell Street, London, WC1A 2HN. ________________________________ From: Gnso-rpm-sunrise <gnso-rpm-sunrise-bounces@icann.org> on behalf of Ariel Liang <ariel.liang@icann.org> Sent: Monday, June 24, 2019 10:44:10 AM To: Kristine Dorrain; gnso-rpm-sunrise@icann.org Subject: Re: [Gnso-rpm-sunrise] [Ext] RE: Question 6 (a-c) proposed text Hello Kristine, Thank you for pointing out about the delay in updating the wiki. We have now uploaded the latest Status Check document to the wiki as well. Staff can incorporate your proposed text in the Status Check document (in green) and also include your proposed text in the slide deck as additional slides to be consistent. We will also post the updated version Status Check doc in the wiki. Thank you again for your feedback. Best Regards, Ariel From: "Dorrain, Kristine" <dorraink@amazon.com> Date: Monday, June 24, 2019 at 9:38 AM To: Ariel Liang <ariel.liang@icann.org>, "gnso-rpm-sunrise@icann.org" <gnso-rpm-sunrise@icann.org> Subject: [Ext] RE: [Gnso-rpm-sunrise] Question 6 (a-c) proposed text Thanks Ariel, Mary, and Julie, We had taken the most current status doc from the wiki as the most current doc and didn’t realize that the emailed doc was something different. Our proposal is different from your text because we didn’t understand there to be wide divergence as your proposed answer suggests. Indeed, we had taken a stab at language because we felt there was good agreement on the call (albeit tentatively, as everyone wanted to think a little more about it). I’d like to propose that we consider the text Susan and I submitted because if we do have consensus, it would help move our report along. The status doc is full of “we can’t agree” and it would be nice to capture places where we did agree. If people in the group disagree with our text, then we could, as you propose, include our language in the deliberations section, but at this point, we believe our text is more than deliberations and may in fact represent a consensus view. I understand we don’t want to open up the doc to wordsmithing viewpoints that are divergent, but I’m deeply concerned that we’re going to submit an initial report that has almost no actual recommendations because we can’t agree on anything. If we can find places where we agree, it’s critical that we include that. Best, Kristine From: Ariel Liang <ariel.liang@icann.org> Sent: Saturday, June 22, 2019 1:46 AM To: Dorrain, Kristine <dorraink@amazon.com>; gnso-rpm-sunrise@icann.org Subject: Re: [Gnso-rpm-sunrise] Question 6 (a-c) proposed text Hello Kristine and Susan, Thank you very much for proposing the new language for Q6(a)-(c). On Wednesday, 19 June, staff sent out the updated Status Check document which include proposed language by the Co-Chairs in collaboration with staff. This email (attached) may be missed due to travels. We have included the proposed language for Q6 in the updated status check document below. As you can see, the updated version is much briefer; the discussions and deliberations text will be included in the Summary Table, so nothing will be lost. Please be so kind to review the updated version below and let us know if you have any additional feedback / see whether any revision to your proposed language is needed. Thank you, Mary, Julie, Ariel == Q6(a): What are Sunrise Dispute Resolution Policies (SDRPs), and are any changes needed? Proposed Answer: The Sub Team noted that SDRPs are explained in the Section 6.2.2 and 6.2.4 of Module 5 of the Applicant Guidebook. The Sub Team generally recognized that it is not within the scope of the RPM PDP WG to recommend changes to any Registry Operator specific SDRPs. The Sub Team had widely diverging opinions on whether any changes, deletions, or additions to the mandatory grounds are needed. Q6(b): Are SDRPs serving the purpose(s) for which they were created? Proposed Answer: The Sub Team had widely diverging opinions on whether SDRPs are serving the purpose(s) for which they were created. Q6(c): If not, should they be better publicized, better used or changed? Proposed Answer: Since the Sub Team had widely diverging opinions on whether SDRPs are serving the purpose(s) for which they were created, it did not consider this question. From: Gnso-rpm-sunrise <gnso-rpm-sunrise-bounces@icann.org<mailto:gnso-rpm-sunrise-bounces@icann.org>> on behalf of "Dorrain, Kristine via Gnso-rpm-sunrise" <gnso-rpm-sunrise@icann.org<mailto:gnso-rpm-sunrise@icann.org>> Reply-To: "Dorrain, Kristine" <dorraink@amazon.com<mailto:dorraink@amazon.com>> Date: Friday, June 21, 2019 at 8:53 PM To: "gnso-rpm-sunrise@icann.org<mailto:gnso-rpm-sunrise@icann.org>" <gnso-rpm-sunrise@icann.org<mailto:gnso-rpm-sunrise@icann.org>> Subject: [Gnso-rpm-sunrise] Question 6 (a-c) proposed text Hi everyone: In an effort to move things along on the murky SDRP questions, Susan and I worked to come up with some initial report language that we think the group might be able to agree on and submit it here for your review. If we can get consensus, we can remove all the “some subteam members” language. :) Thanks and safe travels, Kristine Q6(a): What are Sunrise Dispute Resolution Policies (SDRPs), and are any changes needed? Proposed Answer: According to the Section 6.2.2 and 6.2.4 of the Trademark Clearinghouse Model of Module 5 of the Applicant Guidebook, SDRP is a mechanism that a Registry Operator must provide to resolve disputes regarding its registration of Sunrise Registrations. It allows challenges to Sunrise Registrations related to Registry Operator’s Allocation and registration policies, on four non-exhaustive grounds, including on the grounds that the domain name that was registered does not identically match the Trademark Record on which the Sunrise-Eligible Rights Holder based its Sunrise Registration. In the time between when the AGB was written and the TMCH requirements were established, the TMCH dispute procedure was created. This procedure allows for challenges to the recordal of marks in the TMCH that underlie Sunrise Registrations. As a result two of AGB requirements for Registry Operator SDRPs are moot; and in any event the registry operator is not the best-placed party to adjudicate these challenges due to the fact that the registry operator is reliant on trademark eligibility information provided to it by the TMCH. We propose a resolution that codifies the current practice, with no changes. Recommendations: The SubTeam recommends that the next Applicant Guidebook be amended as follows: 1. We recommend: the new version of the AGB should include the TMCH dispute resolution procedure for challenging the validity of trademark recordals entered into the TMCH. This procedure is currently published at: https://www.trademark-clearinghouse.com/dispute#3.3 [trademark-clearinghouse.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trademark-2Dclearin...>. ICANN Org should ensure that its contract for the provision of TMCH services makes the operation of the TMCH dispute resolution procedure a requirement for the TMCH Provider. 2. We recommend: What is current AGB (Module 5) Trademark Clearinghouse Model, section 6.2.4 be amended to remove (i) and (iii). 3. We recommend: The AGB (Module 5) 6.2.4 be amended to include 6.2.6 – the Registry Operator will, upon receipt from the TMCH of a finding that a sunrise registration was based upon an invalid TMCH record (pursuant to a TMCH dispute resolution procedure), immediately cancel the domain name registration. Note: Registry Operators should continue to have the option to offer a broader SDRP to include optional/additional Sunrise criteria as desired. [The below are just edited from the staff doc using both color (red/green) and traditional strike-through/underline to identify deletions/additions.] Q6(b):Are SDRPs serving the purpose(s) for which they were created? Proposed Answer: The Sub Team had difficulty determining whether SDRPs are serving the purpose(s) for which they were created, as each TLD has its own SDRP and there is hardly any data or analysis of the SDRP decisions across all new gTLD. Some sub team members have proposed a solution in Q6(a) that will eliminate the non-functional parts of the SDRP requirements and codify the current practice. Some Sub Team members believe that, in general, SDRPs do not seem to serve the purpose(s) for which they were created. One Sub Team member believes that SDRPs seem obsolete because the TMCH already has a mechanism to challenge the underlying trademark record of a Sunrise registration. Another Sub Team member believes that the limited access to the TMCH and the lack of trademark information to identify whether a complaint is well-grounded makes it difficult to challenge a registration via the SDRP. Nevertheless, one Sub Team member believes that the SDRPs are generally serving the purpose(s) for which they were created despite their low usage. Q6(c): If not, should they be better publicized, better used or changed? Proposed Answer: Some SubTeam members have proposed some useful changes in Q6(a). One Sub Team member commented that whether SDRPs should be better publicized is contingent on whether they are serving the purpose(s) for which they were created. However, it is not harmful for Registry Operators to periodically remind registrants of the existence of SDRPs. One Sub Team member believes that it is not within the scope of the RPM PDP WG to recommend how SDRPs can be better used. It is up to the Registry Operators and challengers to decide. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>