DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language:
Dear all, Per the WG Co-Chairs, please note the deadline for this action: Please send comments if any to this list not later than COB Friday, 25 September. Note also that the WG discussion of Sunrise Recommendation #2 and the original Implementation Guidance language will be on the agenda for the WG meeting on Tuesday, 29 September, to be followed by a separate discussion of the Sub Team 2 suggested Implementation Guidance language. As a reminder, here is a link to Sunrise Recommendation #2 and the original Implementation Guidance language: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-.... Also as a reminder, here is the proposed Implementation Guidance language for Sunrise Recommendation #2 from Small Team 2: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Tuesday, September 22, 2020 at 4:09 PM To: "gnso-rpm-wg@icann.org" <gnso-rpm-wg@icann.org> Subject: [GNSO-RPM-WG] REMINDER - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below and post any comments to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Thursday, September 17, 2020 at 5:07 PM To: "gnso-rpm-wg@icann.org" <gnso-rpm-wg@icann.org> Subject: [GNSO-RPM-WG] ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below from the WG meeting on 17 September: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Please see the suggested revisions to Sunrise Recommendation #2 in the Google document at: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/12w5W2bQcviAqL...>. Please also review the following Suggested Language from Small Team: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Please post any comments or questions for discussion to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org> Date: Thursday, September 17, 2020 at 2:49 PM To: "gnso-rpm-wg@icann.org" <gnso-rpm-wg@icann.org> Subject: [GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 17 September 2020 Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 17 September 2020 at 17:00 UTC. Staff will post these to the wiki space. Please note that these are high-level notes and are not meant as a substitute for the recording, chat room, or transcript. The recording, Zoom chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2020-09-17+Review+of+all+Ri.... Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS Actions: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4: ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. URS Final Recommendation (was #1): ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. New URS Final Recommendation: ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Sunrise Recommendation #2 and Small Team 2 Suggested Language; see: Suggested Language from Small Team 2<http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004503.html> andhttps://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/12w5W2bQcviAqL...> -- Concerns raised by Maxim Alzoba about the two examples that they are too broad. -- Further to my point, as was noted earlier, this is a high-level policy recommendation; the IRT will be tasked with implementing this recommendation and our guidance should be sufficient to allow the IRT to craft an appropriately tailored RA amendment and (hopefully a challenge mechanism with appropriate safeguards built in so as to not inhibit legitimate registry activities -- I agree (I think) with Jason insofar as implementing this recommendation may necessitate a third party challenge mechanism akin to the PDDRP or pICDRP so aggrieved TM owners can challenge a registry activity and there can be a ruling as to whether the activity is legitimate or not. -- Concerns about misinterpretation if we are not clear. -- Perhaps we can just add a third bullet that says, “registry activities that have a bona fide legitimate basis or rationale are explicitly not intended to be inhibited by this provision”. -- As a staff suggestion for your consideration — perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice and pricing practice that are compliant with ICANN policies and procedures.”? -- Add to bullet point 1 (slightly revised)-- adding: "without countervailing rationale and/or reasonable activity by registries, including handling of dictionary terms.” -- Suggest addition to the Recommendation: “The Working Group recommends that the Registry Agreement for future new gTLDs include a provision stating that a Registry Operator shall not operate its TLD in such a way as to have the effect of [intentionally] circumventing the mandatory RPMs imposed by ICANN or restricting brand owners’ reasonable use of the Sunrise rights protection mechanism.” Text in brackets. -- Don’t think adding “intentionally” in the rec helps us because it doesn’t really address Maxim’s concern, because reserving a name intentionally as part of an ALP or something is still intentional. ACTION ITEM: Discuss suggested language from Small Team 1 on the list. Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” -- Why would the proposed additional implementation guidance language be a beneficial addition to the existing implementation guidance? Answer: Takes some of the burden off of Compliance. -- Does the phrase “explore the possibility of a third party challenge mechanism” encompass and authorize the IRT’s adoption and implementation of such a mechanism if it is found to be possible? Answer: To amend the language to “explore and if possible implement”. -- Would the challenge mechanism be operative against ICANN, a registry alleged to have circumvented a RPM, or both? Answer: It would be against the registry that is alleged to have circumvented it. There already is a way to challenge staff and Board actions. -- This would not be a mechanism as a way for ICANN Org Compliance to enforce – this would be a separate mechanism? Answer: Correct. Discussion: -- Opposed to this language. Sunrise Rec #2 itself is still vague. -- Registries agree by contract to comply, but IRTs cannot develop consensus policies or revise contract terms – so this is out of scope. -- This is putting one vagueness on top of another. -- What authority does an IRT have to do these types of things. -- Didn't an IRT create the URS, PDDRP, PICDRP, to name a few? -- Sunrise Rec #2 seems to beg for a third-party challenge mechanism. -- 1. Clause could include a clause to include a challenge mechanism. 2. IRTs do this sort of thing all the time (e.g. the AGB and all of the challenge mechanisms with it). -- Idea is that there would be an independent panel that an aggrieved party could go to – so not relying on ICANN Compliance and could be an independent review. -- Why isn't a complaint to ICANN compliance sufficient here? I agree with David that it's especially problematic to move from "vague standard applied by single decisionmaker" to "vague standard applied by various possible decisionmakers" -- Would this be a time-sensitive mechanism? -- Because in response to the complaints over the years on sunrise circumvention, ICANN has consistently said they could do nothing about it. -- Circumvention itself is not defined, so cannot be enforced. -- ICANN compliance would need to have a role, in a similar way it does in a PICDRP for instance; an independent panel would actually perform the substantive review and ICANN compliance would implement a panel finding, for example. -- If Rec 2 is "start doing something about it" then why isn't ICANN compliance the appropriate place? -- URS and PDDRP are not Consensus Policy either. They were created during implementation of the 2007 GNSO PDP on New gTLDs. -- Divergence in the WG on this suggested text. ACTION ITEM: Discuss the suggested language on the list. 3. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4; see: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004505.html “The Working Group recommends guidance to the Implementation Review Team that the Approved Launch Program (ALP) Application Review Guidelines be reviewed and clarified in order to address feedback obtained by the working group regarding the length of time and complexity of process involved in seeking to obtain approval for an ALP, and in particular recommends that the IRT consider the following: 1. Where ICANN can not make a determination regarding an ALP application it will notify the Registry Operator to that effect within 45 days stating explicit reasons for needing more time and further, provide a decision date projection plan within a time period not to exceed another 30 days. There should be a reasonable expectation that all negotiations should be completed within a 7 month period. 2. Where ICANN determines to decline an ALP application or make a request for further information ICANN will include a full explanation of the aspects of the ALP application ICANN deems to be acceptable and the aspects ICANN deems to be unacceptable.” Discussion: -- The reference to an ALP being adopted is in the TMCH procedures if approved it is outside of or in contravention of Sunrise. This is directly related to the operation of the Sunrise. -- TMCH RPMs Requirements document that is incorporated by reference into the AGB and the RA (http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-...). 4.5 deals with Launch Programs, specifically 4.5.2: Registry Operator MAY, prior to the start date of its Sunrise Period, apply to ICANN for approval to conduct a registration program not otherwise permitted by these TMCH Requirements. Such a registration program application could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD, which, if set forth in reasonable detail in the application for the TLD, will carry a presumption of being approved, unless ICANN reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. If Registry Operator seeks ICANN’s approval of a program under this Section 4.5.2, and such requested registration program is substantially similar to a...” ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. 4. URS Final Recommendations; see: https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPW... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1huKNcgg3VAk95...> a. URS Final Recommendation (was #1): -- Recommendation language stays as is. -- Contextual language – inserted text to reflect the WG’s agreement to include the EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. b. New URS Final Recommendation: -- This is based on URS Question 1. -- It is a new recommendation based on responses received in the public comment. -- The context comes from the WG discussion of URS Question 1. -- The public comment review is based on the discussion of URS Question 1 and suggestion for a recommendation. Discussion: -- Questions about the contextual language. Concern that the reference to Purpose 6-PA5 is somehow binding. -- Staff noted that it is not binding and there was no change to the new recommendation resulting from the WG’s review of the ICANN org’s EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference.
Thank you, Mary, Ariel, and Julie, Below are my comments regarding the draft Final Report language for Sunrise Recommendation 2, as well as the small team’s additional proposed draft language proposing an independent enforcement mechanism. I raised these issues on the Registries Stakeholder Group call two days ago and used that discussion to help inform my comments. But these comments are personal and not officially on behalf of my employer or of the RySG. First, with respect to the Final Report language on Sunrise Recommendation #2 and the original implementation guidance, I fully support the addition of the word ‘intentionally’ in the Recommendation prior to the word “circumventing”. A registry operator should not face potential enforcement action for unintended consequences. Further, I believe that the implementation guidance language needs to be tightened up to clarify that the “Discriminatory pricing practices” referenced at the second bullet listing non-exhaustive examples of practices that may circumvent an RPM means discriminating against a trademark holder in the sunrise period via extremely high premium pricing, followed by a much lower subsequent land rush or GA price that has resulted in bad faith registration and subsequent infringing use by registrants other than the mark holder. The sunrise registration RPM is meant to give a mark holder first opportunity to register a domain corresponding to its exact mark to prevent its bad faith registration and use by a cybersquatter, but that must be balanced against the fact that many trademarks consist of generic dictionary words that have inherent value and can be used by other potential registrants in a non-infringing manner, justifying a substantial premium price. Further, the premium price level in and of itself cannot be sole basis for a Compliance enforcement action as that would violate the “picket fence” that prohibits GNSO policy from prescribing or limiting the pricing of registry services. As this type of price discrimination leading to subsequent infringement will only become evident after the sunrise registration period has ended, the IRT will need to give consideration as to what appropriate enforcement against such registry operation practices should consist of. Second, I oppose the additional implementation guidance language from Small Team 2. While I applaud the team for its efforts, I cannot support a new enforcement mechanism wholly separate from ICANN Compliance. In my opinion, this is very far from the idea that went out to public comment – the idea of revising a registry agreement provision for future new gTLDs to elevate the general requirement on a registry to implement applicable policies to a specific requirement to refrain from circumventing new gTLD RPMs. The proposal would give to the IRT unchecked and inappropriate policy-making discretion to create a new enforcement mechanism absent any showing that the implementation of Sunrise Recommendation #2 will be insufficient to curb suspect practices. Further, the PDDRP is already available against a registry operator who encourages infringing second level registrations, and the recommendation we have agreed upon to allow unrelated rights holders to bring a combined PDDRP action against a registry operator will make it easier to demonstrate a pattern of intentional circumvention of the sunrise RPM resulting in harm to them. It seems to me that if this additional language is added to the existing language and perfected implementation guidance, then there will be a strong possibility that the entire Sunrise Recommendation #2 will end up lacking consensus support and not proceed to Council. Best regards, David David McAuley Sr International Policy & Business Development Manager Verisign Inc. 703-948-4154 From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Wednesday, September 23, 2020 11:58 AM To: gnso-rpm-wg@icann.org Subject: [EXTERNAL] [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear all, Per the WG Co-Chairs, please note the deadline for this action: Please send comments if any to this list not later than COB Friday, 25 September. Note also that the WG discussion of Sunrise Recommendation #2 and the original Implementation Guidance language will be on the agenda for the WG meeting on Tuesday, 29 September, to be followed by a separate discussion of the Sub Team 2 suggested Implementation Guidance language. As a reminder, here is a link to Sunrise Recommendation #2 and the original Implementation Guidance language: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-.... Also as a reminder, here is the proposed Implementation Guidance language for Sunrise Recommendation #2 from Small Team 2: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Tuesday, September 22, 2020 at 4:09 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] REMINDER - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below and post any comments to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Thursday, September 17, 2020 at 5:07 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below from the WG meeting on 17 September: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Please see the suggested revisions to Sunrise Recommendation #2 in the Google document at: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://secure-web.cisco.com/1FjwAVP01Qp6iUM2rsInfcO1zc3qY1OeyxbslL44ahBnD57...>. Please also review the following Suggested Language from Small Team: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Please post any comments or questions for discussion to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Thursday, September 17, 2020 at 2:49 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 17 September 2020 Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 17 September 2020 at 17:00 UTC. Staff will post these to the wiki space. Please note that these are high-level notes and are not meant as a substitute for the recording, chat room, or transcript. The recording, Zoom chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2020-09-17+Review+of+all+Rights+Protection+Mechanisms+%28RPMs%29+in+all+gTLDs+PDP+WG<https://secure-web.cisco.com/1pj-qVlupt78WOggqQBVxVYjoZzhpAILr_Kjzlnz0Q9dNOBFXaq031gYNHOThZiA6e4f06uthLyxmlMQlQyX7x95gLj9tD_66uMXKEik9YoAiBiXvZC1NtWzldGG_KJCEjz0LMqAAk1cc6wlMGN0DDzCrYDEoTEXgIXWIKE_kt082hEcRI7jM79jKpx8n2wT14ADjZBeRagmXdKLtuKqXvnAm-GD48SuByL7FiCTiwv_xKRc8GXV4mztb5JEhEBm8FmjynZGadWfwt1XqQSdSgA/https%3A%2F%2Fcommunity.icann.org%2Fdisplay%2FRARPMRIAGPWG%2F2020-09-17%2BReview%2Bof%2Ball%2BRights%2BProtection%2BMechanisms%2B%2528RPMs%2529%2Bin%2Ball%2BgTLDs%2BPDP%2BWG>. Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS Actions: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4: ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. URS Final Recommendation (was #1): ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. New URS Final Recommendation: ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Sunrise Recommendation #2 and Small Team 2 Suggested Language; see: Suggested Language from Small Team 2<http://secure-web.cisco.com/1ZQHItR6-GcLnN7flaJYMavZ68Kd0x80R9l3ty5lI1SXM8VS...> andhttps://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://secure-web.cisco.com/1GPaEQhm9H9M25BLwa6LTCBf6l5NTIJUjWXk8Zkqr68yF-8...> -- Concerns raised by Maxim Alzoba about the two examples that they are too broad. -- Further to my point, as was noted earlier, this is a high-level policy recommendation; the IRT will be tasked with implementing this recommendation and our guidance should be sufficient to allow the IRT to craft an appropriately tailored RA amendment and (hopefully a challenge mechanism with appropriate safeguards built in so as to not inhibit legitimate registry activities -- I agree (I think) with Jason insofar as implementing this recommendation may necessitate a third party challenge mechanism akin to the PDDRP or pICDRP so aggrieved TM owners can challenge a registry activity and there can be a ruling as to whether the activity is legitimate or not. -- Concerns about misinterpretation if we are not clear. -- Perhaps we can just add a third bullet that says, “registry activities that have a bona fide legitimate basis or rationale are explicitly not intended to be inhibited by this provision”. -- As a staff suggestion for your consideration — perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice and pricing practice that are compliant with ICANN policies and procedures.”? -- Add to bullet point 1 (slightly revised)-- adding: "without countervailing rationale and/or reasonable activity by registries, including handling of dictionary terms.” -- Suggest addition to the Recommendation: “The Working Group recommends that the Registry Agreement for future new gTLDs include a provision stating that a Registry Operator shall not operate its TLD in such a way as to have the effect of [intentionally] circumventing the mandatory RPMs imposed by ICANN or restricting brand owners’ reasonable use of the Sunrise rights protection mechanism.” Text in brackets. -- Don’t think adding “intentionally” in the rec helps us because it doesn’t really address Maxim’s concern, because reserving a name intentionally as part of an ALP or something is still intentional. ACTION ITEM: Discuss suggested language from Small Team 1 on the list. Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” -- Why would the proposed additional implementation guidance language be a beneficial addition to the existing implementation guidance? Answer: Takes some of the burden off of Compliance. -- Does the phrase “explore the possibility of a third party challenge mechanism” encompass and authorize the IRT’s adoption and implementation of such a mechanism if it is found to be possible? Answer: To amend the language to “explore and if possible implement”. -- Would the challenge mechanism be operative against ICANN, a registry alleged to have circumvented a RPM, or both? Answer: It would be against the registry that is alleged to have circumvented it. There already is a way to challenge staff and Board actions. -- This would not be a mechanism as a way for ICANN Org Compliance to enforce – this would be a separate mechanism? Answer: Correct. Discussion: -- Opposed to this language. Sunrise Rec #2 itself is still vague. -- Registries agree by contract to comply, but IRTs cannot develop consensus policies or revise contract terms – so this is out of scope. -- This is putting one vagueness on top of another. -- What authority does an IRT have to do these types of things. -- Didn't an IRT create the URS, PDDRP, PICDRP, to name a few? -- Sunrise Rec #2 seems to beg for a third-party challenge mechanism. -- 1. Clause could include a clause to include a challenge mechanism. 2. IRTs do this sort of thing all the time (e.g. the AGB and all of the challenge mechanisms with it). -- Idea is that there would be an independent panel that an aggrieved party could go to – so not relying on ICANN Compliance and could be an independent review. -- Why isn't a complaint to ICANN compliance sufficient here? I agree with David that it's especially problematic to move from "vague standard applied by single decisionmaker" to "vague standard applied by various possible decisionmakers" -- Would this be a time-sensitive mechanism? -- Because in response to the complaints over the years on sunrise circumvention, ICANN has consistently said they could do nothing about it. -- Circumvention itself is not defined, so cannot be enforced. -- ICANN compliance would need to have a role, in a similar way it does in a PICDRP for instance; an independent panel would actually perform the substantive review and ICANN compliance would implement a panel finding, for example. -- If Rec 2 is "start doing something about it" then why isn't ICANN compliance the appropriate place? -- URS and PDDRP are not Consensus Policy either. They were created during implementation of the 2007 GNSO PDP on New gTLDs. -- Divergence in the WG on this suggested text. ACTION ITEM: Discuss the suggested language on the list. 3. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4; see: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004505.html<http://secure-web.cisco.com/15s2A-_YSAltxsDRZbXGvAtbln5h7Y5BRK79nsX0sMyJLss1egyxr67iWrtpy3yoMtiGMGy58vZ6jCfjWSRTtmhEls37XpITRmZ0pk1dV0gy4xtVr2i4rCCHxU6Fk0vq3v1ahcw9f06x08EqL886eTn_kATT63sNDfH3osAcZcWZ_O0LFBKVGFZ0cLsqM6KyTHo3QJ6AE9hvRbmNY25yUiX0uy9lSYKzKUkf5zwGvAtfkX6J6srbPI7gFB4a-z4FruA7SVpXSsI1sKGhk4pjZ6g/http%3A%2F%2Fmm.icann.org%2Fpipermail%2Fgnso-rpm-wg%2F2020-September%2F004505.html> “The Working Group recommends guidance to the Implementation Review Team that the Approved Launch Program (ALP) Application Review Guidelines be reviewed and clarified in order to address feedback obtained by the working group regarding the length of time and complexity of process involved in seeking to obtain approval for an ALP, and in particular recommends that the IRT consider the following: 1. Where ICANN can not make a determination regarding an ALP application it will notify the Registry Operator to that effect within 45 days stating explicit reasons for needing more time and further, provide a decision date projection plan within a time period not to exceed another 30 days. There should be a reasonable expectation that all negotiations should be completed within a 7 month period. 2. Where ICANN determines to decline an ALP application or make a request for further information ICANN will include a full explanation of the aspects of the ALP application ICANN deems to be acceptable and the aspects ICANN deems to be unacceptable.” Discussion: -- The reference to an ALP being adopted is in the TMCH procedures if approved it is outside of or in contravention of Sunrise. This is directly related to the operation of the Sunrise. -- TMCH RPMs Requirements document that is incorporated by reference into the AGB and the RA (http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-...). 4.5 deals with Launch Programs, specifically 4.5.2: Registry Operator MAY, prior to the start date of its Sunrise Period, apply to ICANN for approval to conduct a registration program not otherwise permitted by these TMCH Requirements. Such a registration program application could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD, which, if set forth in reasonable detail in the application for the TLD, will carry a presumption of being approved, unless ICANN reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. If Registry Operator seeks ICANN’s approval of a program under this Section 4.5.2, and such requested registration program is substantially similar to a...” ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. 4. URS Final Recommendations; see: https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPW... [docs.google.com]<https://secure-web.cisco.com/14aelGQ2vVVG29EjXESQVYNQs8xt9zypPgviL8EBr2fngGW...> a. URS Final Recommendation (was #1): -- Recommendation language stays as is. -- Contextual language – inserted text to reflect the WG’s agreement to include the EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. b. New URS Final Recommendation: -- This is based on URS Question 1. -- It is a new recommendation based on responses received in the public comment. -- The context comes from the WG discussion of URS Question 1. -- The public comment review is based on the discussion of URS Question 1 and suggestion for a recommendation. Discussion: -- Questions about the contextual language. Concern that the reference to Purpose 6-PA5 is somehow binding. -- Staff noted that it is not binding and there was no change to the new recommendation resulting from the WG’s review of the ICANN org’s EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference.
I'm abandoning the email draft that I had because David expressed my concerns so well. I do want to highlight that we haven't discussed at all the additional bullet points proposed by the Small Group, which are not reproduced in this email chain but are highlighted in the linked document. I don't think the WG is ready to endorse that the specific examples suggested by some commenters ought to be sanctionable, and the current language implies that we agree that these are examples that ought to be enforced against if they were to recur going forward. Rebecca Tushnet Frank Stanton Professor of First Amendment Law, Harvard Law School 703 593 6759 ________________________________ From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> on behalf of McAuley, David via GNSO-RPM-WG <gnso-rpm-wg@icann.org> Sent: Friday, September 25, 2020 2:54 PM To: 'gnso-rpm-wg@icann.org' <gnso-rpm-wg@icann.org> Subject: Re: [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Thank you, Mary, Ariel, and Julie, Below are my comments regarding the draft Final Report language for Sunrise Recommendation 2, as well as the small team’s additional proposed draft language proposing an independent enforcement mechanism. I raised these issues on the Registries Stakeholder Group call two days ago and used that discussion to help inform my comments. But these comments are personal and not officially on behalf of my employer or of the RySG. First, with respect to the Final Report language on Sunrise Recommendation #2 and the original implementation guidance, I fully support the addition of the word ‘intentionally’ in the Recommendation prior to the word “circumventing”. A registry operator should not face potential enforcement action for unintended consequences. Further, I believe that the implementation guidance language needs to be tightened up to clarify that the “Discriminatory pricing practices” referenced at the second bullet listing non-exhaustive examples of practices that may circumvent an RPM means discriminating against a trademark holder in the sunrise period via extremely high premium pricing, followed by a much lower subsequent land rush or GA price that has resulted in bad faith registration and subsequent infringing use by registrants other than the mark holder. The sunrise registration RPM is meant to give a mark holder first opportunity to register a domain corresponding to its exact mark to prevent its bad faith registration and use by a cybersquatter, but that must be balanced against the fact that many trademarks consist of generic dictionary words that have inherent value and can be used by other potential registrants in a non-infringing manner, justifying a substantial premium price. Further, the premium price level in and of itself cannot be sole basis for a Compliance enforcement action as that would violate the “picket fence” that prohibits GNSO policy from prescribing or limiting the pricing of registry services. As this type of price discrimination leading to subsequent infringement will only become evident after the sunrise registration period has ended, the IRT will need to give consideration as to what appropriate enforcement against such registry operation practices should consist of. Second, I oppose the additional implementation guidance language from Small Team 2. While I applaud the team for its efforts, I cannot support a new enforcement mechanism wholly separate from ICANN Compliance. In my opinion, this is very far from the idea that went out to public comment – the idea of revising a registry agreement provision for future new gTLDs to elevate the general requirement on a registry to implement applicable policies to a specific requirement to refrain from circumventing new gTLD RPMs. The proposal would give to the IRT unchecked and inappropriate policy-making discretion to create a new enforcement mechanism absent any showing that the implementation of Sunrise Recommendation #2 will be insufficient to curb suspect practices. Further, the PDDRP is already available against a registry operator who encourages infringing second level registrations, and the recommendation we have agreed upon to allow unrelated rights holders to bring a combined PDDRP action against a registry operator will make it easier to demonstrate a pattern of intentional circumvention of the sunrise RPM resulting in harm to them. It seems to me that if this additional language is added to the existing language and perfected implementation guidance, then there will be a strong possibility that the entire Sunrise Recommendation #2 will end up lacking consensus support and not proceed to Council. Best regards, David David McAuley Sr International Policy & Business Development Manager Verisign Inc. 703-948-4154 From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Wednesday, September 23, 2020 11:58 AM To: gnso-rpm-wg@icann.org Subject: [EXTERNAL] [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear all, Per the WG Co-Chairs, please note the deadline for this action: Please send comments if any to this list not later than COB Friday, 25 September. Note also that the WG discussion of Sunrise Recommendation #2 and the original Implementation Guidance language will be on the agenda for the WG meeting on Tuesday, 29 September, to be followed by a separate discussion of the Sub Team 2 suggested Implementation Guidance language. As a reminder, here is a link to Sunrise Recommendation #2 and the original Implementation Guidance language: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-1Q4/edit?usp=sharing<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-2D1Q4_edit-3Fusp-3Dsharing&d=DwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=E-M4OQvQBo8UWqE1LwEiDR3PcWlfM0I-0jiI1c4ous0&m=1JmB9wKZY64CXRQSsjd4ewxkvEIll849CVNpkbMOYP8&s=qUuhCwTWoV0tymlspT8DPLj8bH50c-LzfgPhu2N7QOw&e=>. Also as a reminder, here is the proposed Implementation Guidance language for Sunrise Recommendation #2 from Small Team 2: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Tuesday, September 22, 2020 at 4:09 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] REMINDER - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below and post any comments to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Thursday, September 17, 2020 at 5:07 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below from the WG meeting on 17 September: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Please see the suggested revisions to Sunrise Recommendation #2 in the Google document at: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_...>. Please also review the following Suggested Language from Small Team: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Please post any comments or questions for discussion to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Thursday, September 17, 2020 at 2:49 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 17 September 2020 Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 17 September 2020 at 17:00 UTC. Staff will post these to the wiki space. Please note that these are high-level notes and are not meant as a substitute for the recording, chat room, or transcript. The recording, Zoom chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2020-09-17+Review+of+all+Rights+Protection+Mechanisms+%28RPMs%29+in+all+gTLDs+PDP+WG<https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1pj-2DqVlupt78WOggqQBVxVYjoZzhpAILr-5FKjzlnz0Q9dNOBFXaq031gYNHOThZiA6e4f06uthLyxmlMQlQyX7x95gLj9tD-5F66uMXKEik9YoAiBiXvZC1NtWzldGG-5FKJCEjz0LMqAAk1cc6wlMGN0DDzCrYDEoTEXgIXWIKE-5Fkt082hEcRI7jM79jKpx8n2wT14ADjZBeRagmXdKLtuKqXvnAm-2DGD48SuByL7FiCTiwv-5FxKRc8GXV4mztb5JEhEBm8FmjynZGadWfwt1XqQSdSgA_https-253A-252F-252Fcommunity.icann.org-252Fdisplay-252FRARPMRIAGPWG-252F2020-2D09-2D17-252BReview-252Bof-252Ball-252BRights-252BProtection-252BMechanisms-252B-252528RPMs-252529-252Bin-252Ball-252BgTLDs-252BPDP-252BWG&d=DwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=E-M4OQvQBo8UWqE1LwEiDR3PcWlfM0I-0jiI1c4ous0&m=1JmB9wKZY64CXRQSsjd4ewxkvEIll849CVNpkbMOYP8&s=RWEYRLrkRXK4e38WYkjZJij1pKfYWaXKTYab-aWfEH8&e=>. Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS Actions: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4: ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. URS Final Recommendation (was #1): ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. New URS Final Recommendation: ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Sunrise Recommendation #2 and Small Team 2 Suggested Language; see: Suggested Language from Small Team 2<https://urldefense.proofpoint.com/v2/url?u=http-3A__secure-2Dweb.cisco.com_1...> andhttps://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_...> -- Concerns raised by Maxim Alzoba about the two examples that they are too broad. -- Further to my point, as was noted earlier, this is a high-level policy recommendation; the IRT will be tasked with implementing this recommendation and our guidance should be sufficient to allow the IRT to craft an appropriately tailored RA amendment and (hopefully a challenge mechanism with appropriate safeguards built in so as to not inhibit legitimate registry activities -- I agree (I think) with Jason insofar as implementing this recommendation may necessitate a third party challenge mechanism akin to the PDDRP or pICDRP so aggrieved TM owners can challenge a registry activity and there can be a ruling as to whether the activity is legitimate or not. -- Concerns about misinterpretation if we are not clear. -- Perhaps we can just add a third bullet that says, “registry activities that have a bona fide legitimate basis or rationale are explicitly not intended to be inhibited by this provision”. -- As a staff suggestion for your consideration — perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice and pricing practice that are compliant with ICANN policies and procedures.”? -- Add to bullet point 1 (slightly revised)-- adding: "without countervailing rationale and/or reasonable activity by registries, including handling of dictionary terms.” -- Suggest addition to the Recommendation: “The Working Group recommends that the Registry Agreement for future new gTLDs include a provision stating that a Registry Operator shall not operate its TLD in such a way as to have the effect of [intentionally] circumventing the mandatory RPMs imposed by ICANN or restricting brand owners’ reasonable use of the Sunrise rights protection mechanism.” Text in brackets. -- Don’t think adding “intentionally” in the rec helps us because it doesn’t really address Maxim’s concern, because reserving a name intentionally as part of an ALP or something is still intentional. ACTION ITEM: Discuss suggested language from Small Team 1 on the list. Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” -- Why would the proposed additional implementation guidance language be a beneficial addition to the existing implementation guidance? Answer: Takes some of the burden off of Compliance. -- Does the phrase “explore the possibility of a third party challenge mechanism” encompass and authorize the IRT’s adoption and implementation of such a mechanism if it is found to be possible? Answer: To amend the language to “explore and if possible implement”. -- Would the challenge mechanism be operative against ICANN, a registry alleged to have circumvented a RPM, or both? Answer: It would be against the registry that is alleged to have circumvented it. There already is a way to challenge staff and Board actions. -- This would not be a mechanism as a way for ICANN Org Compliance to enforce – this would be a separate mechanism? Answer: Correct. Discussion: -- Opposed to this language. Sunrise Rec #2 itself is still vague. -- Registries agree by contract to comply, but IRTs cannot develop consensus policies or revise contract terms – so this is out of scope. -- This is putting one vagueness on top of another. -- What authority does an IRT have to do these types of things. -- Didn't an IRT create the URS, PDDRP, PICDRP, to name a few? -- Sunrise Rec #2 seems to beg for a third-party challenge mechanism. -- 1. Clause could include a clause to include a challenge mechanism. 2. IRTs do this sort of thing all the time (e.g. the AGB and all of the challenge mechanisms with it). -- Idea is that there would be an independent panel that an aggrieved party could go to – so not relying on ICANN Compliance and could be an independent review. -- Why isn't a complaint to ICANN compliance sufficient here? I agree with David that it's especially problematic to move from "vague standard applied by single decisionmaker" to "vague standard applied by various possible decisionmakers" -- Would this be a time-sensitive mechanism? -- Because in response to the complaints over the years on sunrise circumvention, ICANN has consistently said they could do nothing about it. -- Circumvention itself is not defined, so cannot be enforced. -- ICANN compliance would need to have a role, in a similar way it does in a PICDRP for instance; an independent panel would actually perform the substantive review and ICANN compliance would implement a panel finding, for example. -- If Rec 2 is "start doing something about it" then why isn't ICANN compliance the appropriate place? -- URS and PDDRP are not Consensus Policy either. They were created during implementation of the 2007 GNSO PDP on New gTLDs. -- Divergence in the WG on this suggested text. ACTION ITEM: Discuss the suggested language on the list. 3. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4; see: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004505.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__secure-2Dweb.cisco.com_15s2A-2D-5FYSAltxsDRZbXGvAtbln5h7Y5BRK79nsX0sMyJLss1egyxr67iWrtpy3yoMtiGMGy58vZ6jCfjWSRTtmhEls37XpITRmZ0pk1dV0gy4xtVr2i4rCCHxU6Fk0vq3v1ahcw9f06x08EqL886eTn-5FkATT63sNDfH3osAcZcWZ-5FO0LFBKVGFZ0cLsqM6KyTHo3QJ6AE9hvRbmNY25yUiX0uy9lSYKzKUkf5zwGvAtfkX6J6srbPI7gFB4a-2Dz4FruA7SVpXSsI1sKGhk4pjZ6g_http-253A-252F-252Fmm.icann.org-252Fpipermail-252Fgnso-2Drpm-2Dwg-252F2020-2DSeptember-252F004505.html&d=DwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=E-M4OQvQBo8UWqE1LwEiDR3PcWlfM0I-0jiI1c4ous0&m=1JmB9wKZY64CXRQSsjd4ewxkvEIll849CVNpkbMOYP8&s=6rWK0n8pKaapHQ_bLb7VwH_OagUhzVI0BENsAB2X96Y&e=> “The Working Group recommends guidance to the Implementation Review Team that the Approved Launch Program (ALP) Application Review Guidelines be reviewed and clarified in order to address feedback obtained by the working group regarding the length of time and complexity of process involved in seeking to obtain approval for an ALP, and in particular recommends that the IRT consider the following: 1. Where ICANN can not make a determination regarding an ALP application it will notify the Registry Operator to that effect within 45 days stating explicit reasons for needing more time and further, provide a decision date projection plan within a time period not to exceed another 30 days. There should be a reasonable expectation that all negotiations should be completed within a 7 month period. 2. Where ICANN determines to decline an ALP application or make a request for further information ICANN will include a full explanation of the aspects of the ALP application ICANN deems to be acceptable and the aspects ICANN deems to be unacceptable.” Discussion: -- The reference to an ALP being adopted is in the TMCH procedures if approved it is outside of or in contravention of Sunrise. This is directly related to the operation of the Sunrise. -- TMCH RPMs Requirements document that is incorporated by reference into the AGB and the RA (http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__newgtlds.icann.org_en_about_trademark-2Dclearinghouse_rpm-2Drequirements-2D14may14-2Den.pdf&d=DwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=E-M4OQvQBo8UWqE1LwEiDR3PcWlfM0I-0jiI1c4ous0&m=1JmB9wKZY64CXRQSsjd4ewxkvEIll849CVNpkbMOYP8&s=ZxAgKOMbZ2GtiUuRqRj2TTfSNCWoJPwE92i7OeWguU0&e=>). 4.5 deals with Launch Programs, specifically 4.5.2: Registry Operator MAY, prior to the start date of its Sunrise Period, apply to ICANN for approval to conduct a registration program not otherwise permitted by these TMCH Requirements. Such a registration program application could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD, which, if set forth in reasonable detail in the application for the TLD, will carry a presumption of being approved, unless ICANN reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. If Registry Operator seeks ICANN’s approval of a program under this Section 4.5.2, and such requested registration program is substantially similar to a...” ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. 4. URS Final Recommendations; see: https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPW... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_...> a. URS Final Recommendation (was #1): -- Recommendation language stays as is. -- Contextual language – inserted text to reflect the WG’s agreement to include the EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. b. New URS Final Recommendation: -- This is based on URS Question 1. -- It is a new recommendation based on responses received in the public comment. -- The context comes from the WG discussion of URS Question 1. -- The public comment review is based on the discussion of URS Question 1 and suggestion for a recommendation. Discussion: -- Questions about the contextual language. Concern that the reference to Purpose 6-PA5 is somehow binding. -- Staff noted that it is not binding and there was no change to the new recommendation resulting from the WG’s review of the ICANN org’s EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference.
One of my concerns, and I raise this as a member of the WG, I wonder about the proposal below: "The IRT should explore the possibility of a third party challenge mechanism as one of the possible means." Is it appropriate to leave to an IRT - an implementation team run by ICANN - the creation of a new 3rd party mechanism for challenges? To me, this is the essence of the task given to a GNSO policy process; it is something we have always done together through the multistakeholder process. It's how we did the UDRP, the URS and the TM-PDDRP. I continue to ponder. Have a good weekend, All! Kathy ----- Original Message ----- From: "McAuley David" To:"gnso-rpm-wg@icann.org" Cc: Sent:Fri, 25 Sep 2020 18:54:48 +0000 Subject:Re: [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Thank you, Mary, Ariel, and Julie, Below are my comments regarding the draft Final Report language for Sunrise Recommendation 2, as well as the small team’s additional proposed draft language proposing an independent enforcement mechanism. I raised these issues on the Registries Stakeholder Group call two days ago and used that discussion to help inform my comments. But these comments are personal and not officially on behalf of my employer or of the RySG. First, with respect to the Final Report language on Sunrise Recommendation #2 and the original implementation guidance, I fully support the addition of the word ‘intentionally’ in the Recommendation prior to the word “circumventing”. A registry operator should not face potential enforcement action for unintended consequences. Further, I believe that the implementation guidance language needs to be tightened up to clarify that the “Discriminatory pricing practices” referenced at the second bullet listing non-exhaustive examples of practices that may circumvent an RPM means discriminating against a trademark holder in the sunrise period via extremely high premium pricing, followed by a much lower subsequent land rush or GA price that has resulted in bad faith registration and subsequent infringing use by registrants other than the mark holder. The sunrise registration RPM is meant to give a mark holder first opportunity to register a domain corresponding to its exact mark to prevent its bad faith registration and use by a cybersquatter, but that must be balanced against the fact that many trademarks consist of generic dictionary words that have inherent value and can be used by other potential registrants in a non-infringing manner, justifying a substantial premium price. Further, the premium price level in and of itself cannot be sole basis for a Compliance enforcement action as that would violate the “picket fence” that prohibits GNSO policy from prescribing or limiting the pricing of registry services. As this type of price discrimination leading to subsequent infringement will only become evident after the sunrise registration period has ended, the IRT will need to give consideration as to what appropriate enforcement against such registry operation practices should consist of. Second, I oppose the additional implementation guidance language from Small Team 2. While I applaud the team for its efforts, I cannot support a new enforcement mechanism wholly separate from ICANN Compliance. In my opinion, this is very far from the idea that went out to public comment – the idea of revising a registry agreement provision for future new gTLDs to elevate the general requirement on a registry to implement applicable policies to a specific requirement to refrain from circumventing new gTLD RPMs. The proposal would give to the IRT unchecked and inappropriate policy-making discretion to create a new enforcement mechanism absent any showing that the implementation of Sunrise Recommendation #2 will be insufficient to curb suspect practices. Further, the PDDRP is already available against a registry operator who encourages infringing second level registrations, and the recommendation we have agreed upon to allow unrelated rights holders to bring a combined PDDRP action against a registry operator will make it easier to demonstrate a pattern of intentional circumvention of the sunrise RPM resulting in harm to them. It seems to me that if this additional language is added to the existing language and perfected implementation guidance, then there will be a strong possibility that the entire Sunrise Recommendation #2 will end up lacking consensus support and not proceed to Council. Best regards, David David McAuley Sr International Policy & Business Development Manager Verisign Inc. 703-948-4154 FROM: GNSO-RPM-WG ON BEHALF OF Julie Hedlund SENT: Wednesday, September 23, 2020 11:58 AM TO: gnso-rpm-wg@icann.org SUBJECT: [EXTERNAL] [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear all, Per the WG Co-Chairs, please note the deadline for this action: _PLEASE SEND COMMENTS IF ANY TO THIS LIST NOT LATER THAN COB FRIDAY, 25 SEPTEMBER._ Note also that the WG discussion of Sunrise Recommendation #2 and the original Implementation Guidance language will be on the agenda for the WG meeting on TUESDAY, 29 SEPTEMBER, to be followed by a separate discussion of the Sub Team 2 suggested Implementation Guidance language. As a reminder, here is a link to Sunrise Recommendation #2 and the original Implementation Guidance language: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [1]. Also as a reminder, here is the proposed Implementation Guidance language for Sunrise Recommendation #2 from Small Team 2: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Kind regards, Mary, Ariel, and Julie FROM: GNSO-RPM-WG on behalf of Julie Hedlund DATE: Tuesday, September 22, 2020 at 4:09 PM TO: "gnso-rpm-wg@icann.org [4]" SUBJECT: [GNSO-RPM-WG] REMINDER - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, _PLEASE SEE THE ACTION ITEM BELOW AND POST ANY COMMENTS TO THIS LIST ASAP._ Kind regards, Mary, Ariel, and Julie FROM: GNSO-RPM-WG on behalf of Julie Hedlund DATE: Thursday, September 17, 2020 at 5:07 PM TO: "gnso-rpm-wg@icann.org [8]" SUBJECT: [GNSO-RPM-WG] ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below from the WG meeting on 17 September: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: DISCUSS WG SUGGESTED REVISIONS TO THE RECOMMENDATION AND IMPLEMENTATION GUIDANCE ALONG WITH THE SUGGESTED LANGUAGE FROM SMALL TEAM 2. Please see the suggested revisions to Sunrise Recommendation #2 in the Google document at: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com] [10]. Please also review the following Suggested Language from Small Team: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” _PLEASE POST ANY COMMENTS OR QUESTIONS FOR DISCUSSION TO THIS LIST ASAP._ Kind regards, Mary, Ariel, and Julie FROM: GNSO-RPM-WG on behalf of Julie Hedlund DATE: Thursday, September 17, 2020 at 2:49 PM TO: "gnso-rpm-wg@icann.org [13]" SUBJECT: [GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 17 September 2020 Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 17 September 2020 at 17:00 UTC. Staff will post these to the wiki space. _PLEASE NOTE THAT THESE __ARE HIGH-LEVEL NOTES AND ARE NOT MEANT AS A SUBSTITUTE FOR THE RECORDING, CHAT ROOM, OR TRANSCRIPT__._ The recording, Zoom chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2020-09-17+Review+of+all+Ri... [15]. Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS ACTIONS: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: DISCUSS WG SUGGESTED REVISIONS TO THE RECOMMENDATION AND IMPLEMENTATION GUIDANCE ALONG WITH THE SUGGESTED LANGUAGE FROM SMALL TEAM 2. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4: ACTION ITEM: STAFF WILL CHECK WITH GDS TO SEE IF THIS RECOMMENDATION IS FEASIBLE. URS Final Recommendation (was #1): ACTION ITEM: MINOR CHANGE IN THE CONTEXTUAL LANGUAGE – CHANGE FROM “THE WORKING GROUP AFFIRMS” TO “THE WORKING GROUP FURTHER NOTES”. New URS Final Recommendation: ACTION ITEM: REMOVE THE QUOTED TEXT FROM PURPOSE 6-PA5 AND MOVE IT TO A FOOTNOTE FOR REFERENCE. NOTES: 1. Updates to Statements of Interest: No updates provided. 2. Sunrise Recommendation #2 and Small Team 2 Suggested Language; see: Suggested Language from Small Team 2 [16] andhttps://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com] [17] -- Concerns raised by Maxim Alzoba about the two examples that they are too broad. -- Further to my point, as was noted earlier, this is a high-level policy recommendation; the IRT will be tasked with implementing this recommendation and our guidance should be sufficient to allow the IRT to craft an appropriately tailored RA amendment and (hopefully a challenge mechanism with appropriate safeguards built in so as to not inhibit legitimate registry activities -- I agree (I think) with Jason insofar as implementing this recommendation may necessitate a third party challenge mechanism akin to the PDDRP or pICDRP so aggrieved TM owners can challenge a registry activity and there can be a ruling as to whether the activity is legitimate or not. -- Concerns about misinterpretation if we are not clear. -- Perhaps we can just add a third bullet that says, “registry activities that have a bona fide legitimate basis or rationale are explicitly not intended to be inhibited by this provision”. -- As a staff suggestion for your consideration — perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice and pricing practice that are compliant with ICANN policies and procedures.”? -- Add to bullet point 1 (slightly revised)-- adding: "without countervailing rationale and/or reasonable activity by registries, including handling of dictionary terms.” -- Suggest addition to the Recommendation: “The Working Group recommends that the Registry Agreement for future new gTLDs include a provision stating that a Registry Operator shall not operate its TLD in such a way as to have the effect of [intentionally] circumventing the mandatory RPMs imposed by ICANN or restricting brand owners’ reasonable use of the Sunrise rights protection mechanism.” Text in brackets. -- Don’t think adding “intentionally” in the rec helps us because it doesn’t really address Maxim’s concern, because reserving a name intentionally as part of an ALP or something is still intentional. ACTION ITEM: DISCUSS SUGGESTED LANGUAGE FROM SMALL TEAM 1 ON THE LIST. Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” _-- Why would the proposed additional implementation guidance language be a beneficial addition to the existing implementation guidance_? Answer: Takes some of the burden off of Compliance. _-- Does the phrase “explore the possibility of a third party challenge mechanism” encompass and authorize the IRT’s adoption and implementation of such a mechanism if it is found to be possible?_ Answer: To amend the language to “explore and if possible implement”. _-- Would the challenge mechanism be operative against ICANN, a registry alleged to have circumvented a RPM, or both_? Answer: It would be against the registry that is alleged to have circumvented it. There already is a way to challenge staff and Board actions. _-- This would not be a mechanism as a way for ICANN Org Compliance to enforce – this would be a separate mechanism?_ Answer: Correct. Discussion: -- Opposed to this language. Sunrise Rec #2 itself is still vague. -- Registries agree by contract to comply, but IRTs cannot develop consensus policies or revise contract terms – so this is out of scope. -- This is putting one vagueness on top of another. -- What authority does an IRT have to do these types of things. -- Didn't an IRT create the URS, PDDRP, PICDRP, to name a few? -- Sunrise Rec #2 seems to beg for a third-party challenge mechanism. -- 1. Clause could include a clause to include a challenge mechanism. 2. IRTs do this sort of thing all the time (e.g. the AGB and all of the challenge mechanisms with it). -- Idea is that there would be an independent panel that an aggrieved party could go to – so not relying on ICANN Compliance and could be an independent review. -- Why isn't a complaint to ICANN compliance sufficient here? I agree with David that it's especially problematic to move from "vague standard applied by single decisionmaker" to "vague standard applied by various possible decisionmakers" -- Would this be a time-sensitive mechanism? -- Because in response to the complaints over the years on sunrise circumvention, ICANN has consistently said they could do nothing about it. -- Circumvention itself is not defined, so cannot be enforced. -- ICANN compliance would need to have a role, in a similar way it does in a PICDRP for instance; an independent panel would actually perform the substantive review and ICANN compliance would implement a panel finding, for example. -- If Rec 2 is "start doing something about it" then why isn't ICANN compliance the appropriate place? -- URS and PDDRP are not Consensus Policy either. They were created during implementation of the 2007 GNSO PDP on New gTLDs. -- Divergence in the WG on this suggested text. ACTION ITEM: DISCUSS THE SUGGESTED LANGUAGE ON THE LIST. 3. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4; see: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004505.html [18] “The Working Group recommends guidance to the Implementation Review Team that the Approved Launch Program (ALP) Application Review Guidelines be reviewed and clarified in order to address feedback obtained by the working group regarding the length of time and complexity of process involved in seeking to obtain approval for an ALP, and in particular recommends that the IRT consider the following: 1. Where ICANN can not make a determination regarding an ALP application it will notify the Registry Operator to that effect within 45 days stating explicit reasons for needing more time and further, provide a decision date projection plan within a time period not to exceed another 30 days. There should be a reasonable expectation that all negotiations should be completed within a 7 month period. 2. Where ICANN determines to decline an ALP application or make a request for further information ICANN will include a full explanation of the aspects of the ALP application ICANN deems to be acceptable and the aspects ICANN deems to be unacceptable.” Discussion: -- The reference to an ALP being adopted is in the TMCH procedures if approved it is outside of or in contravention of Sunrise. This is directly related to the operation of the Sunrise. -- TMCH RPMs Requirements document that is incorporated by reference into the AGB and the RA (http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-... [19]) 4.5 deals with Launch Programs, specifically 4.5.2: Registry Operator MAY, prior to the start date of its Sunrise Period, apply to ICANN for approval to conduct a registration program not otherwise permitted by these TMCH Requirements. Such a registration program application could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD, which, if set forth in reasonable detail in the application for the TLD, will carry a presumption of being approved, unless ICANN reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. If Registry Operator seeks ICANN’s approval of a program under this Section 4.5.2, and such requested registration program is substantially similar to a...” ACTION ITEM: STAFF WILL CHECK WITH GDS TO SEE IF THIS RECOMMENDATION IS FEASIBLE. 4. URS Final Recommendations; see: https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPW... [docs.google.com] [20] a. URS Final Recommendation (was #1): -- Recommendation language stays as is. -- Contextual language – inserted text to reflect the WG’s agreement to include the EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: MINOR CHANGE IN THE CONTEXTUAL LANGUAGE – CHANGE FROM “THE WORKING GROUP AFFIRMS” TO “THE WORKING GROUP FURTHER NOTES”. b. New URS Final Recommendation: -- This is based on URS Question 1. -- It is a new recommendation based on responses received in the public comment. -- The context comes from the WG discussion of URS Question 1. -- The public comment review is based on the discussion of URS Question 1 and suggestion for a recommendation. Discussion: -- Questions about the contextual language. Concern that the reference to Purpose 6-PA5 is somehow binding. -- Staff noted that it is not binding and there was no change to the new recommendation resulting from the WG’s review of the ICANN org’s EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: REMOVE THE QUOTED TEXT FROM PURPOSE 6-PA5 AND MOVE IT TO A FOOTNOTE FOR REFERENCE. Links: ------ [1] https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [2] mailto:gnso-rpm-wg-bounces@icann.org [3] mailto:julie.hedlund@icann.org [4] mailto:gnso-rpm-wg@icann.org [5] mailto:gnso-rpm-wg@icann.org [6] mailto:gnso-rpm-wg-bounces@icann.org [7] mailto:julie.hedlund@icann.org [8] mailto:gnso-rpm-wg@icann.org [9] mailto:gnso-rpm-wg@icann.org [10] https://secure-web.cisco.com/1FjwAVP01Qp6iUM2rsInfcO1zc3qY1OeyxbslL44ahBnD57... [11] mailto:gnso-rpm-wg-bounces@icann.org [12] mailto:julie.hedlund@icann.org [13] mailto:gnso-rpm-wg@icann.org [14] mailto:gnso-rpm-wg@icann.org [15] https://secure-web.cisco.com/1pj-qVlupt78WOggqQBVxVYjoZzhpAILr_Kjzlnz0Q9dNOB... [16] http://secure-web.cisco.com/1ZQHItR6-GcLnN7flaJYMavZ68Kd0x80R9l3ty5lI1SXM8VS... [17] https://secure-web.cisco.com/1GPaEQhm9H9M25BLwa6LTCBf6l5NTIJUjWXk8Zkqr68yF-8... [18] http://secure-web.cisco.com/15s2A-_YSAltxsDRZbXGvAtbln5h7Y5BRK79nsX0sMyJLss1... [19] http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-... [20] https://secure-web.cisco.com/14aelGQ2vVVG29EjXESQVYNQs8xt9zypPgviL8EBr2fngGW...
Hi Kathy, We talked about this at some length on one of our calls. This is not how we did it for the URS and TM-PDDRP. Those were all done in implementation, not in policy. Here are the Policy outputs for the first round: https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm. No mention of URS or TM-PDDRP. Those were implemented as a result of the ideas of the IRT as refined by the STI. The were not PDP policy and, like those, there is nothing that would keep an IRT from exploring a third party challenge mechanism. The idea may be scrapped by the WG, but if it is it should be scrapped for accurate reasons. Best, Paul To receive regular COVID-19 updates from Taft, subscribe here<https://www.taftlaw.com/general/subscribe>. For additional resources, visit Taft's COVID-19 Resource Toolkit<https://www.taftlaw.com/general/coronavirus-covid-19-resource-toolkit>. This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments. From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org> On Behalf Of Kathy Kleiman Sent: Friday, September 25, 2020 5:17 PM To: McAuley David <dmcauley@Verisign.com>; gnso-rpm-wg@icann.org Subject: Re: [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: One of my concerns, and I raise this as a member of the WG, I wonder about the proposal below: "The IRT should explore the possibility of a third party challenge mechanism as one of the possible means." Is it appropriate to leave to an IRT - an implementation team run by ICANN - the creation of a new 3rd party mechanism for challenges? To me, this is the essence of the task given to a GNSO policy process; it is something we have always done together through the multistakeholder process. It's how we did the UDRP, the URS and the TM-PDDRP. I continue to ponder. Have a good weekend, All! Kathy ----- Original Message ----- From: "McAuley David" <dmcauley@Verisign.com<mailto:dmcauley@Verisign.com>> To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Cc: Sent: Fri, 25 Sep 2020 18:54:48 +0000 Subject: Re: [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Thank you, Mary, Ariel, and Julie, Below are my comments regarding the draft Final Report language for Sunrise Recommendation 2, as well as the small team’s additional proposed draft language proposing an independent enforcement mechanism. I raised these issues on the Registries Stakeholder Group call two days ago and used that discussion to help inform my comments. But these comments are personal and not officially on behalf of my employer or of the RySG. First, with respect to the Final Report language on Sunrise Recommendation #2 and the original implementation guidance, I fully support the addition of the word ‘intentionally’ in the Recommendation prior to the word “circumventing”. A registry operator should not face potential enforcement action for unintended consequences. Further, I believe that the implementation guidance language needs to be tightened up to clarify that the “Discriminatory pricing practices” referenced at the second bullet listing non-exhaustive examples of practices that may circumvent an RPM means discriminating against a trademark holder in the sunrise period via extremely high premium pricing, followed by a much lower subsequent land rush or GA price that has resulted in bad faith registration and subsequent infringing use by registrants other than the mark holder. The sunrise registration RPM is meant to give a mark holder first opportunity to register a domain corresponding to its exact mark to prevent its bad faith registration and use by a cybersquatter, but that must be balanced against the fact that many trademarks consist of generic dictionary words that have inherent value and can be used by other potential registrants in a non-infringing manner, justifying a substantial premium price. Further, the premium price level in and of itself cannot be sole basis for a Compliance enforcement action as that would violate the “picket fence” that prohibits GNSO policy from prescribing or limiting the pricing of registry services. As this type of price discrimination leading to subsequent infringement will only become evident after the sunrise registration period has ended, the IRT will need to give consideration as to what appropriate enforcement against such registry operation practices should consist of. Second, I oppose the additional implementation guidance language from Small Team 2. While I applaud the team for its efforts, I cannot support a new enforcement mechanism wholly separate from ICANN Compliance. In my opinion, this is very far from the idea that went out to public comment – the idea of revising a registry agreement provision for future new gTLDs to elevate the general requirement on a registry to implement applicable policies to a specific requirement to refrain from circumventing new gTLD RPMs. The proposal would give to the IRT unchecked and inappropriate policy-making discretion to create a new enforcement mechanism absent any showing that the implementation of Sunrise Recommendation #2 will be insufficient to curb suspect practices. Further, the PDDRP is already available against a registry operator who encourages infringing second level registrations, and the recommendation we have agreed upon to allow unrelated rights holders to bring a combined PDDRP action against a registry operator will make it easier to demonstrate a pattern of intentional circumvention of the sunrise RPM resulting in harm to them. It seems to me that if this additional language is added to the existing language and perfected implementation guidance, then there will be a strong possibility that the entire Sunrise Recommendation #2 will end up lacking consensus support and not proceed to Council. Best regards, David David McAuley Sr International Policy & Business Development Manager Verisign Inc. 703-948-4154 From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Wednesday, September 23, 2020 11:58 AM To: gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org> Subject: [EXTERNAL] [GNSO-RPM-WG] DEADLINE COB 25 Sept - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear all, Per the WG Co-Chairs, please note the deadline for this action: Please send comments if any to this list not later than COB Friday, 25 September. Note also that the WG discussion of Sunrise Recommendation #2 and the original Implementation Guidance language will be on the agenda for the WG meeting on Tuesday, 29 September, to be followed by a separate discussion of the Sub Team 2 suggested Implementation Guidance language. As a reminder, here is a link to Sunrise Recommendation #2 and the original Implementation Guidance language: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-.... Also as a reminder, here is the proposed Implementation Guidance language for Sunrise Recommendation #2 from Small Team 2: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Tuesday, September 22, 2020 at 4:09 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] REMINDER - ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below and post any comments to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Thursday, September 17, 2020 at 5:07 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] ACTION ITEM: Sunrise Recommendation #2 and Small Team 2 Suggested Language: Dear All, Please see the action item below from the WG meeting on 17 September: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Please see the suggested revisions to Sunrise Recommendation #2 in the Google document at: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://secure-web.cisco.com/1FjwAVP01Qp6iUM2rsInfcO1zc3qY1OeyxbslL44ahBnD57...>. Please also review the following Suggested Language from Small Team: Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” Please post any comments or questions for discussion to this list ASAP. Kind regards, Mary, Ariel, and Julie From: GNSO-RPM-WG <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>> Date: Thursday, September 17, 2020 at 2:49 PM To: "gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>" <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: [GNSO-RPM-WG] Notes and Action Items: RPM PDP WG Meeting 17 September 2020 Dear All, Please see below the action items captured by staff from the RPM PDP Working Group call held on 17 September 2020 at 17:00 UTC. Staff will post these to the wiki space. Please note that these are high-level notes and are not meant as a substitute for the recording, chat room, or transcript. The recording, Zoom chat, transcript and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2020-09-17+Review+of+all+Rights+Protection+Mechanisms+%28RPMs%29+in+all+gTLDs+PDP+WG<https://secure-web.cisco.com/1pj-qVlupt78WOggqQBVxVYjoZzhpAILr_Kjzlnz0Q9dNOBFXaq031gYNHOThZiA6e4f06uthLyxmlMQlQyX7x95gLj9tD_66uMXKEik9YoAiBiXvZC1NtWzldGG_KJCEjz0LMqAAk1cc6wlMGN0DDzCrYDEoTEXgIXWIKE_kt082hEcRI7jM79jKpx8n2wT14ADjZBeRagmXdKLtuKqXvnAm-GD48SuByL7FiCTiwv_xKRc8GXV4mztb5JEhEBm8FmjynZGadWfwt1XqQSdSgA/https%3A%2F%2Fcommunity.icann.org%2Fdisplay%2FRARPMRIAGPWG%2F2020-09-17%2BReview%2Bof%2Ball%2BRights%2BProtection%2BMechanisms%2B%2528RPMs%2529%2Bin%2Ball%2BgTLDs%2BPDP%2BWG>. Best Regards, Julie Julie Hedlund, Policy Director == NOTES & ACTION ITEMS Actions: Sunrise Recommendation #2 and Small Team 2 Suggested Language: ACTION ITEM: Discuss WG suggested revisions to the Recommendation and Implementation Guidance along with the suggested language from Small Team 2. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4: ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. URS Final Recommendation (was #1): ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. New URS Final Recommendation: ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Sunrise Recommendation #2 and Small Team 2 Suggested Language; see: Suggested Language from Small Team 2<http://secure-web.cisco.com/1ZQHItR6-GcLnN7flaJYMavZ68Kd0x80R9l3ty5lI1SXM8VS...> andhttps://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-... [docs.google.com]<https://secure-web.cisco.com/1GPaEQhm9H9M25BLwa6LTCBf6l5NTIJUjWXk8Zkqr68yF-8...> -- Concerns raised by Maxim Alzoba about the two examples that they are too broad. -- Further to my point, as was noted earlier, this is a high-level policy recommendation; the IRT will be tasked with implementing this recommendation and our guidance should be sufficient to allow the IRT to craft an appropriately tailored RA amendment and (hopefully a challenge mechanism with appropriate safeguards built in so as to not inhibit legitimate registry activities -- I agree (I think) with Jason insofar as implementing this recommendation may necessitate a third party challenge mechanism akin to the PDDRP or pICDRP so aggrieved TM owners can challenge a registry activity and there can be a ruling as to whether the activity is legitimate or not. -- Concerns about misinterpretation if we are not clear. -- Perhaps we can just add a third bullet that says, “registry activities that have a bona fide legitimate basis or rationale are explicitly not intended to be inhibited by this provision”. -- As a staff suggestion for your consideration — perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice and pricing practice that are compliant with ICANN policies and procedures.”? -- Add to bullet point 1 (slightly revised)-- adding: "without countervailing rationale and/or reasonable activity by registries, including handling of dictionary terms.” -- Suggest addition to the Recommendation: “The Working Group recommends that the Registry Agreement for future new gTLDs include a provision stating that a Registry Operator shall not operate its TLD in such a way as to have the effect of [intentionally] circumventing the mandatory RPMs imposed by ICANN or restricting brand owners’ reasonable use of the Sunrise rights protection mechanism.” Text in brackets. -- Don’t think adding “intentionally” in the rec helps us because it doesn’t really address Maxim’s concern, because reserving a name intentionally as part of an ALP or something is still intentional. ACTION ITEM: Discuss suggested language from Small Team 1 on the list. Suggestion Language from Small Team 2: “Implementation Guidance to Sunrise Recommendation 2: The IRT should explore the possibility of a third party challenge mechanism as one of the possible means, among others (for example, direct enforcement by ICANN Compliance) to implement this Recommendation to enforce the implementation of this recommended new RA provision. Any such third party challenge mechanism should include appropriate safeguards for registries.” -- Why would the proposed additional implementation guidance language be a beneficial addition to the existing implementation guidance? Answer: Takes some of the burden off of Compliance. -- Does the phrase “explore the possibility of a third party challenge mechanism” encompass and authorize the IRT’s adoption and implementation of such a mechanism if it is found to be possible? Answer: To amend the language to “explore and if possible implement”. -- Would the challenge mechanism be operative against ICANN, a registry alleged to have circumvented a RPM, or both? Answer: It would be against the registry that is alleged to have circumvented it. There already is a way to challenge staff and Board actions. -- This would not be a mechanism as a way for ICANN Org Compliance to enforce – this would be a separate mechanism? Answer: Correct. Discussion: -- Opposed to this language. Sunrise Rec #2 itself is still vague. -- Registries agree by contract to comply, but IRTs cannot develop consensus policies or revise contract terms – so this is out of scope. -- This is putting one vagueness on top of another. -- What authority does an IRT have to do these types of things. -- Didn't an IRT create the URS, PDDRP, PICDRP, to name a few? -- Sunrise Rec #2 seems to beg for a third-party challenge mechanism. -- 1. Clause could include a clause to include a challenge mechanism. 2. IRTs do this sort of thing all the time (e.g. the AGB and all of the challenge mechanisms with it). -- Idea is that there would be an independent panel that an aggrieved party could go to – so not relying on ICANN Compliance and could be an independent review. -- Why isn't a complaint to ICANN compliance sufficient here? I agree with David that it's especially problematic to move from "vague standard applied by single decisionmaker" to "vague standard applied by various possible decisionmakers" -- Would this be a time-sensitive mechanism? -- Because in response to the complaints over the years on sunrise circumvention, ICANN has consistently said they could do nothing about it. -- Circumvention itself is not defined, so cannot be enforced. -- ICANN compliance would need to have a role, in a similar way it does in a PICDRP for instance; an independent panel would actually perform the substantive review and ICANN compliance would implement a panel finding, for example. -- If Rec 2 is "start doing something about it" then why isn't ICANN compliance the appropriate place? -- URS and PDDRP are not Consensus Policy either. They were created during implementation of the 2007 GNSO PDP on New gTLDs. -- Divergence in the WG on this suggested text. ACTION ITEM: Discuss the suggested language on the list. 3. Suggested Language from Small Team 1 on ALP relating to Sunrise Questions #3 and #4; see: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004505.html<http://secure-web.cisco.com/15s2A-_YSAltxsDRZbXGvAtbln5h7Y5BRK79nsX0sMyJLss1egyxr67iWrtpy3yoMtiGMGy58vZ6jCfjWSRTtmhEls37XpITRmZ0pk1dV0gy4xtVr2i4rCCHxU6Fk0vq3v1ahcw9f06x08EqL886eTn_kATT63sNDfH3osAcZcWZ_O0LFBKVGFZ0cLsqM6KyTHo3QJ6AE9hvRbmNY25yUiX0uy9lSYKzKUkf5zwGvAtfkX6J6srbPI7gFB4a-z4FruA7SVpXSsI1sKGhk4pjZ6g/http%3A%2F%2Fmm.icann.org%2Fpipermail%2Fgnso-rpm-wg%2F2020-September%2F004505.html> “The Working Group recommends guidance to the Implementation Review Team that the Approved Launch Program (ALP) Application Review Guidelines be reviewed and clarified in order to address feedback obtained by the working group regarding the length of time and complexity of process involved in seeking to obtain approval for an ALP, and in particular recommends that the IRT consider the following: 1. Where ICANN can not make a determination regarding an ALP application it will notify the Registry Operator to that effect within 45 days stating explicit reasons for needing more time and further, provide a decision date projection plan within a time period not to exceed another 30 days. There should be a reasonable expectation that all negotiations should be completed within a 7 month period. 2. Where ICANN determines to decline an ALP application or make a request for further information ICANN will include a full explanation of the aspects of the ALP application ICANN deems to be acceptable and the aspects ICANN deems to be unacceptable.” Discussion: -- The reference to an ALP being adopted is in the TMCH procedures if approved it is outside of or in contravention of Sunrise. This is directly related to the operation of the Sunrise. -- TMCH RPMs Requirements document that is incorporated by reference into the AGB and the RA (http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-...). 4.5 deals with Launch Programs, specifically 4.5.2: Registry Operator MAY, prior to the start date of its Sunrise Period, apply to ICANN for approval to conduct a registration program not otherwise permitted by these TMCH Requirements. Such a registration program application could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD, which, if set forth in reasonable detail in the application for the TLD, will carry a presumption of being approved, unless ICANN reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. If Registry Operator seeks ICANN’s approval of a program under this Section 4.5.2, and such requested registration program is substantially similar to a...” ACTION ITEM: Staff will check with GDS to see if this recommendation is feasible. 4. URS Final Recommendations; see: https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPW... [docs.google.com]<https://secure-web.cisco.com/14aelGQ2vVVG29EjXESQVYNQs8xt9zypPgviL8EBr2fngGW...> a. URS Final Recommendation (was #1): -- Recommendation language stays as is. -- Contextual language – inserted text to reflect the WG’s agreement to include the EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Minor change in the contextual language – change from “the Working Group affirms” to “the Working Group further notes”. b. New URS Final Recommendation: -- This is based on URS Question 1. -- It is a new recommendation based on responses received in the public comment. -- The context comes from the WG discussion of URS Question 1. -- The public comment review is based on the discussion of URS Question 1 and suggestion for a recommendation. Discussion: -- Questions about the contextual language. Concern that the reference to Purpose 6-PA5 is somehow binding. -- Staff noted that it is not binding and there was no change to the new recommendation resulting from the WG’s review of the ICANN org’s EPDP Phase 1 Recommendation #27 Wave 1 Report. ACTION ITEM: Remove the quoted text from Purpose 6-PA5 and move it to a footnote for reference.
participants (5)
-
Julie Hedlund -
Kathy Kleiman -
McAuley, David -
McGrady, Paul D. -
Tushnet, Rebecca