| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | AE | AF | AG | AH | AI | AJ | AK | AL | AM | AN | AO | AP | AQ | AR | AS | AT | AU | AV | AW | AX | AY | AZ | BA | BB | BC | BD | BE | BF | BG | BH | BI | BJ | BK | BL | BM | BN | BO | BP | BQ | BR | BS | BT | BU | BV | BW | BX | BY | BZ | CA | CB | CC | CD | CE | CF | CG | CH | CI | CJ | CK | CL | CM | CN | CO | CP | CQ | CR | CS | CT | CU | CV | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Timestamp | Email Address | Please provide your name: | Please provide your affiliation | Are you providing input on behalf of another group (e.g., organization, company, government)? | If yes, please explain: | Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. | Please choose one of the following responses for URS Recommendation #1: | If you wish to (a) propose changes to URS Recommendation #1; and/or (b) provide a rationale for your response, please do so here. | URS Q1a. Should URS Rule 15(a) be amended to clarify that, where a Complaint has been updated with registration data provided to the Complainant by the URS Provider, there must be an option for the Determination to be published without the updated registration data? | URS Q1b. If so, when, by whom, and how should this option be triggered? | URS Q1c. Are there any operational considerations that will need to also be addressed in triggering this option? | Please choose one of the following responses for URS Recommendation #2: | If you wish to (a) propose changes to URS Recommendation #2; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for URS Recommendation #3: | If you wish to (a) propose changes to URS Recommendation #3; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for URS Recommendation #4: | If you wish to (a) propose changes to URS Recommendation #4; and/or (b) provide a rationale for your response, please do so here. | URS Q2a. What compliance issues have Registries and Registrars discovered in URS processes, if any? | URS Q2b. Do you have suggestions for how to enhance compliance of URS Providers, Registries, and Registrars in the URS process? | Please choose one of the following responses for URS Recommendation #5: | If you wish to (a) propose changes to URS Recommendation #5; and/or (b) provide a rationale for your response, please do so here. | URS Q3a. Question to Registry Operators -- Have Registry Operator experienced any issues with respect to receiving notices from URS Providers? | URS Q3b. Question to Registry Operators -- Were these notices sent through appropriate channels? | URS Q3c. Question to Registry Operators -- Did the notices contain the correct information? | Please choose one of the following responses for URS Recommendation #6: | If you wish to (a) propose changes to URS Recommendation #6; and/or (b) provide a rationale for your response, please do so here. | URS Q4a. What content and format should these educational materials have? | URS Q4b. How should these educational materials be developed? | URS Q4c. Who should bear the cost for developing these educational materials? | URS Q4d. Should translations be provided? | Please choose one of the following responses for URS Recommendation #7: | If you wish to (a) propose changes to URS Recommendation #7; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for URS Recommendation #8: | If you wish to (a) propose changes to URS Recommendation #8; and/or (b) provide a rationale for your response, please do so here. | URS Q5. Should the Registry Requirement 10 be amended to include the possibility for another Registrar, which is different from the sponsoring Registrar but accredited by the same Registry, to be elected by the URS Complainant to renew the URS Suspended domain name, and to collect the Registrar renewal fee? | Please choose one of the following responses for URS Recommendation #9: | If you wish to (a) propose changes to URS Recommendation #9; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for URS Recommendation #10: | If you wish to (a) propose changes to URS Recommendation #10; and/or (b) provide a rationale for your response, please do so here. | URS Q6. Who has the responsibility for developing the uniform set of basic FAQs for URS Complainants and Respondents? | URS Q7. What mechanism do you suggest that allows a URS Provider to efficiently check with other URS and UDRP Providers in order to ensure that a disputed domain name is not already subject to an open and active URS/UDRP proceeding? | URS Q8a. Question to Registry Operators -- What issues have you encountered with respect to implementing the HSTS-preloaded domain suspension remedy, if any? | URS Q8b. Question to Registry Operators -- What would need to be done to help resolve the issues you have encountered? | URS Q9. Are the non-refundable, late Response fees paid by Respondent reasonable? | URS Q10a. Are penalties for Complainant or Respondent who abuses the URS process sufficient? | URS Q10b. If not, should they be expanded? | URS Q10c. If they should be expanded, how? | Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. | Please choose one of the following responses for TMCH Recommendation #1: | If you wish to (a) propose changes to TMCH Recommendation #1; and/or (b) provide a rationale for your response, please do so here. | Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. | Please choose one of the following responses for Sunrise Recommendation #1: | If you wish to (a) propose changes to Sunrise Recommendation #1; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #2: | If you wish to (a) propose changes to Sunrise Recommendation #2; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #3: | If you wish to (a) propose changes to Sunrise Recommendation #3; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #4: | If you wish to (a) propose changes to Sunrise Recommendation #4; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #5: | If you wish to (a) propose changes to Sunrise Recommendation #5; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #6: | If you wish to (a) propose changes to Sunrise Recommendation #6; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #7: | If you wish to (a) propose changes to Sunrise Recommendation #7; and/or (b) provide a rationale for your response, please do so here. | Please choose one of the following responses for Sunrise Recommendation #8: | If you wish to (a) propose changes to Sunrise Recommendation #8; and/or (b) provide a rationale for your response, please do so here. | Sunrise Q1. What remedy(ies) would you propose for any unintended effects of the Sunrise Period that you have identified in your public comment? | Sunrise Q2a. Have you identified abuses of the Sunrise Period? | Sunrise Q2b. To the extent that you have identified abuses of the Sunrise Period, if any, please describe them and specify any documentation to substantiate the identified abuses. | Sunrise Q3a-1. Question to Registry Operators -- If you did not attempt an ALP, QLP, or LRP, was the reason for not taking advantage of those programs related to how they integrate with Sunrise? | Sunrise Q3a-2. Question to Registry Operators -- Were you able to achieve your goals in a different way (such as by combining any or all of these programs)? | Sunrise Q3b-1. Question to Registry Operators -- If you did attempt an ALP, QLP, or LRP (or combination) but didn’t successfully use any, was the reason you did not take advantage of those programs related to how they integrate with Sunrise? | Sunrise Q3b-2. Question to Registry Operators -- Were you able to achieve your goals in a different way? For instance, some Registry Operators may have used the QLP 100 (Section 3.2 of Registry Agreement Specification 5 ) (plus IDN variants) in combination with registry-reserved names to obtain the names they needed. Did you do this? | Sunrise Q3b-3. Question to Registry Operators -- If so, were you able to reserve or allocate all the names you needed to? | Sunrise Q3c-1. Question to Registry Operators -- If you used an ALP, QLP, or LRP (or combination), did you experience any unanticipated trouble with integrating the Sunrise Period into your launch? | Sunrise Q3c-2. Question to Registry Operators -- Specifically, were you able to allocate all of the names you needed to allocate under those programs before the Sunrise Period? | Sunrise Q3d-1. Question to Registry Operators -- For each issue you have identified in your responses to questions #3a-c, please also include a suggested mitigation path. What do you suggest the RPM Working Group consider to help alleviate the pain points and make those programs more useful and functional, while still respecting the trademark protection goals of the Sunrise Period? | Sunrise Q3d-2. Question to Registry Operators -- How important is it to make changes to these programs before another round of new gTLDs (that is, are these issues worth “holding up” another round for, or are the work-arounds tolerable)? | Sunrise Q3e. Question to Non-Registry Operators -- Did you experience struggles with the way ALP, QLP, or LRPs (or a combination) integrated with Sunrise, either as registrar, as a brand owner, or as a domain name registrant? | Sunrise Q4a-1. Question to Registry Operators -- If you had/have a business model that was in some way restrained by the 100-name pre Sunrise limit for names registries can reserve under Section 3.2 of Registry Agreement Specification 5, or the practical problems with the ALP, please share your experience and suggested path to improvement. | Sunrise Q4a-2. Question to Registry Operators -- What was your work-around, if any? For instance, if you withheld names from registration (“reserved” names), how well did that work? | Sunrise Q4b-1. Question to Registry Operators -- If the Working Group were to identify specialized gTLDs as a key concern that required changes to the way the Sunrise Period operates, are there other TLDs, besides GeoTLDs that did or will encounter the same problem? | Sunrise Q4b-2. Question to Registry Operators -- What suggestions do you have for work-arounds or solutions that will not diminish the protections available from the Sunrise Period (balanced with the need to finish this work in a timely manner)? | Sunrise Q4c-1. Question to Registry Operators -- Did you initially intend (prior to the implementation of Sunrise rules in the original Applicant Guidebook) to offer a special Sunrise before the regular Sunrise that targeted local trademark owners? | Sunrise Q4c-2. Question to Registry Operators -- For instance, would the ability to offer a special “pre-Sunrise” Sunrise solve any problems? | Sunrise Q4c-3. Question to Registry Operators -- If so, would you have validated the marks in some way? | Sunrise Q4c-4. Question to Registry Operators -- How would you have resolved conflicts between trademark holders that got their domains during the first Sunrise and trademark holders who had an identical trademark in the TMCH that was registered prior to Sunrise? | Sunrise Q5a. Question to trademark holders who use non-English scripts/languages -- Did you encounter any problems when you attempted to participate in Sunrise using non-English scripts/languages? | Sunrise Q5b. Question to trademark holders who use non-English scripts/languages -- If so, please describe problems you have encountered. | Sunrise Q5c. Question to trademark holders who use non-English scripts/languages -- Do you have suggestions on how to enable trademark holders who use non-English scripts/languages to effectively participate in Sunrise? | Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time. | Please choose one of the following responses for Trademark Claims Recommendation #1: | If you wish to (a) propose changes to Trademark Claims Recommendation #1; and/or (b) provide a rationale for your response, please do so here. | Trademark Claims Q1a-1. Have you identified any inadequacies or shortcomings of the Claims Notice? | Trademark Claims Q1a-2. If so, what are they? | Trademark Claims Q1b. Do you have suggestions on how to improve the Claims Notice in order to address the inadequacies or shortcomings? | Please choose one of the following responses for Trademark Claims Recommendation #2: | If you wish to (a) propose changes to Trademark Claims Recommendation #2; and/or (b) provide a rationale for your response, please do so here. | |
2 | 4/1/2020 3:54:18 | David SAUSSINAN | Legal Head of UNIFAB | Yes | UNIFAB | Yes | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 | 4/14/2020 17:57:50 | Will Furnish Once Done | Major Survey | No | Yes | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4 | 4/24/2020 10:50:16 | Renee Fossen | Forum (URS and UDRP Provider) | Yes | The answers provided are on behalf of Forum. | No, I would like to continue to the next section | Support Recommendation concept with minor change | While Forum has no objection to allowing the Complainant to amend the complaint, it has so far not seen the need for amendment based on the cases processed since the implementation of the Temporary Specification. No Complainants have expressed a desire to amend based on registration data. The Examiner has access to the registration data obtained from the Registry (or Registrar) and, if need be, is able to address the full data if appropriate. As a practical matter, it seems that allowing 2-3 days for amendment will only delay the issuance of a Determination which is counter to the quick determination the Complainant is hoping to achieve with a URS filing. Further, allowing an amendment will require Forum to modify its online filing platform, which will require costs disproportionate to the filing fees it receives from URS cases. | No | The option should be exercised at all, it should be by the Examiner, based on solely on issues surrounding the true identity of Respondent(s). | Yes. Providers will be required to take additional steps not currently taken to effectuate this change. This, and any other changes to the process, may necessitate an increase in filing fees. | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | While Forum has no objection to this recommendation generally, the compliance mechanism should be available to Providers, Registries and Registrars in addition to parties, as there may be issues between Providers, Registries and Registrars that do not involve the named parties to URS proceedings. | Creation of a compliance reporting system where a responsible party in compliance follows up within hours rather than days or weeks would be helpful. The URS is intended to move quickly, so unresolved compliance issues have the potential to significantly delay the proceedings. | Support Recommendation as written | Support Recommendation concept with minor change | While Forum does not oppose the recommendation, it cautions that guidance on the “clear and convincing” burden may have negative implications if the guidance provided uses a list of examples of what is and isn’t deemed clear and convincing as a substitution for Examiner discretion. However, even if the burden is defined in the abstract, as opposed to by example, that abstract definition could be incomplete or inaccurate with respect to its application to certain facts and circumstances. | FAQ | Forum agrees that the development of materials should be by an ICANN group made up of Providers, Examiners and Practitioners. The materials should be presented in a neutral and unbiased way, and not provide legal advice. The group should be relatively small to be the most efficient. | ICANN | Yes | Support Recommendation concept with minor change | Forum has directed its Examiners to document the rationale in all decisions. It is important, however, to allow the Examiners to use their discretion as to how much rationale is required in URS Determinations. Further, with the extremely low filing fees, Examiners receive very little compensation in exchange for a Determination. There must be a proper balance between cost-efficiency and the proper level of rationale to ensure Examiners will be willing to continue to act as Examiners. | Support Recommendation as written | No opinion | Support Recommendation as written | Support Recommendation concept with minor change | While Forum is not opposed to this recommendation, it recognizes that there may be issues with how such materials will fit within the current Providers’ websites and practices. For example, Forum’s URS process is completely online as a secure web application, so there are no hyperlinked “forms.” Instead, Forum provides presentations to assist the parties through the process. The final recommendation should include some flexibility for the Providers as to format. As for translations, it should be noted that a recent estimate to translate Forum’s current URS training materials is over $1,000 per language. This cost may be disproportionate to the current filing fees depending on how many languages will be included. | Proposed response: Forum believes the same team assembled in response to URS Question #4 should develop the materials. | Per URS Rule 3(b)(viii) and UDRP Rule 3(b)(xi), the Complainant is to, “Identify any other legal proceedings that have been commenced or terminated in connection with or relating to any of the domain name(s) that are the subject of the complaint.” These rules place the burden on identification of other URS and UDRP proceedings and other legal proceedings on the Complainant. As a practical matter, URS and UDRP Providers discover concurrent URS or UDRP proceedings upon verification from the Registry or Registrar because the domain name will already be locked prior to the commencement of the second case. The Registry or Registrar in those instances are able to inform the second Provider that there is already a matter pending. The pressing question is what should Providers do when there is a concurrent URS and UDRP case relating to the same domain name(s)? | Yes. | There has been only one finding of material falsehood to date, so it would appear that the penalties are sufficient. | Yes | No, I wish to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
5 | 4/25/2020 6:42:54 | Richard Hill | Hill & Associates | No | No, I would like to continue to the next section | Support Recommendation concept with minor change | I agree with the comment submitted by Renee Fossen on behalf of Forum | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | I agree with the comment submitted by Renee Fossen on behalf of Forum | Support Recommendation as written | Support Recommendation concept with minor change | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | Yes | Support Recommendation concept with minor change | I agree with the comment submitted by Renee Fossen on behalf of Forum | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | I agree with the comment submitted by Renee Fossen on behalf of Forum | Yes | No, I wish to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
6 | 4/27/2020 4:35:42 | Mette Andersen | registrant and registry | Yes | LEGO System A/S | No, I would like to continue to the next section | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | While we support the Recommendation, it should also provide for the elaboration of enforcement, including sanctions, for non-compliance. | As the compliance required by the URS and UDRP are similar, they should be enforced in a consistent manner | Support Recommendation as written | Support Recommendation as written | These materials should include a suggested list of the evidence that should be provided to support the conclusion that a domain name has been registered and used in bad faith and clear explanations of the three parts of the test. | By the community, URS providers and panelists and ICANN Org. | ICANN Org. and the URS providers. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation as written | Support Recommendation as written | The community and ICANN Org. | The responsibility to notify URS providers of concurrent proceedings between the parties falls to the parties themselves, although when attempting to lock a domain name upon receipt of a URS complaint, the Registrar should to advise the URS provider whether or not the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes; we support reasonable Respondent fees. | As there has been no evidence of abusive URS Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents which is unfair, presupposing that only one party could act in an abusive manner. | Yes | There should be mirrored procedures for abusive Respondents, so that the provisions relating to “deliberate material falsehoods” are extended to apply to Respondents, not just Complainants. | No, I wish to continue to the next section | Support Recommendation as written | We support the status quo for these three elements of the TMCH. However, we also support relaxed evidentiary standards to support TM + 50 entries (meaning that determinations should be sufficient without referring to specific trademark registration numbers) and “exact match” rules should be expanded to cover certain variants such as singular and plurals. We oppose any formalized limitation on the scope of RPMs based on the categories of goods or services arguably related to a particular gTLD. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | No opinion | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | No | No | No, I wish to continue to the next section | No opinion | Not sure | Support Recommendation as written | |||||||||||||||||||||||||||||||||||||||||||||||||||||
7 | 4/27/2020 6:08:24 | Masson | Hermes International | No | No, I would like to continue to the next section | Support Recommendation as written | No | We ask to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation as written | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation of complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. | Support Recommendation as written | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have up-to-date information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | The responsibility to notify URS providers of concurrent proceedings between the parties falls to the parties themselves. However, when attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload… | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | same as previous question | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would be help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | |||||||||||||||||||||||||||||||||||||||
8 | 4/27/2020 6:08:25 | Muller Anaïs | Hermès International | No | No, I would like to continue to the next section | Support Recommendation as written | No | We ask to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation as written | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation of complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. | Support Recommendation as written | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have up-to-date information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | The responsibility to notify URS providers of concurrent proceedings between the parties falls to the parties themselves. However, when attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload… | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | Same as previous question. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would be help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | |||||||||||||||||||||||||||||||||||||||
9 | 4/27/2020 6:08:34 | Alice Gensse | Hermes International | No | No, I would like to continue to the next section | Support Recommendation as written | No | We ask to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation as written | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation of complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. | Support Recommendation as written | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have up-to-date information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | The responsibility to notify URS providers of concurrent proceedings between the parties falls to the parties themselves. However, when attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload… | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | d. Other: In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | Same as previous question. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would be help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | |||||||||||||||||||||||||||||||||||||||
10 | 4/27/2020 14:31:26 | George Kirikos | Leap of Faith Financial Services Inc. | No | Do not support Recommendation | As a preliminary matter, the URS should be eliminated, for reasons which will be elaborated upon in other sections. [You can assume this statement into all of my future responses below, without being explicitly made again.]
However, if the URS is retained, one must remember that it was only intended to be applicable for “slam dunk” disputes, which should be so compelling, regardless of who the registrant is behind the domain name. If the outcome of the dispute would turn based on who the registrant is, then the dispute was inappropriate/weak from the start, and should have gone another route (UDRP or courts). One doesn’t need to know the identity of the registrant for FAMOUSBANK-login-here.TLD with a phishing page, as that’s a slam dunk case for the complainant. Where the dispute involves “POPULARSURNAME.TLD”, and an aggressive trademark holder’s case would fail if the respondent happens to share that surname, then that case perhaps shouldn’t have been brought in the first place, unless it was “obviously abusive” (e.g. via phishing content, etc.), rather than “possibly abusive, depending on who registered it” It also needs to be made clear that in the event a Complainant amends their complaint (i.e. if the above is ignored), the time limit for a response must also be adjusted accordingly (i.e. the time to respond needs to be measured from the date the amendment is delivered to the Respondent). | Yes | At the option of the registrant, if and only if they are a natural person covered by applicable privacy legislation. | Most likely yes, but not a major issue for me, so I’ll leave it to others to argue about. | Support Recommendation concept with minor change | This recommendation should be clarified to ensure that any time measurement for responding is based on the last method used for sending notices. For example, if a URS provider sends notices on April 25th via email (which might have been visible in the WHOIS), but sends out notices by mail/courier or FAX on April 28th, after obtaining that data from the registry (had it not been visible in the WHOIS), then the time to respond needs to be based on the April 28th date, and not the earlier April 25th one. | Significant change required | This recommendation should be an embarrassment to ICANN, given that it uncovered non-compliance by providers not sending the required notice. As such, there should be consequences to those providers, to ensure that it doesn’t happen again.
Furthermore, the actual recommendation is not robust, in that there is ambiguity about “predominant language”, and also suffers delays when the WHOIS is redacted due to GDPR (as one must wait for the underlying data to be disclosed, to determine where the respondent is located). Instead, the working group should adopt Individual URS Proposal #34 (from Zak Musovitch and myself), as it is a proven method (long used for the UDRP) based on the language of the registration agreement. That registration agreement language is known even if the WHOIS is redacted due to GDRP, because the identity of the REGISTRAR is known at all times (regardless of whether or not the WHOIS is redacted). As discussed in the body of URS Proposal #34 (evidence section) https://community.icann.org/display/RARPMRIAGPWG/URS+Proposals?preview=/93126760/96207628/URS-Proposal-34.pdf#URSProposals--986447092 the higher default rate for Chinese registrants can be explained due to the language barriers, and Individual URS Proposal #34 is superior to this “recommendation” in addressing that major problem. | Significant change required | I reiterate that it would be best for the URS to be entirely eliminated, as its benefits are outweighed by its costs. Adding additional layers of bureaucracy to handle compliance issues demonstrates that there are some members of the community who will always be arguing for additional costs to be incurred in trying to “fix” a broken procedure, rather than doing the proper thing, namely eliminating that procedure completely (in favour of the courts and/or the UDRP). In essence this would be a “dispute resolution procedure” for the “dispute resolution procedure”!! Indeed, given ICANN itself has not had a great track record in reigning in their contracted parties, I do not have much confidence that their compliance department would be up to the job. Regulators tend to have a history of being captured by those they purport to regulate.
The amount of time and money spent evaluating this procedure has been extraordinary (likely into the millions of dollars, if one evaluates the hourly value of the volunteer and staff time to date). A “URS commissioner” and/or “standing committee” isn’t free. This report has been devoid of any economic rationales for its recommendations, nor does it even attempt to weigh the costs against the benefits, including for this recommendation. Essentially, this recommendation is asking for ICANN to spend more money to hire someone to do something. That costs money. That might be attractive to some in the ICANN community who are looking to get hired, but the rest of us actually end up paying those costs, directly or indirectly. In conclusion, it’s time to recognize that the URS is beyond being fixed. It was an experiment that failed, and should be retired. All is not lost, though, as complainants have other options (courts and/or UDRP, to name a few). | N/A (not a registry or registrar) | Create contracts with explicit third party beneficiary clauses. Then, if there is a breach, allow those contracts to be enforced in court. But, read above, the URS should be eliminated in its entirety, and not persist. See also URS Individual Recommendation #33, which called for fixed-term contracts for URS providers, with explicit consequences for non-compliance. The current “accredit and forget it” model doesn’t work, and has led to URS providers who are too comfortable. They should always be aware that someone better can come along and replace them. | Support Recommendation as written | This again is an embarrassment, that one would even need to make a recommendation like this. This points to deeper organizational problems, that they can’t deliver services with basic functionality. ICANN likes to brag that they’re a “world class” organization, but they can’t even accomplish many of the basics.
To reiterate, though, the URS should be eliminated as policy. Trying to do too many things at once stretches one's limited resources, and leads to embarrassment like this, where one has to recommend that parties “keep contact details up to date”. No kidding! | Other (N/A - not a registry operator) | Other (N/A - not a registry operator) | Other (N/A - not a registry operator) | Do not support Recommendation | I reiterate that it would be best for the URS to be entirely eliminated, as its benefits are outweighed by its costs. Adding additional layers of bureaucracy to handle creation of “educational materials” and “documentation” demonstrates that there are some members of the community who will always be arguing for additional costs to be incurred in trying to “fix” a broken procedure, rather than doing the proper thing, namely eliminating that procedure completely (in favour of the courts and/or the UDRP).
The amount of time and money spent evaluating this procedure has been extraordinary (likely into the millions of dollars, if one evaluates the hourly value of the volunteer and staff time to date). Spending hundreds of thousands of dollars more to create educational materials, for a procedure that is used a couple of hundred times a year? That’s a waste of money, that could be better spent on other things. Economics involves trade-offs and making choices. There are unlimited wants, but limited resources to satisfy them. Resources would be better spent eliminating the URS completely, and diverting any additional investment into the UDRP. This report has been devoid of any economic rationales for its recommendations, nor does it even attempt to weigh the costs against the benefits, including for this recommendation. Essentially, this recommendation is asking for ICANN to spend more money to hire someone to do something. That costs money. That might be attractive to some in the ICANN community who are looking to get hired, but the rest of us actually end up paying those costs, directly or indirectly. In conclusion, it’s time to recognize that the URS is beyond being fixed. It was an experiment that failed, and should be retired. All is not lost, though, as complainants have other options (courts and/or UDRP, to name a few). If this proposal gets adopted, it must be costed out entirely (i.e. explicit cost attached) BEFORE it goes to the GNSO Council and/or Board, and the community must be made aware that those costs meant lower expenditures on some other project (which might have a bigger impact). | Precious resources (including my time) should be spent elsewhere, as discussed above, and the URS should be eliminated entirely. | If ICANN foolishly proceeds with this “make work” project, which will squander more resources, then there should be a competitive tender that specifically EXCLUDES anyone associated with this working group (past or present members/observers). There is a huge conflict of interest in arguing for ICANN to spend money to develop educational resources, and then have that same party line up to line their pockets with contracts or grants which result from that recommendation.
Given many problems with the URS occur due to lack of any response from registrants, at least two-thirds of any money spent should be devoted to educating registrants on defending complaints, rather than educating complainants (most of whom are already knowledgeable about making complaints). | Since URS providers and INTA (and its members) have been the ones who’ve most pushed for the URS’ adoption, the cost should be borne entirely by trademark holders and URS providers. A one-time levy of USD $50,000 per URS provider, as well as an ongoing fee of $10 per TMCH recordal per year would suffice, to ensure that the appropriate parties who’ve advocated for the URS end up paying for it. | Yes | Support Recommendation as written | This is “low hanging fruit”, since it should be a basic part of procedural fairness to have reasons. These are disputes with penalties (suspension of the domain name), and registrants are entitled to know exactly why they were found in violation of a policy, if their domain is suspended. Alternatively, complainants that fail should similarly understand why they didn’t meet the burden required. Errors in that analysis or reasoning can be used to appeal the decision, but can’t be detected if there are no reasons provided at all, or if those reasons are otherwise inadequate. Furthermore, frequent or severe errors should have consequences for URS providers and/or panelists, but can’t be detected if no reasons are provided.
To cite some law in Ontario, Canada, where I’m from, note: Megens v. Ontario Racing Commission, 2003 CanLII 26509 (ON SCDC): https://www.canlii.org/en/on/onscdc/doc/2003/2003canlii26509/2003canlii26509.html “One aspect of fairness is the duty to give reasons for the decision on the merits and as to penalty. There is a minimum standard that must be met, and the full extent of the duty to give reasons may vary depending on the circumstances including the operative statute, the importance of the decision to the party and how closely the tribunal process resembles the judicial process. The obligation to provide reasons is not satisfied by merely reciting the submissions and evidence and stating a conclusion.” | Do not support Recommendation | The supporting rationale came from a tiny sample (not statistically significant) of URS practitioners that were dominated by those representing complainants (only 1 out of 14 had represented respondents). See: https://community.icann.org/download/attachments/86606544/URS%20Practitioners%20Survey%20Summary%20Results%2012%20June%202018.pdf?version=1&modificationDate=1528859972000&api=v2
Thus, it’s a recommendation that came from a very unrepresentative sample. Looking at Registry Requirement 10, it seems fine as-is, without any changes. One should not allow any implementation team to modify that policy based on views from that unrepresentative group. | No | Significant change required | The current language policies are broken for the URS. Instead, the working group should adopt Individual URS Proposal #34 (from Zak Musovitch and myself), as it is a proven method (long used for the UDRP) based on the language of the registration agreement. That registration agreement language is known even if the WHOIS is redacted due to GDRP, because the identity of the REGISTRAR is known at all times (regardless of whether or not the WHOIS is redacted).
As discussed in the body of URS Proposal #34 (evidence section) https://community.icann.org/display/RARPMRIAGPWG/URS+Proposals?preview=/93126760/96207628/URS-Proposal-34.pdf#URSProposals--986447092 the higher default rate for Chinese registrants can be explained due to the language barriers, and Individual URS Proposal #34 is superior to this “recommendation” in addressing that major problem. | Do not support Recommendation | (same answer as URS Recommendation #6) I reiterate that it would be best for the URS to be entirely eliminated, as its benefits are outweighed by its costs. Adding additional layers of bureaucracy to handle creation of “educational materials” and “documentation” demonstrates that there are some members of the community who will always be arguing for additional costs to be incurred in trying to “fix” a broken procedure, rather than doing the proper thing, namely eliminating that procedure completely (in favour of the courts and/or the UDRP).
The amount of time and money spent evaluating this procedure has been extraordinary (likely into the millions of dollars, if one evaluates the hourly value of the volunteer and staff time to date). Spending hundreds of thousands of dollars more to create educational materials, for a procedure that is used a couple of hundred times a year? That’s a waste of money, that could be better spent on other things. Economics involves trade-offs and making choices. There are unlimited wants, but limited resources to satisfy them. Resources would be better spent eliminating the URS completely, and diverting any additional investment into the UDRP. This report has been devoid of any economic rationales for its recommendations, nor does it even attempt to weigh the costs against the benefits, including for this recommendation. Essentially, this recommendation is asking for ICANN to spend more money to hire someone to do something. That costs money. That might be attractive to some in the ICANN community who are looking to get hired, but the rest of us actually end up paying those costs, directly or indirectly. In conclusion, it’s time to recognize that the URS is beyond being fixed. It was an experiment that failed, and should be retired. All is not lost, though, as complainants have other options (courts and/or UDRP, to name a few). If this proposal gets adopted, it must be costed out entirely (i.e. explicit cost attached) BEFORE it goes to the GNSO Council and/or Board, and the community must be made aware that those costs meant lower expenditures on some other project (which might have a bigger impact). If ICANN foolishly proceeds with this “make work” project, which will squander more resources, then there should be a competitive tender that specifically EXCLUDES anyone associated with this working group (past or present members/observers). There is a huge conflict of interest in arguing for ICANN to spend money to develop educational resources, and then have that same party line up to line their pockets with contracts or grants which result from that recommendation. Given many problems with the URS occur due to lack of any response from registrants, at least two-thirds of any money spent should be devoted to educating registrants on defending complaints, rather than educating complainants (most of whom are already knowledgeable about making complaints). If money is to be spent, it should come from URS providers and INTA members, since URS providers and INTA (and its members) have been the ones who’ve most pushed for the URS’ adoption. Tthe cost should be borne entirely by trademark holders and URS providers. A one-time levy of USD $50,000 per URS provider, as well as an ongoing fee of $10 per TMCH recordal per year would suffice, to ensure that the appropriate parties who’ve advocated for the URS end up paying for it. | If ICANN foolishly proceeds with this “make work” project, which will squander more resources, then there should be a competitive tender that specifically EXCLUDES anyone associated with this working group (past or present members/observers). There is a huge conflict of interest in arguing for ICANN to spend money to develop educational resources, and then have that same party line up to line their pockets with contracts or grants which result from that recommendation.
Given many problems with the URS occur due to lack of any response from registrants, at least two-thirds of any money spent should be devoted to educating registrants on defending complaints, rather than educating complainants (most of whom are already knowledgeable about making complaints). | There is a basic technology called a “database”. Obviously a centralized database would solve the problem.
Alternatively, amending the list of available EPP codes, currently seen at: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en so that there’s a new status code like “clientHoldUDRP” or “serverHoldURS” would also work. Ultimately, this accomplishes the same thing as a centralized database, but via the distributed WHOIS database instead. | While I’m not a registry operator, I feel compelled to answer, given that it was I who first discovered the HSTS issue, and brought it to the attention of the working group in May and June of 2018, see:
https://mm.icann.org/pipermail/gnso-rpm-wg/2018-May/003106.html https://mm.icann.org/pipermail/gnso-rpm-wg/2018-May/003112.html https://mm.icann.org/pipermail/gnso-rpm-wg/2018-May/003119.html https://mm.icann.org/pipermail/gnso-rpm-wg/2018-June/003139.html and made the accompany URS Individual Proposal #4: https://community.icann.org/download/attachments/93126760/URS-Proposal-4.pdf?version=1&modificationDate=1537972993000&api=v2 which the working group did not publish in the initial report. Renee Fossen of NAF falsely described that proposal as “moot”, https://mm.icann.org/pipermail/gnso-rpm-wg/2020-January/004151.html as some “technical guidances” had changed as a result of my discovery and analysis (without properly crediting me for that research, by the way). Obviously “technical guidance” that can be changed “out of band” like that, without GNSO involvement, can be changed again to revert to its prior state, and thus cannot be compared to a binding policy like the one I proposed. Thus, my proposal was not “moot”. Indeed, the “context” provided by NAF (page 35 of the report) indicates that they are not technically competent. This isn’t meant as an insult, but just a statement of fact. Anyone after doing appropriate searches in Google, or consulting with technically-minded individuals, could discover resources on how to setup automated renewal of SSL certificates. The fact that NAF is renewing them manually is their own fault, and demonstrates their incompetence (again, not an insult, but a statement of fact, literally “not having or showing the necessary skills to do something successfully.”). It took me less than a minute to determine that they are using LetsEncrypt Wildcard SSL certificates (e.g. from the Novartis.app URS suspension page, via https://www.adrforum.com/DomainDecisions/1880633D.htm ). Then, using that magical tool called “Google”, I typed in “auto renew letsencrypt wildcard” and followed the links! That’s it. It should be an embarrassment to the Working Group that the registry operators’ time is being wasted on stuff that should never have appeared in this report. This is what happens when a working group is captured, as I documented at: https://freespeech.com/2020/04/16/icann-rpm-pdp-phase-1-comment-period-is-another-sham-part-2/ and has lack of broad representation from other groups (including ones with technical backgrounds, like myself, who was unfairly banished, as per https://freespeech.com/2019/04/05/update-my-participation-rights-have-now-been-eliminated-at-icann-working-groups/ ). Again, there are no “issues”, except those deriving from lack of competence. | See my answer above to prior question. 1. Hire competent people. 2. Learn to use Google. 3. Don’t ban people from the working group that actually are competent and know how to use Google! | Yes, as presently stated. But, they have a captive audience, so they need to be capped, to ensure that they are not high in comparison with fees for complainants. | The answer to this question should be kept in mind when considering unbalanced proposals like Individual URS Proposal #15, which seek entirely unbalanced penalties for registrants. In my view, the entire URS policy should be eliminated, as a failed experiment.
If the policy is retained, penalties should be assessed only by courts, not the URS system itself. Thus, penalties should be anticipated within the complaint and response process, but evaluated within the court system. An explicit “costs” clause should be added to the complaint and response, such as: “In the event of any litigation between the parties relating to this Agreement and their rights hereunder, the prevailing party shall be entitled to recover all reasonable litigation costs and reasonable attorneys’ fees and expenses from the non-prevailing party.” | Other: The answer to this question should be kept in mind when considering unbalanced proposals like Individual URS Proposal #15, which seek entirely unbalanced penalties for registrants. In my view, the entire URS policy should be eliminated, as a failed experiment.
If the policy is retained, penalties should be assessed only by courts, not the URS system itself. Thus, penalties should be anticipated within the complaint and response process, but evaluated within the court system. An explicit “costs” clause should be added to the complaint and response, such as: “In the event of any litigation between the parties relating to this Agreement and their rights hereunder, the prevailing party shall be entitled to recover all reasonable litigation costs and reasonable attorneys’ fees and expenses from the non-prevailing party.” | The answer to this question should be kept in mind when considering unbalanced proposals like Individual URS Proposal #15, which seek entirely unbalanced penalties for registrants. In my view, the entire URS policy should be eliminated, as a failed experiment.
If the policy is retained, penalties should be assessed only by courts, not the URS system itself. Thus, penalties should be anticipated within the complaint and response process, but evaluated within the court system. An explicit “costs” clause should be added to the complaint and response, such as: “In the event of any litigation between the parties relating to this Agreement and their rights hereunder, the prevailing party shall be entitled to recover all reasonable litigation costs and reasonable attorneys’ fees and expenses from the non-prevailing party.” | Significant change required | As a preliminary matter (which I’ll expand upon later in other parts of this questionnaire), the TMCH should be eliminated. Its minor benefits have not outweighed its costs, which have included a 93.7% cart abandonment rate, as per the Analysis Group report, as I cited in my Individual Proposal (which was wrongly rejected due to a captured working group within the subteams). See:
https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 for that Individual Proposal, which cites the various data sources. See: https://community.icann.org/pages/viewpage.action?pageId=102146375#SunriseClaims--324377862 for the numerous other Sunrise & TMCH proposals I submitted. [in the “Individual Proposal tab] It is noteworthy that this report did not publish meaningful quantitative data such as this abandonment data from the Analysis Group report. Nor did it report on the 99%+ reduction in sunrise utilization, compared to past sunrises (which was arguably one of the reasons for having the TMCH, to have economies of scale for the trademark validation for sunrises which were expected to be popular, but instead were a bust, just like the entire new gTLD program). The top 10 most popular strings in the TMCH were all common dictionary words like “ONE” or “HOTEL”, and there was enormous gaming (on a relative basis, given the sunrises were so unpopular), for terms like “HOTEL” or “HOTELS”, and other strings as noted in posts like: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html which linked to numerous supporting articles. The Trademark+50 should not be expanded upon further. The exact match should be retained, otherwise inferior “typo” trademarks could be used to capture superior non-typo domain names (e.g. “Flickr” could be used to capture “Flicker” during sunrises). Much greater limitations would be needed to reduce gaming in sunrises, beyond those considered, as I proposed via my Proposal #3, which would have seen the Uniregistry anti-gaming clauses adopted, see: https://community.icann.org/download/attachments/102146375/Proposal%233.pdf?version=1&modificationDate=1553614262000&api=v2 Restricting domain transfers to ensure that trademarks are transferred along with sunrise domains would massively hit the gamers, yet this simple proposal was blocked from consideration in the captured working group. No reasonable justification exists for not considering a serious proposal like this. It can only be explained by capture by insiders who wish to perpetuate the gaming that has been going on in sunrise periods. Similarly proposal #4 would have seriously addressed gaming: https://community.icann.org/download/attachments/102146375/Proposal%234.pdf?version=1&modificationDate=1553614273000&api=v2 but was again not considered for public comment. Of course, sunrise itself should also be eliminated, as was proposed (but was prevented from being considered for public comments due to the capture of the working group). Capture of the working group is documented at: https://freespeech.com/2020/04/16/icann-rpm-pdp-phase-1-comment-period-is-another-sham-part-2/ among other sources (I had also warned about it in my Section 3.7 appeal which I quote from on that blog post). | Significant change required | Sunrise should be eliminated entirely, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See:
https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 It is noteworthy that this report did not publish meaningful quantitative data such as the 99%+ reduction in sunrise utilization, compared to past sunrises. The top 10 most popular strings in the TMCH were all common dictionary words like “ONE” or “HOTEL”, and there was enormous gaming (on a relative basis, given the sunrises were so unpopular), for terms like “HOTEL” or “HOTELS”, and other strings as noted in posts like: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html which linked to numerous supporting articles. | Do not support Recommendation | Sunrise should be eliminated entirely, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See:
https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 Rather than expanding sunrises via expanded matches, they need to be shrunk or eliminated entirely. | Support Recommendation as written | There’s no need to create even more complexity surrounding these sunrises. Instead, the entire concept of a mandatory sunrise is broken, and should be eliminated, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See:
https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 Rather than expanding sunrises via expanded matches, they need to be shrunk or eliminated entirely. | Do not support Recommendation | There should be full transparency, just as there should be for the TMCH itself (and WHOIS). More importantly, there should be consistency and an underlying principle behind all of these various databases. It’s the height of hypocrisy to want certain databases to be public, but then argue vehemently that others should be private, when all of them have comparable data (lists of domain names, lists of trademarks, etc.). We’re not talking about highly sensitive personal health data, but just lists of strings.The benefits outweigh the exaggerated costs. | Do not support Recommendation | Sunrise should be eliminated entirely, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See:
https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 It is noteworthy that this report did not publish meaningful quantitative data such as the 99%+ reduction in sunrise utilization, compared to past sunrises. The top 10 most popular strings in the TMCH were all common dictionary words like “ONE” or “HOTEL”, and there was enormous gaming (on a relative basis, given the sunrises were so unpopular), for terms like “HOTEL” or “HOTELS”, and other strings as noted in posts like: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html which linked to numerous supporting articles. Ultimately, sunrises were pushed for by a small group of ICANN insiders who captured various groups, and that wanted to go to the “Front of the Line”, as if a trademark is so special that it trumps all other potential uses of a term. Trademark laws give curative rights, but don’t preemptively restrict speech. As we’ve seen from actual usage of sunrises, it’s been a bust, and it will be even less popular for future niche gTLDs in future rounds of the failed new gTLD program, as most of the more common terms that might have utility as a TLD have already been applied for in the past rounds. With fewer broken policies to maintain and have to review, there’d be less required in the future in terms of ongoing policy review, etc. (which uses up precious time of volunteers, staff, etc.). It’s better to focus on doing a few things very well, rather than have a hodgepodge of numerous procedures or systems that are performing poorly. | Do not support Recommendation | First of all, did anyone even bother to proofread these proposals? Rather than being independent and discrete, they repeatedly overlap with one another! Sunrise Recommendation #5 fully includes everything in Recommendations #6, but then also tosses in a separate point about their length! In other words, Rec #5 already argued for mandatory sunrise (i.e. “current requirement for the sunrise period be maintained”), which is then duplicated in Rec #6 that the mandatory sunrise be maintained (without mentioning anything about length). This should have been 2 separate recommendations that didn’t overlap (i.e. one focused only on length, and another on whether it should be mandatory), otherwise this sets up potentially conflicting advice, and potentially confusing public input.
That being said, sunrise should be eliminated entirely, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See: https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 It is noteworthy that this report did not publish meaningful quantitative data such as as the 99%+ reduction in sunrise utilization, compared to past sunrises (while the report did note the 64,000 sunrises across 484 TLDs on page 42 of this section, it didn’t post the prior data, or what the expectations were prior to the new gTLD RPMs being mandated). The top 10 most popular strings in the TMCH were all common dictionary words like “ONE” or “HOTEL”, and there was enormous gaming (on a relative basis, given the sunrises were so unpopular), for terms like “HOTEL” or “HOTELS”, and other strings as noted in posts like: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html which linked to numerous supporting articles. Ultimately, sunrises were pushed for by a small group of ICANN insiders who captured various groups, and that wanted to go to the “Front of the Line”, as if a trademark is so special that it trumps all other potential uses of a term. Trademark laws give curative rights, but don’t preemptively restrict speech. As we’ve seen from actual usage of sunrises, it’s been a bust, and it will be even less popular for future niche gTLDs in future rounds of the failed new gTLD program, as most of the more common terms that might have utility as a TLD have already been applied for in the past rounds. With fewer broken policies to maintain and have to review, there’d be less required in the future in terms of ongoing policy review, etc. (which uses up precious time of volunteers, staff, etc.). It’s better to focus on doing a few things very well, rather than have a hodgepodge of numerous procedures or systems that are performing poorly. | Significant change required | Small tweaks like those suggested by this recommendation won’t be effective, given one can’t even see the data in the TMCH to make a challenge. The entire system is broken, and it should be eliminated. The fact that the working group killed the various proposals before they could even be published in the initial report for comment demonstrates the extent of total capture of the working group by those who want to preserve and perpetuate a flawed system.
Sunrise should be eliminated entirely, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See: https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 It is noteworthy that this report did not publish meaningful quantitative data such as as the 99%+ reduction in sunrise utilization, compared to past sunrises (while the report did note the 64,000 sunrises across 484 TLDs on page 42 of this section, it didn’t post the prior data, or what the expectations were prior to the new gTLD RPMs being mandated). The top 10 most popular strings in the TMCH were all common dictionary words like “ONE” or “HOTEL”, and there was enormous gaming (on a relative basis, given the sunrises were so unpopular), for terms like “HOTEL” or “HOTELS”, and other strings as noted in posts like: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html which linked to numerous supporting articles. Ultimately, sunrises were pushed for by a small group of ICANN insiders who captured various groups, and that wanted to go to the “Front of the Line”, as if a trademark is so special that it trumps all other potential uses of a term. Trademark laws give curative rights, but don’t preemptively restrict speech. As we’ve seen from actual usage of sunrises, it’s been a bust, and it will be even less popular for future niche gTLDs in future rounds of the failed new gTLD program, as most of the more common terms that might have utility as a TLD have already been applied for in the past rounds. With fewer broken policies to maintain and have to review, there’d be less required in the future in terms of ongoing policy review, etc. (which uses up precious time of volunteers, staff, etc.). It’s better to focus on doing a few things very well, rather than have a hodgepodge of numerous procedures or systems that are performing poorly. | Significant change required | Did anyone actually proofread these recommendations? #8 here is phrased in a “negative” manner, i.e. “the working group does not recommend”, as opposed to an affirmative recommendation, to “do something” or “maintain something”. Very sloppy! It should have been rewritten to be consistent with the rest of the document (although, to the extent the rest of the document is sloppy, I suppose this fits right in).
Anyhow, sunrise should be eliminated entirely, as was proposed in individual proposal #1 in the subteam (but which was blocked for consideration/publication for public comments by a captured working group). See: https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 Mitch Stoltz made a similar proposal, proposal #8, see: https://community.icann.org/download/attachments/102146375/Proposal%238.pdf?version=1&modificationDate=1553789243000&api=v2 It is noteworthy that this report did not publish meaningful quantitative data such as as the 99%+ reduction in sunrise utilization, compared to past sunrises (while the report did note the 64,000 sunrises across 484 TLDs on page 42 of this section, it didn’t post the prior data, or what the expectations were prior to the new gTLD RPMs being mandated). The top 10 most popular strings in the TMCH were all common dictionary words like “ONE” or “HOTEL”, and there was enormous gaming (on a relative basis, given the sunrises were so unpopular), for terms like “HOTEL” or “HOTELS”, and other strings as noted in posts like: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html which linked to numerous supporting articles. Ultimately, sunrises were pushed for by a small group of ICANN insiders who captured various groups, and that wanted to go to the “Front of the Line”, as if a trademark is so special that it trumps all other potential uses of a term. Trademark laws give curative rights, but don’t preemptively restrict speech. As we’ve seen from actual usage of sunrises, it’s been a bust, and it will be even less popular for future niche gTLDs in future rounds of the failed new gTLD program, as most of the more common terms that might have utility as a TLD have already been applied for in the past rounds. With fewer broken policies to maintain and have to review, there’d be less required in the future in terms of ongoing policy review, etc. (which uses up precious time of volunteers, staff, etc.). It’s better to focus on doing a few things very well, rather than have a hodgepodge of numerous procedures or systems that are performing poorly. | If sunrise is to be retained (which I’ve argued already that it should not exist), then I reiterate the fixes I previously made (that got killed in the subteam in my absence after I was unjustly banished from the working group, as per https://freespeech.com/2019/04/05/update-my-participation-rights-have-now-been-eliminated-at-icann-working-groups/ and all these proposals should have been up for discussion in the initial report. See:
A] Individual Sunrise Proposal #2: Further detail in the PDF, but briefly: If the sunrise procedures are retained (a separate proposal calls for its elimination), then all details of any trademark relied upon to secure a sunrise registration shall be made public, in order to permit utilization of the SDRP. Details should include all information provided to the TMCH (e.g. country, registration number, TM registration date, TM owner, goods and services, etc.). Without limiting an implementation review team, such publication might be implemented by making it public at the source (the TMCH) or via the WHOIS (which had been done in the past). https://community.icann.org/download/attachments/102146375/Proposal%232.pdf?version=1&modificationDate=1553614254000&api=v2 B] Individual Sunrise Proposal #3: Further detail in the PDF, but briefly: If the sunrise procedure is retained (a separate proposal calls for its elimination), then the Uniregistry "Sunrise Registration Anti-Hijack Provisions" shall be made standard for all future TLDs, as per Section III of: https://www.uniregistry.link/wp-content/uploads/2015/07/Acceptable-Use-Policy-and-Terms-of-Service-2017.pdf "1. Registered Names obtained in accordance with the Sunrise registration process shall be solely registered to the qualified applicant thereof who is the owner of the trade or service mark registration on the basis of which the Sunrise registration was allocated. Such Registered Names shall be restricted from transfer to any other registrant, absent submission to the Registry of evidence of assignment, license or other authorized acquisition of rights in the underlying trade or service mark giving rise to Sunrise qualification, and shall remain subject to the provisions of the Sunrise Challenge Policy. 2. Registered Names obtained in accordance with the Sunrise registration shall not be maintained using a privacy or proxy registration service." https://community.icann.org/download/attachments/102146375/Proposal%233.pdf?version=1&modificationDate=1553614262000&api=v2 C] Individual Sunrise Proposal #4: Further detail in the PDF, but briefly: If the sunrise procedure is retained (a separate proposal calls for its elimination), then the Uniregistry "Substantive Ineligibility" clause be included as a minimum standard for SDRP disputes, as per clause 2.1.2. of: https://www.uniregistry.link/wp-content/uploads/2015/07/SEPRP.pdf "2.1.2. Substantive Ineligibility i. Token use or Non-use: The trademark registration on which the domain name registrant based its Sunrise registration is not the subject of actual and substantial use in commerce in the issuing jurisdiction on which the TMCH entry is based, or has been unused in such jurisdiction for a sufficient period to constitute abandonment thereof in such jurisdiction; or ii. Pretextual Sunrise Registration: The domain name is otherwise a non-exclusive and generically applicable term having a primary meaning in relation to goods or services other than those for which the trade or service mark was obtained; and the domain name is not used or under demonstrable preparation for use, or held to prevent infringing use, by the registrant in connection with the goods and/or services on which the subject trademark registration is based. The following circumstances in particular shall, without limitation, constitute evidence of Pretextual Sunrise Registration: (a) The registrant’s use, licensing or offer of licensing of use of the domain name for the primary purpose of exploiting such nontrademark primary meaning; or (b) Circumstances indicating a pattern by the Registrant or in concert with others, of Sunrise Registrations based on formal claims of trade or service mark rights in alleged marks which are otherwise non-exclusive and generically applicable terms having a primary meaning in relation to goods or services other than those for which the trade or service mark was obtained; and (c) As an aggravating factor in connection with any of the circumstances above, whether the term in question is particularly generically applicable in connection with the TLD in which the Sunrise Registration was made https://community.icann.org/download/attachments/102146375/Proposal%234.pdf?version=1&modificationDate=1553614273000&api=v2 | Yes | I had attempted to document abuses in the working group, but the co-chairs put up major obstacles, as did staff (who failed to compile various data sources) with unrealistic deadlines, and specific formatting requirements that did not apply to data sources that had been submitted by others. This was documented in paragraphs 9 and 10 of the PDF attached tot:
https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003633.html for the Section 3.7 appeal I made (which was not treated seriously, as I’ve pointed out elsewhere, including at https://freespeech.com/2020/04/16/icann-rpm-pdp-phase-1-comment-period-is-another-sham-part-2/ ). I now include the same articles (including the comments to the articles, which often contained compelling data/insights) documenting abuses of the sunrise, I attempted to bring to the attention of the group, but which were ignored! https://mm.icann.org/pipermail/gnso-rpm-wg/2019-February/003651.html Additional examples were documented at: https://docs.google.com/document/d/1PSjuohvTGkXbmK5eNGSEi_R0qw6GvI3Hv3MtpK83tuc/edit but were not brought to the attention of the public in this report, which falsely claims that there’s “lack of concrete evidence”. It was buried in the subteam work which was captured, as was the entire working group. | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (never attempted to use them, as we have no interest in new gTLDs) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | N/A (not a registry operator) | Other: N/A (not a registry operator) | Other: N/A (not a registry operator) | Other: N/A (not a registry operator) | N/A (not a registry operator) | Other: N/A, own no non-English trademarks | N/A | N/A, own no non-English trademarks. | Significant change required | The “context” provided is extremely misleading and incomplete, falsely claiming that the Working Group “could not determine the extent of deterrence that occurred, if any”. It was documented in the Analysis Group report that there was a 93.7% abandonment rate, as was cited in my Individual Proposal #1 at:
https://community.icann.org/pages/viewpage.action?pageId=102146375#SunriseClaims--324377862 [list of all individual Sunrise & Trademark Claims Proposals] https://community.icann.org/download/attachments/102146375/Proposal%231.pdf?version=2&modificationDate=1553614357000&api=v2 [Proposal #1] https://newgtlds.icann.org/en/reviews/tmch/revised-services-review-22feb17-en.pdf [Analysis Group report, pp.16-18] This 93.7% abandonment rate was already adjusted, to eliminate 2 registrars with very high abandonment rates which might have been “mining” the service for data, as was noted in footnote 55 on page 17 of the Analysis Group report, which states: “As discussed in Section IV, there are two registrars that averaged downloads of more than 20 trademark strings per download, which is large compared to the average of fewer than five trademark strings in the downloads of other registrars. We also exclude downloads made by ICANN’s monitoring system. The exclusion of the two registrars does not significantly impact our results. Inclusion of the two registrars shows that 99% of registrations are abandoned and 0.5% of completed registrations are disputed.” The erroneous statement in the report that the Working Group allegedly “could not determine the extent of deterrence that occurred, if any” simply demonstrates the high degree of capture by trademark maximalists in the working group, who refused to acknowledge any deleterious effects caused by their pet projects in the real world. As Table 1 (on page 9 of the Analysis Group report) demonstrates, the most common terms that registrants were attempting to register were terms like: SMART, FOREX, HOTEL, ONE, LOVE, CLOUD, NYC, LONDON, ABC, LUXURY Had these been famous and distinctive fanciful marks such as “Google” or “Verizon” or “Exxon”, a sound statistical case might have been made by the brand protection lobbyists who’ve captured this working group for the retention of the TMCH and the Trademark Claims notices. But, anyone who is open-minded, fair-minded, and seeks to engage in evidence-based policymaking can plainly see that these are commonly used dictionary terms and acronyms that have multiple legitimate uses, which no firm can claim exclusivity, and the Trademark Claims notices are having a chilling effect on legitimate registration attempts for these terms. As such, the Trademark Claims notices shouldn’t be merely “tweaked”, as this Recommendation #1 suggests. Instead, the Trademark Claims should be entirely eliminated, as I proposed in my Individual Proposal #1 which had been killed (in my absence, as I was already unfairly banished, as per https://freespeech.com/2019/04/05/update-my-participation-rights-have-now-been-eliminated-at-icann-working-groups/ ) by a captured working group that is dominated by trademark maximalists. As I also noted in my Sunrise proposal #2 at: https://community.icann.org/download/attachments/102146375/Proposal%232.pdf?version=1&modificationDate=1553614254000&api=v2 (which also impacts trademark claims) the Trademark Claims notices omit essential details to even allow registrants the ability to easily identify which trademark is being asserted against their registration. While that obviously would need to be fixed if the Trademark Claims notices are to be retained, the preferred course of action is to follow where the evidence has led us, namely that the policy has failed as it is causing massive abandonment of legitimate registrations. | Yes | As I noted in my Sunrise proposal #2 at:
https://community.icann.org/download/attachments/102146375/Proposal%232.pdf?version=1&modificationDate=1553614254000&api=v2 (which also impacts trademark claims) the Trademark Claims notices omit essential details to even allow registrants the ability to easily identify which trademark is being asserted against their registration. While that obviously would need to be fixed if the Trademark Claims notices are to be retained, the preferred course of action is to follow where the evidence has led us, namely that the policy has failed as it is causing massive abandonment of legitimate registrations. [see my full answer re: Trademark Claims Recommendation #1 which talked about the 93.7% abandonment rate, the top 10 most frequently reported strings, and so on, which support elimination of the Trademark Claims notices] | Yes, one can eliminate them entirely. As I noted in my Sunrise proposal #2 at:
https://community.icann.org/download/attachments/102146375/Proposal%232.pdf?version=1&modificationDate=1553614254000&api=v2 (which also impacts trademark claims) the Trademark Claims notices omit essential details to even allow registrants the ability to easily identify which trademark is being asserted against their registration. While those could be added in a so-called “improved” claims notice, the preferred course of action is to follow where the evidence has led us, namely that the policy has failed as it is causing massive abandonment of legitimate registrations. [see my full answer re: Trademark Claims Recommendation #1 which talked about the 93.7% abandonment rate, the top 10 most frequently reported strings, and so on, which support elimination of the Trademark Claims notices] | Do not support Recommendation | The preferred course of action is to follow where the evidence has led us, namely that the policy has failed as it is causing massive abandonment of legitimate registrations. [see my full answer re: Trademark Claims Recommendation #1 which talked about the 93.7% abandonment rate, the top 10 most frequently reported strings, and so on, which support elimination of the Trademark Claims notices]
I will also note that the Working Group recommendation trying to “improve” the Claims notices recognizes that the language of the registration agreement is critical. Yet, when it came to recommendations related to the URS, the language of the registration agreement was IGNORED! (i.e. URS Recommendation #3 wrote about the “predominant language of the Respondent”). As I noted in my response to URS Recommendation #3, working group should adopt Individual URS Proposal #34 (from Zak Muscovitch and myself), as it is a proven method (long used for the UDRP) based on the language of the registration agreement. That registration agreement language is known even if the WHOIS is redacted due to GDRP, because the identity of the REGISTRAR is known at all times (regardless of whether or not the WHOIS is redacted). As discussed in the body of URS Proposal #34 (evidence section) https://community.icann.org/display/RARPMRIAGPWG/URS+Proposals?preview=/93126760/96207628/URS-Proposal-34.pdf#URSProposals--986447092 the higher default rate for Chinese registrants can be explained due to the language barriers, and Individual URS Proposal #34 is superior to this “recommendation” in addressing that major problem. Thus, in order to ensure consistency in the approach towards language considerations, it becomes clear that the language of the claims notices should be identical to the language of the URS. This reinforces the need to adopt Individual URS Proposal #34, not only on its merits, but for the same reasons that language is used for the Trademark Claims notices! This inconsistency should have been caught earlier by those who remain in the working group (I’ve been banished unfairly, as noted at https://freespeech.com/2019/04/05/update-my-participation-rights-have-now-been-eliminated-at-icann-working-groups/ ), but it demonstrates that recommendations are being made in a haphazard fashion by a captured group that is simply “going through the motions”, stumbling forward without reference to any strong underlying principles. | |||||||
11 | 4/28/2020 14:52:26 | Lori Schulman | INTA | Yes | No, I would like to continue to the next section | Support Recommendation concept with minor change | INTA supports this Recommendation but proposes two amendments. First, the amount of time in which the Complainant is allowed to amend the Complaint should be changed from “within 2-3 calendar days” to “within 3 Business Days.” (Business Day is a defined term in the URS Rules meaning “a working day as defined by the Provider in its Supplemental Rules.”) This change will provide the Complainant with sufficient time to respond, particularly if the URS Provider provides updated registration data on a Friday or before a holiday, while still requiring the amendment promptly. Second, the Recommendation should be amended to make clear that the Complainant is allowed to amend the Complaint after receiving updated registration data but is not required to do so. | Yes | The Respondent should be allowed to request that the Determination be published without the updated registration data. This request must be made in the Response filed by the Respondent and the request should be granted only if the Respondent has established good cause for the updated registration data not to be published. Where a Complainant prevails, this should automatically require publication of the decision with the Respondent’s full name (but no other non-public contact details) for reasons of transparency and accountability, as this information must be usable to inform any future cases against the same Respondent. | If the Respondent is permitted to request that the Determination be published without the updated registration data, the URS Rules and URS Procedure will have to be updated to, among other things, provide the Respondent and the Examiner with the factors or criteria that, if established, could constitute good cause for the updated registration data not to be published. Again, where a Complainant prevails, this should automatically require publication of the decision with the Respondent’s full name (but no other non-public contact details) for reasons of transparency and accountability, as this information must be usable to inform any future cases against the same Respondent. | Support Recommendation as written | N/A | Support Recommendation concept with minor change | INTA supports this Recommendation, since it appears to only be recommending compliance with existing rules in URS Procedure paragraphs 4.2 and 4.3, but propose it be amended. It may be the case that some URS Providers are not complying with URS Procedure paragraph 4.3 because they do not understand that transmission of the Notice of Complaint must be accomplished by all three means (email, mail, and, where available, fax). INTA thus proposes that the Recommendation be changed from “via email, fax, and postal mail” to “by means of both email and postal mail, as well as by fax where available.” | Support Recommendation as written | N/A | Public posting of findings (and/or reports) of non-compliance, such as in a database/webpage maintained by the ICANN Complaints Office, would incentivize URS Providers, Registries, and Registrars to comply with URS Rules and URS Procedures. | Support Recommendation concept with minor change | INTA supports this Recommendation but proposes it be amended to state the following: “The Working Group recommends that the ICANN org, Registries, Registrars, and URS Providers take appropriate steps to ensure that each other’s contact details are up to date in order to effectively fulfill the notice requirements set forth in the URS Procedure para 4.” This change makes clear that the various interested parties should be taking affirmative steps to resolve the issues identified in the feedback from URS Providers. | Support Recommendation as writte | N/A | INTA agrees with the Working Group that the educational materials must be developed in the form of an administrative checklist, basic template, and/or FAQ.
The main attention must be provided to model documents such as Complaint, Notice of Complaint, Response and so on. In the event that Recommendation #6 is retained, INTA suggests adhering the content and format to a similar approach employed by WIPO in its Jurisprudential Overview 3.0. At the same time, it would be useful to make a relevant video for ICANN Learn. | These materials could be developed by the IRT, with input from URS Providers. | ICANN should bear the cost as part of implementation for this PDP. | Other: Yes, into official languages of UN | Support Recommendation as written | N/A | Support Recommendation as written | N/A | Yes | Do not support Recommendation | If the domains subject to a URS Complaint may have been registered via a privacy or proxy service, English language must be used by default. That said, the URS already provides rules regarding language of proceedings, so this recommendation seems unnecessary, particularly once proxy service is removed, which it typically is in the course of a URS proceeding. | Support Recommendation as written | N/A | The three URS Providers jointly have responsibility. | Each URS Provider should establish a dedicated non-public email address that other Providers can use to confirm whether a new URS case has been filed involving a domain name already subject to an existing case with the other Providers. This administrative check should be part of the URS process, if not already being done by Providers. | N/A | N/A | INTA believes these fees are reasonable, as the fees apply only to a Respondent seeking to file a past-due Response, placing an additional administrative burden on the Provider/Panel which the late Response fees are designed to offset. | Penalties for abusive complainants are adequate. There are currently no penalties for “abusive respondents” and it is not clear what conduct would constitute abuse on the part of a respondent in the context of how they participate in a URS proceeding. That said, INTA would support in principle certain penalties for abusive respondents, applicable for conduct such as the filing of vexatious supplemental materials, making false statements, or seeking to unreasonably delay or frustrate a URS proceeding. Such penalties should be commensurate with penalties for abusive complainants but without jeopardizing adequate due process under the URS generally. | Other: see comments above | See comments above. | No, I wish to continue to the next section | Significant change required | INTA prefers expanding the matching rules for purposes of Trademark Claims only (not Sunrise) to any variation in which the mark is contained. INTA believes this important in terms of deterring bad faith registrations that rely on variants and not exact matches of a TMCH-recorded mark and to enhance the ability of TMCH-recorded mark owners to more robustly monitor new registrations for possible infringement and bad faith registration/use. False positives generated through this approach could be overcome through additional language in Claims Notices to registrants explaining the possibility of false positives and to evaluate their registration with this in mind, and brand owners receiving such false positive notices would be able to easily disregard them. INTA encourages the Working Group to reconsider this section of the recommendation with this in mind, and would urge the Working Group to instead adopt a recommendation supporting expanded matching for TM Claims for all “mark contained” variations. | Support Recommendation as written | Support Recommendation as written | INTA strongly supports this recommendation. There were a number of significant instances of such abuse cited in the discussions of the Working Group. Appropriate controls must be put in place to ensure that the Sunrise mechanism remains meaningful and fair. | Do not support Recommendation | INTA supports a uniform challenge mechanism to challenge a registry operator’s designation of a name matching a TMCH-recorded mark as a premium or reserved name, and thereby unreasonably inhibiting the relevant brand owner from securing the name either during Sunrise or general availability. In our experience, registry operators will consider changing such designations on an ad hoc basis in response to direct, individual outreach from the brand owner, but there is no uniformity, transparency, or accountability around these informal communication channels, which would be improved through a single uniform mechanism applicable to all registries. | Support Recommendation as written | Support Recommendation concept with minor change | Although INTA supports the recommendation as written, INTA also recommends a change to make the End-Date Sunrise 60 day minimum the only option and eliminate the 30-day Start-Date Sunrise entirely. This would provide more uniformity and predictability, and the vast majority of Sunrise periods have been operated in this manner anyway. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Adopting Recommendation #2 (that registries not employ practices that would circumvent Sunrise) should help to mitigate the problems caused by how certain registries operated Sunrise or other registry practices aimed at preventing brand owners from reasonably using Sunrise. However, this recommendation must be implemented and enforceable for it to have any impact. This would likely require an amendment to the base gTLD Registry Agreement, and the creation of specific challenge mechanisms and ICANN Compliance powers to address behavior that runs afoul of this requirement. The TM-PDDRP or PICDRP could be used to address such behavior, if appropriately amended to specifically cover this type of activity. Other than these registry practices, INTA has not seen substantial evidence of other unintended effects of the Sunrise Period. Any comments seeking changes to Sunrise policies bear the burden of proof that such problems exist and are reasonably pervasive enough to warrant considering policy changes. | No | Yes | Some INTA members encountered problems during the verification stage for proof of use at the TMCH, which was a pre-requisite for participation in Sunrise. To be able to qualify for a Sunrise registration, trademark holders are required to submit a sample of use to be verified by the TMCH. In verifying samples of use, the TMCH has in the past taken a very strict approach which, for example, led to the rejection of some legitimate and genuine samples of use which demonstrated the full text of the trademark along with additional text that happened to be on the packaging and which did not affect the distinctiveness or validity of the trademark. This was particularly an issue in non-Latin scripts. | The range of languages/scripts understood by the validators of the TMCH should be expanded. This might particularly be addressed by the introduction of competition for validation services at the front-end of the TMDB, thereby allowing for such services to be operated by providers fluent in other languages and scripts, for example in Asia. Such validated trademark records could all be submitted into the same back-end database, thereby ensuring that contracted parties continue to need only connect to a single database. | Support Recommendation concept with minor change | INTA supports recommendation 1. Regarding the suggested implementation guidance, INTA does not support the third bullet, which we consider to be unnecessary. Within ICANN’s community a range of perspectives and skills sets are already represented (including the specific organizations suggested) and there is no need to formally engage external resources. | Yes | In addition to the perception that the Claims Notice may not be understandable by the lay registrant, some brand owner representatives have also found these notices confusing, where they have received them in respect of their own trademarks when registering domains during the Claims period. | The proposals contained within this recommendation #1 should address the identified concerns. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||
12 | 4/29/2020 13:05:42 | Nacho Amadoz | Fundació .cat | No | No, I would like to continue to the next section | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | Not sure | Not sure | Not sure | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No, I wish to continue to the next section | No opinion | No, I wish to continue to the next section | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | Not sure | QLPs and LRPs were conducted with no issues. The reason ALP was not finally attempted in some cases was the extreme difficulty to obtain assurances by ICANN that approval would be issued by the beginning of the launch period. Integration with sunrise was not a concern, as launch plans were detailed in the TLD application, and any proposal would have followed the requirements set by the ALP program, as set by ICANN. ALPs' approvals should be streamlined so that Registry Operators planning them have clear guidelines and answers from ICANN staff, as they are the only way to conduct a launch phase that has priority over TMCH trademarks. Some TLDs, based on their community or geographical basis, must have a way to provide assurances to certain stakeholders (governments, public services, key community entities) that their names will not be registered by companies with no specific connection to the community | Not to the extent desirable. The main goal that could not be achieved given the design of the Applicant Guidebook was to be able to put community main interested above TMCH trademarks. Trademarks, be them TMCH registered or not, should be protected to the maximum reasonable extent, within the launch period and even afterwards. The level of protection they must be offered by the Registry Operator must be present at all times in cases where there are clear-cut abuse cases. The same level of protection must be offered to the stakeholders described in the previous question against both bona fide trademarkss and abusive TMCH registrations. In some cases, such as public services, public interest and the benefit of the community should prevail over private defensive registrations. | No. The reason the ALP programs that were devised in the TLD applications could not be implemented was the certainty that they would not be approved in time for the launch. | As replied in 3a-2, the main issue was not the number of registrations available during the QLP but the principle at stake. | No | Clear guidelines for future ALPs based on the only ALP precedent, the one conducted by .madrid. | Critical | community TLDs | Yes | Some, but the parties mainly affected by the lack of an ALP are not trademark owners. | Yes, against the public databases of the trademark registries required in the launch period policy. | There are many options here. In case of a GEO TLDs, it would be conceivable that a trademark local to the area represented by the TLD should have priority over a TMCH entry with no connection to the territory. | No opinion | Not sure | No opinion | ||||||||||||||||||||||||||||||||||||||||||||||||||||
13 | 4/30/2020 5:41:47 | Ronald Schwaerzler | DOMAINWORX SERVICE & MANAGEMENT GMBH | No | No, I would like to continue to the next section | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No, I wish to continue to the next section | Support Recommendation as written | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | No opinion | No opinion | Not sure | yes | some - but not all | no | some - not all | I'm representing geoTLDs - they have governmental bodies behind them. It is more than obvious that it must be able to assign e.g. police.london to the city authority prior to any right of the trademark owner (POLICE - sunglasses) | the work-arounds are tolerable, we found ways to work with the issues | no | "reserved names" worked more or less | I don't know | leave as it is - we (the geoTLDs) found ways to get along | Yes | most of the problems (if not all at least of ours) | Yes | priorization of local prior rights over trademarks with no local presence; e.g. AIDA has over 400 outlets / cafes in Vienna, it would have had priority over the cruise ship company AIDA (in Vienna) | No, I wish to continue to the next section | No opinion | No | No opinion | |||||||||||||||||||||||||||||||||||||||||||||||||||||
14 | 4/30/2020 14:41:03 | Amadeu Abril i Abril | Chief Policy Advisor CORE Association | No | No, I would like to continue to the next section | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No opinion | No, I wish to continue to the next section | No opinion | No, I wish to continue to the next section | Significant change required | For community based-TLDs and for geographically oriented TLDs, the following possibility should be allowed: smd label when equal to sld+TLD should be allowed (eg. the smd "RealMadrid" should allow for sunrise registration "real.madrid" or "BBCRadio" as a sunrise registration for "bbc.radio") in case the relevant Registry Operators wish to allow such registrations. | No opinion | Support Recommendation as written | No opinion | Support Recommendation as written | Support Recommendation as written | No opinion | No opinion | Yes | The main source of abuse and conflicts we have witnessed are the following: 1. Figurative trademarks: in trademark law a figurative tm benefits from weaker use prohibendi than word trademarks. Most figurative trademarks respond to the inability to register a given text as a word trademark because it is either a generic or is descriptive or is a forbidden term. The way TMCH handles figurative trademarks into SMD labels has granted protection to registrants in many situations that trademark law does not warrant and priority over non TMCH trademarks and other legitimate interests in a way that trademark law would not warrant. In futurs sunrises if figurative trademarks are accepted as text lables RO should be able to apply restrictions. 2. Jurisdiction cherrypicking: for strict GEO TLDs or geographically oriented TLD, a separate issue arises. Most GEO TLDs have eligibility requirements regarding the registrant but do not require prioruse or specific requirements for eligibility selection. Therefore, they rightly accept sunrise applications from International companies having activity on the relevant territory even if the TMCH entry corresponds to a trademark in a different jurisdiction (e.g: facebook.madrid with an SMD label corresponding to a US trademark). But as no additional requirements are allowed for sunrise applications this has the side effect to allow eligible registrants to create sunrise-purpose only trademarks in "exotic" jurisdictions usually for terms that in the local GEO TLD language would be generic and non-trademarkable or otherwise collide with local trademarsk. In future sunrises GEO TLds should be able to accept trademarks from any jurisdiction so as not exclude legitimate application but should be allowed to require additional checks for eligibility from non-local trademark entries. 3. Generic SMD labels: in a previous question we are asked whether SMD labels should be limited to the category of goods and services for which they've been registered as trademark. We don't think this is reasonable because it would exclude legitimate sunrise application. On the contrary we believe that community-based TLDs and other sector specific TLDs should be able to exclude SMD labels that are specific generic terms for that community/sector. | CORE for its own three IDN TLDs, neither community nor GEO oriented, applied for LRPs and it also submitted LRPs the ten community-based CORE provides BERO services. For the majority of them QLPs were also submitted and in the cases it was not the reason was that the Registry found the 100 names was too limited to run certain programs that would probably have more applicants and did not want to create discriminations. Most community based TLDs working with CORE applied for ALPs in the TLD application, but ICANN staff clearly imposed the view that negotiations would take too long for them to happen in a reasonable timeframe. Only in one case an ALP was conducted, after a 1,5 year. | Even if we and our customers extensively used QLPs and LRPs the actual unavailability of ALPs and sub-optimal rules on sunrise meant that two additional tools needed to be use: a) stricter rules than probably needed to prevent abusive sunrise registrations (generic terms, other non-trademarkable names, etc) and; b) probably an excessive use of reserved names. Which is a clearly inferior tool in both senses that it withdraws from the market an excessive number of names and that it is impossible to foresee all variables to be protected. | See above. The only reason not to use ALPs was the failure from ICANN to provide assurances that they would be approved in a reasonable time. | See above. | Lists are inherently imperfect for these purposes. The criteria matter more than the numbers, and criteria over priority should take into account many interests, among them trademarks. But also other non trademark non TMCH public interests relevant to community and/or geo-geo-oriented TLDs. | Not unanticipated. All those problems we could anticipated as described above were present during sunrises due to the design flaws of the smd system | See above. No, because the QLP100 did not suffice. Even in the case of the only approved ALP (.madrid) ICANN forced an arbitrary limit on it being reserved to public administrations when in a geo-based community TLD there are many private sector actors (cultural, sports, civil society, etc) which deserved top priority protection. | 1. ALPs should not be unreasonably denied or simply postponed into inviability 2. ALPs should not be limited in number of application, as sunrise is not. 3. Priority rights in ALP should be defined in accordance to preexisting rights and community recognition for each specific TLD and not arbitrary criteria (as TMCH accepts trademarks from all actors and sectors) 4. Specifically for GEO TLDs - or geo-oriented aimed at a specific geographic area - local trademarks outside the TMCH should have the same priority than TMCH smd labels 5. TMCH registrants should be public. While tradermark registrations are public, and organizations in domain name registrations also are, smd holders are not. This creates unnecessary tensions in understanding the extent to which some names should be registered and some policies must be restrictive, leaning to excess in both cases. | Critical in order to respect different governance models that embrace community TLDs and their stakeholders. | See above. | Work-arounds are always second best for sensible rules. | Not prior, concurrent and with the same priority. This was denied by ICANN. | Pre-sunrise should have been the RPM requirements document defined ALP, that was never put into practice. Along with local trademarks sunrise for geo/geo-oriented TLDs. | We ran local trademark LRPs for all geo-oriented TLDs and we checked each application the publicly available relevant and official trademark offices databases | As said above, concurrency would imply same priority and the same resolution criteria, which are not unique across all TLDs- | No, I wish to continue to the next section | No opinion | Yes | The technical and operational aspects of claims notices could be vastly improved. As could be the support from the TMCH. This is one of the reasons why many registrars are not accredited with TMCH and do not provide claims services. This results very often in registrations queries for names subject to claims returned by these registrars as "domain not available". Hence, forcing the registrant to withdraw his/her registration. We have seen no examples of such registrars returning messages indicating their lack of connection to the TMCH, indicating end-users to try with TMCH-connected registrars. Example: at the time of the sunrise for .madrid (2019) only six of the fifteen spanish ICANN accredited registrars were connected to the TMCH and thus providing TMCH services. Any discussion for improving or even keeping claims services should take into account this reality. | No opinion | |||||||||||||||||||||||||||||||||||||||||||||||||||
15 | 4/30/2020 15:40:04 | Dennis Foster | Attorney | No | No, I would like to continue to the next section | Support Recommendation as written | Yes | Support Recommendation as written | Significant change required | Translation only if language of registration other than English. Eliminate postal notify. | Significant change required | Too cumbersome. Please simplify. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Yes | Do not support Recommendation | Language of registration, not location of service or respondent. | Support Recommendation as written | Too little. | Yes. | Yes | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
16 | 4/30/2020 11:34:44 | Jan Corstens | Deloitte | Yes | Trademark Clearinghouse | No, I would like to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
17 | 5/4/2020 0:04:10 | Nat Cohen | President, Telepathy, Inc. | No | No, I would like to continue to the next section | Support Recommendation as written | Yes | If the registrant info in the Whois is inaccurate or impersonates someone else. For the panel to determine. | The respondent could be alerted to this option. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | not aware of any | Uniform standards, especially as to "clear and convincing". A mechanism to de-accredit panelists who misapply the URS, such as a review board, independent of a specific URS provider, to review problematic decisions. | Support Recommendation as written | Support Recommendation as written | Similar to the WIPO consensus view for the UDRP with key practice questions reviewed and answered with examples. | Through a group where IP and registrant interests are balanced to develop a consensus view. | It could be through a volunteer WG, or to the extent funding is needed ICANN should support this work on an ICANN developed policy. | may not be necessary, as one of the requirements for panelists is that they be conversant in English. | Support Recommendation as written | Merely saying the tests have been met is inadequate. The Examiner should detail the evidence on which his/her findings rely. | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | As an ICANN developed policy, ICANN must take responsibility for how it is interpreted and applied. | A central structured database, with key elements in XML format, should be developed. This is long overdue for the UDRP. | No. | Yes | Complainant counsel who bring abusive URS should be barred from bringing further URS complaints and from acting as a URS examiner or UDRP panelist, and the ban should extend to partners of the firm of the complainant counsel. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | If more than one entity enters the same word mark for the Sunrise Period, then that term should be excluded from the Sunrise Period as being non-exclusive to any one party. Unless a rights holder attests that its mark meets the legal standard of being a famous mark, no dictionary word, two-letter or three-letter acronym should be included in the Sunrise period because all such terms are non-distinctive to any one entity and are eligible for multiple legitimate concurrent commercial uses. | Yes | Entities have registered TMs on inherently valuable generic terms in regimes that do not require a demonstration of use in commerce in order to get "first dibs" on valuable domain names through manipulation of the Sunrise Period. A trademark registration in law does not exclude non-infringing uses of the same mark, yet the Sunrise Period stifles the ability of start-ups to obtain attractive domain names due to the ability of existing businesses to use their limited rights to claim a monopoly on all commercial use of the mark through the Sunrise Period priority registration process. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Can be intimidating and deter someone from registering a domain for a legitimate non-infringing use. | Make it clear that simply because someone has a TM somewhere in the world for a specific product or service does not prevent someone else from registering the domain name for a non-infringing use. The language should be revised to ensure it does not have a chilling effect on registrations for other legitimate uses. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||||
18 | 5/4/2020 14:05:55 | Jay Chapman | Digimedia.com, LP | Yes | for Digimedia.com, LP | No, I would like to continue to the next section | Support Recommendation as written | Yes | When the respondent is not the registrant | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Thorough contracts with URS providers, along with yearly reviews and recertification, & uniform supplemental rules | Support Recommendation as written | Support Recommendation as written | definition of "clear and convincing", a community prepared "consensus view" of applicable precedent. | bottom-up community development process | ICANN | Yes | Support Recommendation as written | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN | a list of all proceedings maintained by ICANN. | No. Abolish late fees. | No. | Yes | Penalties should also apply to counsel/firms. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The TMCH must be open and publicly accessible - no different, than, for example, the USPTO TM database. Also, no Sunrise for dictionary terms. | Yes | Examples of abuse/gaming were provided in WG discussions - reported in publications | No, I wish to continue to the next section | Support Recommendation as written | Yes | Likelihood of deterring domain registration by a potential good faith, lawful registrant | Generally, provide access to more info. Explain that the TMCN is not an indication or notice of any wrongdoing or that any tm owner has superior right to the particular domain name. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||||||
19 | 5/1/2020 20:07:28 | Vahid Razavi | Ethics In Technology a 501 c3 | Yes | Ethics In Technology a 501c c3 and Myself Vahid Razavi | No, I would like to continue to the next section | Do not support Recommendation | This policy change would allow the trademark owner to amend the Complaint with registrant data which was redacted for privacy reasons (including GDPR and proxy registrations). Although the rationale of the working group was to allow trademark owners to identify registrants who have engaged in a pattern of bad faith registrations, the wording of this recommendation is in no way tied to this goal. Since the URS is a low-cost, low-overhead proceeding, the processes are streamlined by The Forum (the largest of the URS providers). If the trademark owner amends its complaint, that data will be published with the decision absent any further interference. According an individual’s name, or an organization’s location, may be disclosed despite the protection of this data under the personal and sensitive data protections of the GDRP and completely in violation of these protections and privacy rights. Further, the data would be disclosed even if the respondent wins. • This section seeks to obtain input on all the preliminary recommendations and questions related to the Uniform Rapid Suspension System (URS). • Related URS preliminary recommendations and questions are placed next to each other for easy reference Such disclosure – without regard to the “purpose” for which the PII is being obtained and disclosed – is a violation of privacy laws and principles. Any disclosure recommendation must be much more closely tied to the goal of disclosing those with a pattern of proven bad faith registrations. Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | Yes | As above, the disclosure of redacted and private data of individual, organizations and businesses must be done only to further the “purpose” presented in the Working Group – helping disclose those with a pattern of proven bad faith registrations. Absent such a showing, the registrant data should be published as shown in the public WHOIS/RDDS (as it is today). Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | As above, the disclosure of redacted and private data of individual, organizations and businesses must be done only to further the “purpose” presented in the Working Group – helping disclose those with a pattern of proven bad faith registrations. Absent such a showing, the registrant data should be published as shown in the public WHOIS/RDDS (as it is today). Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | Support Recommendation as written | Support Recommendation as written | This is very important to send notification to the registrant. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The materials should include an explanation of the importance of giving rationales so that registrants, claimants, and others can understand the rationale of the decision. They should include model “good” decisions, which include a short and clear statement of the facts (or their absence) leading to the relevant findings. The materials do not need to be extensive, but they should be clear that merely cutting and pasting the URS policy is not sufficient for an acceptable decision. | With input of all stake holders. | ICAN | Yes | Support Recommendation as written | Support Recommendation as written | No opinion | Support Recommendation as written | Support Recommendation as written | ICANN should work with the URS Providers on clear and understandable FAQs for Complainants and Respondents. ICANN’s involvement is important for uniformity. Respondents, in particular, often have no idea of what the URS proceeding in and how they might respond. These materials should be translated into the basic language of key ICANN documents. | The limited data shows that Respondents from US, China, Australia and Japan are paying response fees. In the data analyzed by Rebecca Tushnet’s research assistants, roughly 1/3 of late responses came from the US, which is higher than the US representation in the database generally. The price may be unaffordable for Respondents from Africa and Latin America. Discounts should be allowed for these regions. | Any attempt to set penalties would be inconsistent with the low-cost, relatively low-involvement nature of the URS process, and would inevitably increase costs on participants in the system who have not been identified as wrongdoers. The default rates for respondents are already extremely high; any penalties would (1) be uncollectable and create significant administrative costs in tracking, which would have to be borne by someone; (2) deter legitimate responses. For (1), it is worth noting that US jurisdictions can spend much more money on administration than they collect when they fine populations who can’t or won’t pay. | No | URS is meant to be a simple system. They should not be expanded. | No, I wish to continue to the next section | Significant change required | he TMCH should be more limited. Exact match should continue and be maintained. If a dictionary term is used, it should be used for Sunrise only for related categories of goods and services. Anything else is an overreach of TM rights and claims: ICANN has long indicated its goal of not expanding trademark rights beyond what is granted by national authorities, and extending rights to a text string in unrelated categories of goods or services expands trademark rights substantially. | No, I wish to continue to the next section | Support Recommendation as written | Do not support Recommendation | Do not support Recommendation | This recommendation needs further clarity. | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Do not support Recommendation | It is vitally important that the Sunrise Period be limited to allowing registrations of trademarks only in those gTLDs to which the trademark is logically related. Othewrise, the ICANN policy goes far beyond law to allow ownership of strings and words outside context or categories of goods and services – which is a right never provided in trademark law | The Analysis Group report and investigative stories show that some trademark owners are registering common words for the purpose of gaining privileged access to new domain names in areas completely unrelated to their legal rights. [See response to question 50.] In doing so, they are depriving legitimate noncommercial organizations and entrepreneurs of their ability to register a domain name. These unintended effects should be more closely reviewed, and corrected | Yes | The Analysis Group report and investigative stories researched and shared during WG meetings clearly show that trademark owners are registering common words into the Trademark Clearinghouse. [See response to question 50.] The secrecy of the Trademark Clearinghouse prevents any investigation or audit of abuse and misuse of Sunrise except on an anecdotal basis, but it is clear that TMCH misuse is occurring. See https://onlinedomain.com/2014/04/15/legal/fake-trademarks-stealing-generic-domains-in-new-gtld-sunrises/ (identifying 330 domain names for terms such as social, cloud, and direct (registered in Switzerland as trademarks for pens) registered across multiple unrelated gTLDs in Sunrise). | Support Recommendation as written | Yes | The TM Claims notice is very difficult for potential registrants to understand, and very intimidating. These issues have been discussed at length in the WG and we look forward to a newly draft notice soon. | Written in much clearer and more straightforward language with a fair and balanced explanation; and translated into many languages. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||
20 | 5/3/2020 0:59:46 | Sam Stern | WBRS 100.1FM | Yes | I am writing on behalf of WBRS 100.1FM, a non-profit radio station in Waltham, MA. | No, I would like to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | No, I wish to continue to the next section | Significant change required | If a dictionary term is used, it should only be used if the trademarked goods and services relate to the new gTLD. | No, I wish to continue to the next section | Support Recommendation as written | Do not support Recommendation | Do not support Recommendation | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
21 | 5/3/2020 12:03:27 | Zak Muscovitch | Internet Commerce Association | Yes | This comment is submitted on behalf of the Internet Commerce Association in my capacity as General Counsel. | No, I would like to continue to the next section | Support Recommendation as written | Yes | Where a URS respondent advises the Panel, and the Panel finds that the respondent is not in fact the actual registrant (for example in the case of identity theft, fraud, or a stolen domain name) or where other circumstances militate in favor of not publishing the updated registration data on the basis of exceptional circumstances involving fairness and/or protection of safety and security. | Respondent should be advised in the notice, that if they can request that updated registration not be published based upon exceptional circumstances, but that it is in the normal course. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Employ uniform supplemental rules mandatory to all providers, and employ a comprehensive URS provider contract instead of a Memorandum of Understanding. Annual recertification applications and evaluations should be employed based upon compliance and performance.. | Support Recommendation as written | Support Recommendation as written | Also recommend that a community-developed document be prepared comparable to the WIPO Consensus View. | In part the material should be, modeled on the user friendly and informative materials employed by Nominet. See: https://www.nominet.uk/domain-support/uk-domain-disputes/ Detailed information on the three-part test should be provided and explanations what they mean and require, in particular what “clear and convincing” requires. Detailed summaries of applicable precedent and case law, eg a community-developed “Consensus View” should be provided. A help line for procedural issues should be provided. | By the community through a specialized Working Group of experts. | ICANN through its per domain name registration fee, and Dispute Resolution Providers through their dispute resolution service fees. | Yes | Support Recommendation as written | Examiners must be informed and should certify, that their decisions sufficiently explain their rationale in detail, even if if brief, so that a reader and any review body, including subsequent RPM working groups, can understand the basis for the decision. This is in contrasts to problematic decisions which merely state that the tests have been met. | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN has the responsibility. Funds can be recouped through licensing Dispute Resolution Providers and via the per domain name fee paid to ICANN by registries. | ICANN should maintain a central list of all proceedings. It used to do that for the UDRP. | There should be no additional late fees. | No. The penalties should also apply to counsel/firms who abuse the procedure particularly on multiple occasions, and where the counsel or firm has been so found, they should be permanently prohibited from serving as an Examiner or UDRP panelist. | Yes | No. The penalties should also apply to counsel/firms who abuse the procedure particularly on multiple occasions, and where the counsel or firm has been so found, they should be permanently prohibited from serving as an Examiner or UDRP panelist. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The TMCH should be opened up as a publicly accessible database. For dictionary terms, there should be no Sunrise. | Yes | As reported in numerous publications examined by the WG, parties have gamed the system by filing registrations merely in order to get priority for attractive dictionary term domain names. Since most trademarks are dictionary words capable of lawful use by persons other than trademark registrants, priority should not be given over the general public. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Need to make the Notices more user friendly, provide more information and resources, explain that receiving a Notice does not mean that you have necessarily done anything wrong or that the referenced trademark owner has any superior rights. The Notice needs to take precautions to avoid it appearing to be spam, etc. as per Recommendation #1. Need to provide the prospective registrant with examples of why a registration would likely be considered entirely lawful or unlawful, despite a Claims Notice. | Need to make the Notices more user friendly, provide more information and resources, explain that receiving a Notice does not mean that you have necessarily done anything wrong or that the referenced trademark owner has any superior rights. The Notice needs to take precautions to avoid it appearing to be spam, etc. as per Recommendation #1. Need to provide the prospective registrant with examples of why a registration would likely be considered entirely lawful or unlawful, despite a Claims Notice. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||
22 | 5/3/2020 13:01:12 | Alexander Lerman | Registrant | No | No, I would like to continue to the next section | Support Recommendation as written | Yes | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Supplemental Rules should be the same for all providers. Providers should be under comprehensive contract. | Support Recommendation as written | Support Recommendation as written | All stakeholders should contribute to the development. | ICANN | Yes | Support Recommendation as written | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN | Any fees should be uniform across providers. There should be no additional or increased late fees. | There should be penalties for law firms that repeatedly abuse the procedue. | Yes | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The TMCH should be public so that the public can identify abuses. | Yes | Gaming the Sunrise by recording marks including logos of generic terms to get priority, as reported in industry news. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Far more information and examples for registrants so they know not to be intimidated by a Claims Notice if they have done nothing wrong. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
23 | 5/3/2020 13:41:02 | Dr. Gregg McNair | Group Chairman, Premium Traffic Limited | Yes | Premium Traffic Limited | No, I would like to continue to the next section | Support Recommendation as written | Yes | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Mandatory uniform rules amongst all providers. Providers bound by comprehensive contract that sets out performance standards and complaints procedure. | Support Recommendation as written | Support Recommendation as written | By the community. | ICANN. | Yes | Support Recommendation as written | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN community. | All fees should be standardized amongst all providers. There should be no increase. | Should be penalties also for the lawyers that abuse the procedure. | Yes | Should apply to the lawyers too. If a lawyer abuses the procedure, they should not be an Examiner or Panelist. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The TMCH should be publically accessable to crowd source instances of abuse of the TMCH. No priority should be given to common dictionary words. | Yes | Gaming the system through the TMCH. Enrolling a trademark that was not genuinely used and only obtained to game the TMCH and Sunrise. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Claims Notices should not appear spam-like and should provide genuine guidance to registrants so they are not scared away from an innocent registration. | Claims Notices should not appear spam-like and should provide genuine guidance to registrants so they are not scared away from an innocent registration. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
24 | 5/3/2020 14:46:25 | Matthew Klein | registrant | No | No, I would like to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Uniform rules across all URS providers. Put all providers under a comprehensive contract with performance standards and procedures for deaccreditation and complaints. | Support Recommendation as written | Support Recommendation as written | Via the community. | ICANN | Yes | Support Recommendation as written | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN | Fees should be uniform and capped by ICANN. | Any penalties should also extend to counsel who repeatedly bring an abusive complaint. | Yes | Generally, I feel there are insignificant deterrents/punishments for legal representative who habitually file frivolous or unsuccessful complaints across their client base. Barring an individual complainant from filing cases for 1 year is all well and good, but that is a punishment that will rarely come into play and a complainant can just lodge another complainant after the short 1 year period has expired. Registrants are often the target of suprajudicial cease and desist letters. While there may well be supporting basis for such notices, in some cases these C&D letters are abusive in nature and attempt to coerce a rightfully held domain name from a registrant without due propose. When a losing complainant has first attempted to obtain a domain name through a C&D letter, such actions should be held to be evidence that it has acted in bad faith and filed an abusive complaint. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | TMCH should be open to the public so that it can see if / how it is being gamed by parties using it purely to jumpe the queue on registrations of desireabe common terms. There should be no Sunrise for dictionary terms. | Yes | Gaming the system to jump ther queue by obtaining unused or nominally used trademark registrations over generic terms, including via logos. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Make it far more user friendly and genuinely informative for registrants with links to credible resources. Avoid an appearance of presumptive guilt on the part of registrants. | Make it far more user friendly and genuinely informative for registrants with links to credible resources. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
25 | 5/4/2020 4:23:24 | David Saussinan | Legal Director | Yes | UNIFAB - Union des Fabricants | No, I would like to continue to the next section | Support Recommendation as written | No | We ask the working group to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant and verified data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation concept with minor change | We suggest to change “AND” postmail into “OR” postmail. It would then state: “The Working Group recommends that URS Providers must comply with URS Procedure para 4.2 and para 4.3 and transmit the Notice of Complaint to the Respondent, with translation in the predominant language of the Respondent, via email, fax, or postal mail. URS Provider should not suffer complicated proceedings to contact the Respondent, especially as the email address is usually the sole reliable information.” | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation o complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a deposit mechanism when registering a domain name (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”) or at least a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. The deposit mechanism could permit in case of non-compliance with the URS rules to have more leverage as there are direct assets to seize. Then it could permit to optimize some other related process like UDRP rules etc. (e.g the losing party could be the one paying. It would be fair not have the winning party to support the costs, otherwise it is always worth trying for the cybersquatters). | Support Recommendation concept with minor change | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have verified and up-to-date reliable information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. Either way, these materials should include a suggested list of the evidence that should be provided to support the conclusion that a domain name has been registered and used in bad faith and clear explanations of the three parts of the test. | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). On top of that, URS providers should be doing do. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | To ensure coherence, we should look at whether existing materials from e.g. WIPO can be repurposed. | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | When attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes. | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. A deposit mechanism paid by the Registrant at the moment of the registration of the domain name would permit to establish a better balance regarding the burden of the penalties and an efficient way to recover money in case of abuse by the Respondent (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”). It could then be a way to stop the fact that Complainants have to pay for UDRP and that there are no penalties for Respondents. This mechanism is encouraging cybersquatters as there is no risk at all except the fact that they may lose a domain name (extremely low cost: 10USD compared to UDRP: 1500USDmin fees). | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload… | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | d. Other: In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | Same as previous question. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | ||||||||||||||||||||||||||||||||||||
26 | 5/4/2020 9:54:31 | Massimo Vittori | Managing Director of oriGIn | No | No, I would like to continue to the next section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
27 | 5/4/2020 9:59:01 | Marianne Georgelin | Afnic | No | No, I would like to continue to the next section | Support Recommendation as written | Yes | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation as written | Support Recommendation as written | No, I wish to continue to the next section | No opinion | No, I wish to continue to the next section | Support Recommendation as written | No opinion | No opinion | Support Recommendation as written | No opinion | No opinion | No opinion | No opinion | No | An ALP is entirely relevant for geographic TLDs that wish to favor non public local organizations over international trademarks. But the timeline to obtain ICANN's approval for an ALP was too discouraging. | Yes, by using the possibility to reserve 100 domain names prior to the Sunrise period. | Yes, we did use that option for a pionner program (geoTLD) and had to deal with a lot of unclear questions/concerned raised by ICANN requiring a long and difficult negociation for a very simple program. | Yes. But a clear and fast process for obtaining ICANN's approval for an ALP would have been a more adapted way to achieve this goal. The goal of these programs is to provide innovative solutions to launch and promote a new gTLD. | No (except for the one described above) | When an ALP fully comply with the protection of reserved names and protected names under TMCH, there is no reason for delaying its approval. | Yes, in the case of geoTLDs, for trademark owners but also for local registered companies without trademarks | Yes | Yes, marks or registrered company names | For geoTLDs, with a clear priority set of rules. | No, I wish to continue to the next section | No opinion | No opinion | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
28 | 5/4/2020 10:29:59 | Laurent Dhennequin | Comité Colbert | Yes | I answer on behalf of the Comité Colbert | No, I would like to continue to the next section | Support Recommendation as written | No | We ask the working group to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant and verified data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation concept with minor change | We suggest to change “AND” postmail into “OR” postmail. It would then state: “The Working Group recommends that URS Providers must comply with URS Procedure para 4.2 and para 4.3 and transmit the Notice of Complaint to the Respondent, with translation in the predominant language of the Respondent, via email, fax, or postal mail. URS Provider should not suffer complicated proceedings to contact the Respondent, especially as the email address is usually the sole reliable information.” | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation o complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a deposit mechanism when registering a domain name (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”) or at least a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. The deposit mechanism could permit in case of non-compliance with the URS rules to have more leverage as there are direct assets to seize. Then it could permit to optimize some other related process like UDRP rules etc. (e.g the losing party could be the one paying. It would be fair not have the winning party to support the costs, otherwise it is always worth trying for the cybersquatters). | Support Recommendation concept with minor change | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have verified and up-to-date reliable information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. Either way, these materials should include a suggested list of the evidence that should be provided to support the conclusion that a domain name has been registered and used in bad faith and clear explanations of the three parts of the test | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). On top of that, URS providers should be doing do. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | To ensure coherence, we should look at whether existing materials from e.g. WIPO can be repurposed. | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | When attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | yes | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. A deposit mechanism paid by the Registrant at the moment of the registration of the domain name would permit to establish a better balance regarding the burden of the penalties and an efficient way to recover money in case of abuse by the Respondent (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”). It could then be a way to stop the fact that Complainants have to pay for UDRP and that there are no penalties for Respondents. This mechanism is encouraging cybersquatters as there is no risk at all except the fact that they may lose a domain name (extremely low cost: 10USD compared to UDRP: 1500USDmin fees). | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload… | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | Same as previous question. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | |||||||||||||||||||||||||||||||||||||
29 | 5/4/2020 16:08:29 | Peter Vaughan | Chartered Institute of Trade Mark Attorneys | Yes | Provided on behalf of the Chartered Institute of Trade Mark Attorneys | No, I would like to continue to the next section | Support Recommendation concept with minor change | This would be better as 2-3 business days. This would align with the type of entity (businesses rather than individuals) likely to be using the URS. Using calendar days as the criteria would pose difficulties with deadline management, especially where the two days fell over the weekend. It would also not be aligned with common practice relating to deadlines at Intellectual Property Offices. | Details should be published to prevent potential frustration of future complaints and masking of serial offenders. With the possibility for a Respondent to make submissions (to which the Complainant could respond) as to why their details should be masked. But without active Respondent engagement the determination should include the updated registration data. If the Respondent can seek to have this withheld then there need to be clear criteria for deciding this - it may only be appropriate for private individuals and not those trading in domain names, for example. Where a decision is against the Respondent the full details should be published to ensure tracking across multiple decisions is possible. Where a Respondent looses there should be a strong presumption of publication. | Only on submission by a Respondent who has actively engaged in proceedings - perhaps as part of their response. The Complainant would need a right to reply. | Support Recommendation as written | Support Recommendation concept with minor change | Providers should follow the rules as set out. | Support Recommendation as written | Any party in URS process - and provider, examiner, registrar | Failure to disclose underlying WHOIS data. | Clear avenue for complaint to ICANN about these entities to try and ensure compliance with their obligations. | Support Recommendation as written | Support Recommendation as written | This is important in seeking to provide consistent decisions which can be supported and have precedential value. Allows for greater understanding of why a decision was taken and for better advice to be provided as to chances of success. A good model would be the WIPO and Nominet guides. | A searchable decision database, FAQ Document, Template Complaint. A good model would be the WIPO Overview and Nominet Expert Overview. | In conjunction with panellists, practitioners, academics and registrars. | The URS providers. | Not as an obligation but at the discretion of the provider to do so if they wish. | Support Recommendation as written | Proportionality is important - should be at current level but rules applied. | Support Recommendation as written | It is important that a Complainant has the option to renew or extend a suspension period using their registrar of choice as this will also aid with portfolio management and prevent being tied to a Registrar which is not suitable to the Complainant. | Yes | Support Recommendation as written | Support Recommendation concept with minor change | No translation needed as an obligation - if needed funded by ICANN - however this shouldn’t discourage providers to produce in other language if the wish to do so. | URS Providers; there should be room for some difference between providers to encourage competition between providers. | Live database hosted by each URS Provider of currently ongoing Complaints which is publicly searchable by domain name and Respondent / Complainant. | Currently very one sided and no discouragement for a Respondent engaging in abusive conduct. Some form of sanction against a serial and abusive Respondent would be desirable. | Yes | Sanctions for a Respondent need to be considered | No, I wish to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
30 | 5/4/2020 11:00:12 | Romain MALLET | CHANEL | Yes | CHANEL | No, I would like to continue to the next section | Support Recommendation as written | No | We ask the working group to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant and verified data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation concept with minor change | We suggest to change “AND” postmail into “OR” postmail. It would then state: “The Working Group recommends that URS Providers must comply with URS Procedure para 4.2 and para 4.3 and transmit the Notice of Complaint to the Respondent, with translation in the predominant language of the Respondent, via email, fax, or postal mail. URS Provider should not suffer complicated proceedings to contact the Respondent, especially as the email address is usually the sole reliable information.” | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation o complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a deposit mechanism when registering a domain name (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”) or at least a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. The deposit mechanism could permit in case of non-compliance with the URS rules to have more leverage as there are direct assets to seize. Then it could permit to optimize some other related process like UDRP rules etc. (e.g the losing party could be the one paying. It would be fair not have the winning party to support the costs, otherwise it is always worth trying for the cybersquatters). | Support Recommendation concept with minor change | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have verified and up-to-date reliable information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. Either way, these materials should include a suggested list of the evidence that should be provided to support the conclusion that a domain name has been registered and used in bad faith and clear explanations of the three parts of the test | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). On top of that, URS providers should be doing do. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | To ensure coherence, we should look at whether existing materials from e.g. WIPO can be repurposed. | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | When attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. A deposit mechanism paid by the Registrant at the moment of the registration of the domain name would permit to establish a better balance regarding the burden of the penalties and an efficient way to recover money in case of abuse by the Respondent (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”). It could then be a way to stop the fact that Complainants have to pay for UDRP and that there are no penalties for Respondents. This mechanism is encouraging cybersquatters as there is no risk at all except the fact that they may lose a domain name (extremely low cost: 10USD compared to UDRP: 1500USDmin fees). | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload. | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | Same as previous question. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | ||||||||||||||||||||||||||||||||||||
31 | 5/4/2020 11:12:12 | Marie Pattullo | AIM - European Brands Association | No | No, I would like to continue to the next section | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | We support the goal of the Recommendation but it must be amended to provide for enforcement, including appropriate sanctions, for non-compliance. | There should be consistent compliance which could be assisted by harmonised contract terms and conditions. Urgent steps to ensure the accuracy of the underlying data are also needed. | Support Recommendation as written | Support Recommendation as written | These materials should include a suggested list of necessary evidence to show that a domain name has been registered and used in bad faith, including clear explanations of the three parts of the test, especially how to reach the “clear and convincing” threshold. | By the community, URS providers and panelists and ICANN Org. | ICANN Org. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation as written | We need a harmonised system, so any such guidance would need the expert input of providers. | Support Recommendation as written | Again to ensure coherence, we should look at whether existing materials from e.g. WIPO can be repurposed. | The community, providers, panelists and ICANN Org. | While the parties must notify the URS provider of any concurrent proceedings, if a registrar receives a complaint so tries to lock a domain name, that registrar should inform the URS provider if that domain name has already been locked for a concurrent proceeding. | Yes; we support reasonable Respondent fees. | As no evidence of abusive URS Complainants has been established, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents, which is unfair, presupposing that only one party could act in an abusive manner. Comparable penalties for abusive Respondents should therefore be introduced. | Yes | The procedures that apply to abusive Complainants as to “deliberate material falsehoods” should be extended, so that they also apply to Respondents. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Limiting Sunrise to the categories of goods and services for which the TM is actually registered would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
32 | 5/4/2020 11:49:22 | Stella Padovani | Moncler SpA | No | No, I would like to continue to the next section | Support Recommendation as written | No | We ask the working group to pay attention to the question of transparency when triggering this option. In fact, we should avoid any risks of making this URS process inefficient. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers could send better and more specific notices to the Respondent if they do receive relevant and verified data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which need to be tackled strongly and without any tolerance. | Support Recommendation concept with minor change | We suggest to change “AND” postmail into “OR” postmail. It would then state: “The Working Group recommends that URS Providers must comply with URS Procedure para 4.2 and para 4.3 and transmit the Notice of Complaint to the Respondent, with translation in the predominant language of the Respondent, via email, fax, or postal mail. URS Provider should not suffer complicated proceedings to contact the Respondent, especially as the email address is usually the sole reliable information.” | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified and go even further. Indeed, enhancing compliance cannot be limited to a possibility of investigation o complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest that a deposit mechanism when registering a domain name (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”) or at least a sanction mechanism should be applied to all these actors if not coping with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. The deposit mechanism could permit in case of non-compliance with the URS rules to have more leverage as there are direct assets to seize. Then it could permit to optimize some other related process like UDRP rules etc. (e.g the losing party could be the one paying. It would be fair not have the winning party to support the costs, otherwise it is always worth trying for the cybersquatters). | Support Recommendation concept with minor change | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. On top of that, it is crucial to have verified and up-to-date reliable information in order for this URS mechanism to be perfectly useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to the different types of infringing. Either way, these materials should include a suggested list of the evidence that should be provided to support the conclusion that a domain name has been registered and used in bad faith and clear explanations of the three parts of the test | In order for the educational materials to please every stakeholder, we suggest a survey should be developed and posted online in order for everyone to give its recommendations/opinions and specify the key elements they would find useful in these educational materials. | The costs of developing the educational materials should be borne by ICANN’s as part of its arbitration centers’ missions. Interested actors should however be given the opportunity to take part in its development (thanks to the survey we proposed in question URS Q4b). On top of that, URS providers should be doing do. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceeding could be registered as best practices in order to gain some time when facing similar other proceeding or Determination. | Support Recommendation as written | To ensure coherence, we should look at whether existing materials from e.g. WIPO can be repurposed. | We suggest developing the uniform set of basic FAQs for URS Complaints and Respondents should be done by ICANN and the community. Indeed, that allows the URS process to be developed thanks to cooperation and inclusion of all stakeholders. | When attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | YES | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. In our opinion, this system is unfair, because it presupposes that only one party could act in an abusive manner. Which is often not the case… | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material falsehoods” should be extended to apply to Respondents, and not just Complainants. A deposit mechanism paid by the Registrant at the moment of the registration of the domain name would permit to establish a better balance regarding the burden of the penalties and an efficient way to recover money in case of abuse by the Respondent (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”). It could then be a way to stop the fact that Complainants have to pay for UDRP and that there are no penalties for Respondents. This mechanism is encouraging cybersquatters as there is no risk at all except the fact that they may lose a domain name (extremely low cost: 10USD compared to UDRP: 1500USDmin fees). | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation concept with minor change | We fully agree with that recommendation. It is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would participate indirectly in the influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We suggest and support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially the one concerning the possibility of increasing the Registry Operators’ workload… | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | We have no objection to this recommendation. As it is stated and supported by some members of the working group: limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely intellectual property rights of trademarks. | Not sure | Not sure | No opinion | No opinion | In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | Some trademark holders can experience different kind of problems, such as translation issues, or more generally transcriptions of technical elements who are specific to the language/country of the trademark holder. | Same as previous question. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. For trademark holders for instance, it would help fighting against intellectual property rights infringements. As it is one of the most vital aspects of ICANN’s work regarding trademark holders, it is essential to ensure efficiency, clarity, precision and conciseness. | Not sure | Support Recommendation as written | Once again and as it was proposed in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | |||||||||||||||||||||||||||||||||||||
33 | 5/4/2020 13:39:36 | Susan Payne | IPC Secretary | Yes | IPC | No, I would like to continue to the next section | Support Recommendation as written | No | The IPC does not support the notion that there should be an option for a determination to be published without the names of the parties involved. Not publishing the name of a Respondent involved in a proceeding creates uncertainty and allows for a bad faith actors to shield their prior activities. The decisions in these proceedings are meant to be publicly available and searchable, and the privacy concerns are not greater in these types of administrative proceedings than those in court actions which typically publish the names of the parties involved in a matter. | Support Recommendation concept with minor change | Support the recommendation as written, with the caveat that if the registry or registrar do not timely provide, or fail to provide, within the designated period of time, the underlying information regarding the Respondent, the URS provider shall then send the notice by the prescribed manner to the Respondent at the contact information that is then available. | Significant change required | The IPC supports the intent of this recommendation, requiring URS Providers quickly and effectively provide registrant with notification of a Complaint, in clear and understandable language. Compliance with these notice requirements bolsters the efficiency and integrity of the URS mechanism. The IPC believes there would be benefit in more closely aligning the relevant language with that of the UDRP, where the reference is to the language of the registration agreement. For the avoidance of doubt, if recommendation #3 is retained then URS Procedure 4.2 provides that "The Notice of Complaint shall be in English and translated by the Provider into the predominant language used in the Registrant’s country or territory" rather than "the prodominent language of the respondent", and so recommendation #3 should be amended accordingly to accurately reference the existing procedure. | Support Recommendation concept with minor change | The IPC supports the intent of this recommendation, which aims to ensure that there is a designated compliance mechanism to enforce the rules and requirements of the URS process. The IPC agrees that is important for interested parties to be able to raise issues with ICANN Compliance and have an effective mechanism for addressing non-compliance issues. The IPC notes that interested parties can already reach out to ICANN Compliance regarding contracted parties and dispute providers, and we believe that Compliance should be equally applicable for URS, just as it should be for UDRP. However, a number of the recommendations of this WG are essentially to the effect that the URS procedure and rules should be followed, indicating that the community considers existing compliance mechanisms to be inadequate or are not being followed. Additionally, the IPC would like to see a specific mechanism in place whereby failure to comply with reveal requests from a party with a legitimate interest should be an automatic trigger allowing for ICANN Compliance to act. The IPC further believes that such failures to respond to reveal requests occur too frequently, and undermine the effectiveness of dispute resolution mechanisms. | The IPC believes the question of compliance issues in URS processes parallel issues in the UDRP. Both the URS and UDRP are reliant on responses by registrars to reveal requests and access to accurate registrant data in order for the RPM to be effective. So even if the number of compliance issues raised directly in URS processes to registries and registrars may be small, the need for consistent and effective relief exists. Registrar members of the IPC have encountered losing registrars who have failed to transfer a name as ordered by a UDRP panel, subsequently allowed it to lapse, thereby resulting in it being registered again and lost to the winning brand owner. In such circumstances, ICANN Compliance has appeared unwilling to take any action or impose any sanction. See also our comments on URS Recommendation #8 | The IPC would suggest that a critically important step towards enhanced compliance would be to ensure reasonable access to accurate, current registrant data upon legitimate request. However, the IPC recognizes that the EPDP is not proceeding in a manner that will allow for this (i.e., not dealing with accuracy). Unfortunately, the IPC believes the efficiency and usefulness of the URS is diminished without such guarantees of access to accurate and current registrant data. | Support Recommendation as written | Support Recommendation as written | A high standard of proof is the fundamental characteristic of the URS. By requiring ‘clear and convincing’ evidence, there are no disputed questions of material fact. Clear-cut trademark infringement provides the basis for expedited remediation. It is, therefore, critically important that the standard is applied consistently, even by multiple URS Providers who pull Panelists from various countries where evidentiary standards may vary. The IPC believes that uniform application of the ‘clear and convincing’ standard for URS filings results in consistent outcomes, shared understanding by all the parties, a reduction in frivolous or malformed filings, and provides the basis for future performance evaluation. Such uniformity could also reduce undesirable activities like forum-shopping and complaints against Panelists. Therefore, the IPC supports the formation of a small group of experienced URS Practitioners (both Complainant & Respondent), Providers, and subject matter experts to draft educational materials elucidating the ‘clear and convincing’ standard in a simple, easily understandable format such as a checklist or guide. ICANN's participation to facilitate production of the materials, but no to opine on the legal standard, would be desirable. It should be noted that Panelists are vetted and selected because of their expertise in these matters. The IPC believes that the educational material should not constrain their ability to make fair and sound decisions relevant to the specifics of each dispute. Rather the IPC supports a simple document that can facilitate a consistent interpretation of the standard. Lastly, it is the opinion of the IPC that this proposal has the support of the community. Although (2) of (3) URS Providers offered a tepid response when surveyed, the remaining Provider supported the development of such guidance and a plurality of Practitioners representing both Complainants & Respondents agreed that more guidance would be helpful. | As Panelists are experts selected for their in-depth knowledge of the subject matter, the content should be a concise & specific description of the standard as applied to the URS, which should be provided in a simple format such as a checklist or worksheet. To be clear, these materials are not legal advice, rather they are intended to give guidance for panelists to bear in mind when they are making their own expert determination, based on the facts of each case before them. | Given the technical nature of the subject matter, the IPC recommends convening a small group of experienced URS Practitioners (both Complainant & Respondent), Providers, and subject matter experts to draft the educational materials. Once approved, the educational materials should be provided to the IRT team tasked w/ implementing the RPM working group proposals. | ICANN should pay for educational materials developed to clarify its enforcement mechanisms and benefit the community at large. | Yes | Support Recommendation as written | There is disagreement as to the extent that this is an issue. The vast majority of URS decisions have a reasonably stated rationale for the decision and there is only a small set of URS decisions that might fall in this category of not stating a rationale. That being said, the IPC supports the idea of a requirement that Panelists provide a reasonably expressed rationale for the decision issued. The IPC does not support the notion of a detailed checklist of items to be included or a template to be followed. There is no need for such as most decisions have clearly expressed rationales and the possibility of imposing detailed requirements could become onerous in what is supposed to be a streamlined process. In addition, given the fees paid to Panelists for a URS decision, imposing strict requirements may deter many good Panelists from not wanting to take on URS cases, which will harm both Complainants and Respondents. In addition, imposing strict checklist requirements or templates are likely to create additional issues and burdens on Providers as well as the possibility of challenges of decisions on technical grounds, if only to delay the conclusion of proceedings. As such, the IPC believes that this issue, which involves a small number of cases, can be handled more easily and efficiently by simply requiring that Panelists provide a reasonably expressed rationale for their URS decisions, and by requiring providers to not release a decision until such contains a stated rationale for the decision. | Support Recommendation as written | IPC encourages IRT to ensure that Rrs, Rys, & Providers understand their roles & responsibilities in implementing URS outcomes; timely perform their duties; & that compliance mechanisms are created/strengthened and made accessible to ensure URS functions as intended. Given seriousness of the abuse and high standard of proof, relief should be swiftly implemented & capably administered. Important deficiencies exist. Provider survey indicates CP confusion about their role in extending suspensions. Providers encountered difficulties: slow response, slow/no response to provider info requests; delayed lock notification; delay notifying completion of suspension; and inaction/lack of communication to Providers requesting notification. Note there seems no consensus among Providers on whether Registrant info of suspended domains may be changed on suspension renewal. Some FORUM Examiners supported alteration. Practitioners survey also reveals suspension problems. 1/3 Practitioners said “problems with the implementation of the relief awarded following a URS decision.” Including difficulties: renewing suspensions, paying for renewals, & re-registration by losing Respondents or other “cybersquatters”. Some Practitioners consider this reduces/eliminates value of URS. INTA survey found “While the URS is helpful, the escalated proof required & limited remedy makes it of limited usefulness” noting utility of the mechanism is lost when the only relief, suspension, is not swiftly & correctly applied. Therefore, vital that CPs understand their responsibilities & the required technical procedures. Even domain investors note flaws. DomainNameWire: “It seems that the way URS works doesn’t fit into any existing automated procedures. It’s manual and requires a lot of human intervention, including when it comes time for renewal/expiration. That human intervention can be a problem… In some cases, the domain name registrar might have overlooked a manual process, and in others the registry did.” | Yes: As discussed in the WG, there can be circumstances where it is appropriate to move the domain from the registrar of record to an alternative registrar in order to enable the complainant to pay for the additional year's renewal anticipated by te URS - for example where the complainant cannot pay the existing registrar due to OFAC concerns, or where the registrar is one with a reputation as a bad actor. | Support Recommendation as written | The IPC believes it is important that there be consistency in guidance across URS service providers to ensure greater consistency in both instructions and resulting decisions. See our comments on URS recommendation #3 above,which would address the privacy/proxy concern. | Support Recommendation as written | The IPC agrees that ICANN should develop educational materials for Complainants & Respondents which outline the URS process. The materials should include an easy-to-understand, concise process overview, simple FAQ page, and copies of common documents; list links to Provider websites and compliance mechanisms; and be translated into the six United Nations languages. Much of the Providers’ processes are automated and offered online, so Complainants and Respondents are often on their own when navigating the procedure. MFSD and ADNDRC have a manual administrative review following submission. Deficient complaints are dismissed without prejudice (they cannot be amended), but the filing fee is not refunded. The RPMs PDP, Session 4 (March 15, 2018/San Juan) showed little uniformity in how the URS is administered by the three Providers: • ADNDRC, a collaboration of four Asian organizations, communicates only in English • FORUM provides downloadable documents and step-by-step explainer videos on their website • MFSD provides detailed descriptions of the URS program, rules and fees on their website • ADNDRC has six unlinked bullet points for rules & procedures, a flowchart, and submission guide • FORUM is aware that some Respondents did not file a response as they did not know how to proceed • FORUM received a number of complaints about their online portal • The Providers were generally amenable to the creation of these materials to supplement the information they already offer NOTE: Providers should be allowed to provide additional resources that may be useful to the parties and information on their own services and practices. The recommended guidance would demystify the URS, set reasonable expectations, and increase URS use and satisfaction. The IPC supports these goals. | ICANN should draft for the community to comment. | This is a situation that rarely occurs and is one that in most instances would be known to a Respondent, and which should be raised by a Respondent. To the extent there is consensus that there is a need to address this rare issue that may in fact have never occurred, then it should be limited to a simple check by a provider (as part of their normal review of a matter) of existing online databases of pending cases to make sure that the domain name at issue is not involved in another case. | The late fees as written are reasonable. The Respondent has the choice of paying the late fees to avoid a default. | URS Q #10 refers to penalties for a complainant or respondent who abuses the URS process. Whilst the URS procudure does include specific penalties for a complainant found to have abused the the process, there is in fact no penalty for an abusive respondent, whether this takes the form of abusing the URS process or repeated cybersquatting. In order to bring appropriate balance, and to encourage good behaviour, there should also be penalties for abusive respondents. Regarding the existing penalties for complainants, the IPC considers these to be more than sufficient. Indeed, in the absence of the balance that would be brought by penalties for the respondent, we consider these to be unduly harsh. | Yes | See URS Q10a | No, I wish to continue to the next section | Do not support Recommendation | The IPC supports maintaining the status quo on questions 1 and 3. The IPC does not support maintaining the status quo on question 2. As noted in related comments on the exact match issue below (see comments on Sunrise Recommendation #1 and Trademark Claims Recommendation #6) we consider the matching rules ought to be expanded. Given the substantial number of URS and UDRP decisions involving disputed domains incorporating a brand owner's mark in its entirety, some consideration for expansion should be given. The IPC suggests that for the purposes of Trademark Claims in particular we would strongly support expanding matching to also include "mark plus" and “mark-contained” variations. We would support expanding the matching rules to any variation in which the entire mark is contained – we believe this is important in terms of deterring bad faith registrations that rely on variants and not exact matches of a TMCH-recorded mark and to enhance the ability of TMCH-recorded mark owners to more robustly monitor new registrations for possible infringement and bad faith registration/use. | Yes | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
34 | 5/4/2020 15:17:32 | Steven Kennedy | Domain registrant, founder SK Creations Inc. | No | No, I would like to continue to the next section | Support Recommendation as written | Support Recommendation as written | ICANN by its per domain reg fee, and dispute resolution providers covered by their dispute fees | Yes | Support Recommendation as written | Examiners should be required to explain the rationale for their decisions in detail so readers can understand why the decisions are made. Not just check a box on the reasoning. | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN | ICANN should keep a list of all proceedings that can be easily checked against by URS and UDRP Providers. | There should be no late fees. | No. The penalties should apply to attorneys and their law firms as well, not just the complainant business. And these abusive attorneys and firms should not be able to serve as UDRP panelists or URS Examiners. | Yes | The penalties should apply to attorneys and their law firms as well, not just the complainant business. And these abusive attorneys and firms should not be able to serve as UDRP panelists or URS Examiners. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Make the TMCH publicly accessible, and there should be no Sunrise for dictionary words. | Yes | Many articles have pointed out how parties have gamed the Sunrise system by applying for trademarks solely in order to register attractive dictionary word domains. Dictionary word domains should not be eligible for Sunrise. | No, I wish to continue to the next section | Support Recommendation as written | Yes | First of all, it needs to look less like spam. Then it needs to be more user friendly, offer resources for explaining what is going on better, and make it clear that the registrant has not necessarily done anything wrong just based on a filing being made. Provide examples of registrations that are lawful even though a claim has been made. | First of all, it needs to look less like spam. Then it needs to be more user friendly, offer resources for explaining what is going on better, and make it clear that the registrant has not necessarily done anything wrong just based on a filing being made. Provide examples of registrations that are lawful even though a claim has been made. | Support Recommendation as written | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
35 | 5/4/2020 13:54:17 | Crescent Ezekwu | Com Laude | Yes | Input is provided on behalf of Nom-IQ Limited (t/a Com Laude), Consonum, Inc. (dba Com Laude USA and Valideus USA), Demys Limited and Valideus Limited (collectively referred to as “Com Laude”) | No, I would like to continue to the next section | Support Recommendation as written | No | It is appropriate that this be left to the discretion of the panellist. Generally it will be in the interests of justice for the respondent’s name to be published in the determination. | Support Recommendation as written | Support Recommendation concept with minor change | Support compliance with the existing procedure. URS para 4.2 refers to the predominant language of the country of the respondent, not the respondent’s predominant language. | Support Recommendation as written | Although we have not seen issues arise specifically in the URS (anecdotally, our clients look to the UDRP - with its enhanced transfer mechanism - more than the URS), we have encountered issues in the UDRP where the respondent’s registrar fails to timely comply with the UDRP outcome (transfer of the domain to the Complainant). While this is not a URS issue, to the extent there are compliance issues with the URS, the same principle applies: effective enforcement by ICANN Compliance is required to ensure that non-compliant registrars fulfil their URS obligations under their RAA accreditation. | We support Recommendation #4 in principle. ICANN must implement effective enforcement of its existing compliance mechanisms (or enhance them if necessary) to ensure its contracts with the URS Providers, Registries and Registrars are fulfilled. | Support Recommendation as written | Support Recommendation as written | We support the recommended goal of providing guidance on the 'clear and convincing' standard for the URS burden of proof. However, this should be informational in nature, intended as an aid for Examiners and not limit their ability to exercise their judgment based on the facts of the case before them. This could take the form of FAQs or a reference checklist. | The materials should be developed through the collective work of subject-matter experts - Examiners, practitioners, and the URS Providers. | ICANN should bear the cost. | Yes | Support Recommendation concept with minor change | We agree with the principle that Examiners should document their rationale, but not with the suggestion that a standard should necessarily apply across the board. What is sufficient rationale may vary from one matter to another, depending on the specific facts and circumstances. Additionally, the URS is intended to be a lower cost, rapid suspension system for clear and convincing cases. The effect of this recommendation should not place an undue administrative burden on URS Providers and their Examiners. | Support Recommendation as written | Yes | Support Recommendation as written | Support Recommendation as written | ICANN | If such a mechanism is required, the precise means should be agreed by the providers. | Yes - it is reasonable for a Respondent to pay a late fee in order to avoid a default and we have no reason to believe the fees as noted are unreasonable. | There are no penalties for a respondent who abuses the URS process. There have been no complaints to date, to our knowledge, which have been determined as abusive. We have no reason to believe the penalties on complainants are insufficient, therefore, although in the absence of a corresponding penalty for a respondent, the penalty for a complainant actually seems unreasonable. | Yes | There seems to be no reasonable basis for penalties to apply only to Complainants. A Respondent is also capable of abusing the URS process, for example, by abusing the Response filing procedure in order to deliberately obstruct effective resolution of proceedings. Further, there are no penalties for Respondents who repeatedly lose URS cases, and so the URS fails to provide a sufficient deterrent against future bad faith registrations. | No, I wish to continue to the next section | Significant change required | We support the WG's recommendation to maintain the status quo for issues (1) and (3) of TMCH Recommendation #1. As far as issue (2) is concerned, we understand this is a contentious matter on which there are differing views within the WG. A number of our clients' feedback has indicated that current matching rules for the Claims service should be extended “mark plus” and “mark contained”, as it is common for cybersquatters to register a brand name together with additional material. Many brand owners believe they are denied the opportunity to register during sunrise and denied a preventative benefit from the Claims service, and so must instead look to more costly curative mechanisms. | No, I wish to continue to the next section | Do not support Recommendation | As with TMCH Recommendation #1 above, while we recognise the differing views within the WG, a number of our clients have reported that the current matching rules are limiting and provide inadequate preventative benefit, in an already much expanded gTLD landscape. | Support Recommendation as written | We strongly support the principle underpinning this recommendation. Effective implementation and robust enforcement will be essential. | Do not support Recommendation | We provide registrar services to brand owners as well as new gTLD consultancy and registry management services to TLD registry operators, including Geo and community TLDs. A number of our brand owner clients would support a challenge mechanism to address a minority of registries who may seek to circumvent the RPMs, including by adopting pricing policies and premium/reserved names lists specifically targeting certain brand owners. We recognise that this is contentious within the WG. | Do not support Recommendation | As above, with Sunrise Recommendation #3, this touches on important issues for brand owners, but also raises implementation concerns for registries. The adoption of an effective means for brand owners to challenge registry circumvention of RPMs is needed. If appropriately implemented, Sunrise Recommendation #2 may strike a suitable balance for brand owners and registries. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | See responses to Sunrise Recommendations #2, #3 and #4 | A number of abuses were identified by brand owners in the INTA survey. In addition, in the context of the TM-PDDRP, brand owners identified various abusive behaviours, which were never reviewed and discussed in any detail by the WG. They can be found here: https://community.icann.org/display/RARPMRIAGPWG/Additional+Documents+and+Materials+on+the+TM-PDDRP?preview=/61606586/62399692/Collated%20Examples%20of%20Perceived%20Registry%20Conduct%20within%20TM-PDDRP%20scope%20-%2017%20Oct%202016.pdf | Yes | Inflexible verification process at the TMCH for proof of use samples (needed in order to participate in sunrise), leading to the rejection of legitimate samples of use where the trade mark as used on the sample is accompanied by additional wording which does not affect the distinctiveness of the mark. | No, I wish to continue to the next section | Support Recommendation as written | The deliberations of the WG in forming a recommendation here indicate a lack of available data in reaching its findings. However, we are supportive of the general aims of reviewing the Claims Notice to ensure it is clear, and understandable to a layperson. | Yes | Our client feedback has noted, among other issues (i) the ability of potential registrants to ignore the notice and proceed to register a matching domain; (ii) the fact that the Notices only cover domains considered an “exact match”; and (iii) the fact that the brand owner is not notified of the intention to register the domain in advance. Further, if the brand owner uses a TMCH agent who is not their registrar of record, then Claims Notices are sent in relation to the brand owner's own domains - a burdensome task made worse by the limited information provided in the notice. | In addition to the implementation guidance provided in Trademark Claims Recommendation #1, addressing the issues noted in our response to Trademark Claims Q1a-2 above would also go a long way towards making Claims Notices much more effective for both the potential registrant and relevant brand owner (although we recognise certain implementation challenges would arise with some of the issues raised). | Support Recommendation as written | |||||||||||||||||||||||||||||||||||||||||
36 | 5/4/2020 13:53:04 | Sarah Wyld | RrSG | Yes | Tucows family of registrars | No, I would like to continue to the next section | Support Recommendation as written | Yes | Personal data ought not be published. The personal data provided to the URS Provider and by the URS Provider to the Complainant has served its purpose by identifying the registrant's information to those two interested parties with a legitimate purpose. There not only is no need to publish these personal data publicly, there is a law against it. | Support Recommendation concept with minor change | Agree with some edits: we recommend that the word "Registrar" be struck from this recommendation because the URS applies to registries. | Support Recommendation concept with minor change | We recommend removal of "fax, and postal mail" so that translations may simply be transmitted per email. Internet services should be prioritized when communicating about Internet services. URS procedures and explanations must be transmitted to the Respondent in English. If additional languages are offered by the URS Provider, that is fine, but English must be the controlling language. | Support Recommendation concept with minor change | Remove "and Registrars" since the URS applies only to registries. | URS does not apply to Registrars. | The words "and Registrars" should be struck in their entirety as the URS does not apply to registrars. | Support Recommendation concept with minor change | We agree with the sentiment but continue to note that this is not an appropriate "URS Recommendation" as the URS does not apply to registrars. | Support Recommendation concept with minor change | See specific responses to following questions | Content should include what reasonable uses of marks are and a caution that not every use of a mark is presumptively inappropriate. | In coordination with representatives of relevant areas, including, e.g. digital rights advocacy groups. | URS Complainants. | If translations are provided, it must be clear that the English version prevails | Support Recommendation concept with minor change | This will increase the cost of the URS procedure because it will increase the time spent by examiners. The point of the URS was not to provide a "mini-UDRP" but rather to provide a fast and inexpensive alternative where only the most egregious issues could be brought and quickly dealt with. This recommendation indicates that goal was not achieved. It may be better to return to the principle that only the most significant issues are brought to URS. If this is not happening, it may indicate that rights holders are attempting to extend their rights beyond what is intended in intellectual property rights. | Significant change required | The URS should not allow the Inter-Registrar Transfer Policy to be bypassed. In addition, we recommend removal of "and Registrars" because the URS applies to registries. | No | Support Recommendation concept with minor change | This does not seem necessary as registrants using a privacy or proxy service have agreed to different venues. | Support Recommendation concept with minor change | See response to next question (Q6) | ICANN and URS Providers should together develop these materials; some elements are more appropriate for ICANN (e.g. links to forms) while others are better handled by Providers (e.g. reference materials explaining the Provider’s services) The English version must be authoritative (not translated versions). | The registry should know if the domain name is subject to other URS proceedings because it is the point of contact. | No, I wish to continue to the next section | Support Recommendation concept with minor change | It is unclear whether the third item in TMCH Rec #1 represents a change or not, it could be worded more clearly or a reference to the existing requirement provided. We strongly believe that this limitation within the relevant category must be maintained; trademark holders ought not be able to restrict the use of dictionary words beyond their realm. | No, I wish to continue to the next section | Support Recommendation as written | Do not support Recommendation | This is a very broad descriptor that is likely impossible to enforce. As such, we recommend against this. | Support Recommendation as written | Support Recommendation as written | The publication of Reserved Names is merely asking for people to attempt to subvert the list. | Support Recommendation as written | Support Recommendation as written | Do not support Recommendation | We disagree with this recommendation based on the faulty arguments made in reaching it. §6.2.4(i) and (iii) still have validity and it is not the registry making the determination but rather the registry's SDRP provider, often a third party with exactly the type of expertise the discussion of Sunrise Recommendation #7 notes that registries lack. Furthermore these are _very important reasons_ to invalidate an entry in the TMCH and removal of them strongly impacts innocent registrants who registered words that, at the time of registration, _were not yet trademarked_. Attempting to remove these clauses is a vast overreach by trademark interests and should be seen as such. To #1 specifically: These are legal issues that have no place at ICANN. If there is a trademark dispute, there are MANY fora to take such a dispute, including, e.g. WIPO, the EPO, and the USPT. To #2 specifically: There is no §6.2.4 of Module 5; there is similarly no (i) or (iii) in Module 5. To what does this recommendation refer? (We found the relevant info elsewhere but the info should be better organized and labelled.) | Do not support Recommendation | Trademarks are specifically designed to be for a limited purpose. Allowing marks holders to extend their reach beyond these limits is *not* within the purview of ICANN or this WG. | Yes | The WG's Sunrise Recommendation #8 would open the door for vast abuses by trademark holders to restrict the uses of their marks well beyond their lawful rights. Allowing marks holders to extend their reach beyond existing category limits is *not* within the purview of ICANN or this WG. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Confusing to users. | We support plain-language versions of the Claims Notice rather than legalese. | Support Recommendation as written | We note that the local language may not be one of the six UN languages and the registrar ought to be provided the opportunity to do their own translation with, perhaps, a note that the English version controls. | ||||||||||||||||||||||||||||||||||||||||
37 | 5/4/2020 13:58:12 | ALESSANDRA ROMEO | MARQUES EXTERNAL RELATIONS OFFICER | Yes | MARQUES EUROPEAN ASSOCIATION OF TRADE MARK OWNERS | No, I would like to continue to the next section | Support Recommendation as written | No | We do not support such an option. Determinations should include the full name of the Respondent - this serves the interests of justice. It should be left in the Examiner's discretion to exclude the Respondent's full name in exceptional circumstances (e.g., identity theft). [Any GDPR concerns (relevant only where the Respondent is a natural person) are addressed by reference to Art 6(1)b and/or Art 6(1)f GDPR.] | URS Providers would need to process and review requests to trigger such an option. This could also carry cost implications for URS Providers | Support Recommendation as written | N/A | Support Recommendation concept with minor change | URS Rec #3 misstates the URS Procedure. Para 4.2 states “The Notice of Complaint shall be in English and translated by the Provider into the predominant language used in the Registrant’s country or territory.” | Support Recommendation concept with minor change | Marques would contend that ICANN Org already has a responsibility to ensure compliance with the URS by Providers, Registries and Registrars, which should be the responsibility of the ICANN Compliance department. The current wording of Rec#4 might wrongly imply that this has not been the case to date. Nevertheless, the work of this working group and experiences of some of Marques members would indicate that there is a lack of clarity over how to raise such compliance concerns and over what action ICANN Compliance will take. Developing a working compliance mechanism is an absolute priority. | N/A | We believe ICANN should - via its contracts for future new gTLDs - incorporate such metrics and provide consequences for repeated breaches. We also support the publication of repeated breaches of performance against such metrics. Examples of such a metric would be delays in Registry/Registrar compliance with requests from URS Providers to lock/suspend domain names, or to reveal registration data (in the absence of a standardised system for reasonable, prompt access). Transparency of performance creates accountability and an incentive for contracted parties to proactively address issues in their compliance processes. | Support Recommendation as written | N/A | Support Recommendation as written | N/A | The content should provide high-level, non-legal guidance on the clear and convincing standard and be provided in a format of a checklist/set of FAQs - it is important however that this is intended as informational only and does not constrain an Examiner's discretion. | ICANN could coordinate the development of materials, which should be led by a collaboration of URS Providers, Examiners and other URS Practitioners and experts | ICANN should bear the cost | Yes | Support Recommendation concept with minor change | The URS is intended to be a quick and cost-effective measure for clear and convincing cases of cybersquatting. While it may be helpful to provide uniform guidance notes to Examiners on documenting their rationale, this should not unduly constrain Examiners or require a higher standard than is necessary. The overwhelming majority of decisions do document the “rationale in sufficient detail to explain how the decision was reached" | Support Recommendation as written | We support this Recommendation to the extent that it calls for addressing deficiencies in implementing the outcomes of a URS proceeding, provided that these changes remain true to the spirit and intent of the URS. | Yes | Support Recommendation concept with minor change | We support consistency in guidance across URS service providers. It may also be beneficial to undertake a review with consideration of the procedures followed under the UDRP, and as far as possible, achieve uniformity. The review should also take into consideration any cost implications of any changes in guidance to URS Providers and feasibility under existing cost structures. | Support Recommendation as written | N/A | ICANN should cover the costs incurred in developing such materials, and actively engage URS Providers to create high-level informational materials which can be uniformly agreed upon and published by each provider. | This should be agreed by the providers. For example, they may be able to agree to refer to specified online databases to check for open and active cases. | In the absence of any evidence to the contrary, we do not have any reason to believe that the late Response fees are unreasonable. | As we understand from the report, there have been no abusive Complaint findings. However, we have no reason to believe that existing penalties for Complainants are deficient. | Yes | There should also be penalties in place for Respondents - applicable to unreasonable conduct during URS proceedings, and penalties aimed at deterring repeated offenders. We note Individual Proposal #15 includes several possible measures in this regard. The implementation review team should be tasked with reviewing the feasibility of a range of possible measures intended to deter Respondents who are repeatedly subject to findings of cybersquatting. | No, I wish to continue to the next section | Do not support Recommendation | Marques supports maintaining the status quo on questions 1 and 3. With respect to question 2, exact match, Marques does not support maintaining the status quo, which is inadequate. We remain supportive of extending matching rules for Sunrise and Trademark Claims, to any variants which include the mark in its entirety. This would help to deter bad faith registrations containing the mark. A large number of UDRP and URS cases continue to consist of variants containing - rather than being limited just to exact matches of - marks recorded in the TMCH. | No, I wish to continue to the next section | Do not support Recommendation | Marques and its members strongly favour the expansion of matching beyond identical match only, for the reasons given in para 50 above. | Support Recommendation as written | We support this recommendation, as a means to address the most egregious behaviour by a minority of Registry Operators. | Do not support Recommendation | Brand owners currently have no protection from registry practices designating their brands as either Premium or Reserved Names, thereby undermining the intent and spirit of the Sunrise. If a challenge mechanism is not taken forward, then alternative solutions should be considered (which could possibly be achieved within the implementation scope of Recommendation #2). | Do not support Recommendation | As with Recommendation #3 above, further review should be undertaken to protect brand owners from being targeted by a minority of Registry Operators. This could also fall within the implementation scope of Recommendation #2. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The contractual requirement not to operate the TLD in a manner which circumvents the RPMs, a challenge process as referred to at Rec #3 and publication of reserved names (as referred to at Rec #4) would address. | Yes | We are aware of some reported problems with the TMCH's acceptance of proof of use, for trademark holders who use non-English scripts/languages. | No, I wish to continue to the next section | Support Recommendation as written | We support the principle of improving the Claims Notice to make it clearer to understand and more user-friendly, based on feedback regarding experience to date that some have found the Claims Notice difficult to understand. In doing so, we also agree that ICANN should seek input from resources with expertise in communicating complex issues relating to intellectual property to the general public. | Yes | We are aware that some brand owners have found receiving Claims Notices in respect of their own domain registrations confusing. Notices of registered names (NORNs) are also unhelpful since they include no information about the registrant (not even publicly-available WHOIS data), making the review of such NORNs more time consuming than it needs to be. | The proposals set out in Recommendation #1 should, in principle, address existing inadequacies in the Claims Notice. The NORN should also be reviewed. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||
38 | 5/4/2020 13:58:44 | Martin Sutton | Brand Registry Group, Inc. | No | No, I would like to continue to the next section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
39 | 5/4/2020 14:05:31 | Raymond Hackney | TLDinvestors.com | No | No, I would like to continue to the next section | Do not support Recommendation | Yes | At the option of the registrant, if and only if they are a natural person covered by applicable privacy legislation | Nothing worth mentioning | Support Recommendation concept with minor change | Significant change required | Significant change required | Not a registrar | Create contracts with explicit third party beneficiary clauses. | Support Recommendation as written | URS should be eliminated as policy. | Not a registry provider does not apply for me | Not a registry provider | Not a registry provider | Do not support Recommendation | There should be no need and eliminate the URS | EXCLUDE anyone associated with this working group make sure there is a an arms length third party | Those responsible for the whole mess the trademark holders and URS providers | Yes | Support Recommendation as written | Do not support Recommendation | No | Significant change required | Do not support Recommendation | Given many problems with the URS occur due to lack of any response from registrants, at least two-thirds of any money spentshould be devoted to educating registrants on defending complaints, rather than educating complainants (most of whom already have the knowledge about making complaints) | centralized database would solve the problem. | N/A | N/A | Yes but need to be capped | They should be stronger and imposed by an outside body | Yes | Trademark holders should only get one bite at the apple, if they are deemed abusive they should no longer be afforded the opportunity to use the URS | No, I wish to continue to the next section | Significant change required | the TMCH should be eliminated. Itsminor benefits have not outweighed its costs | No, I wish to continue to the next section | Significant change required | Sunrise should be eliminated entirely | Do not support Recommendation | Support Recommendation as written | Do not support Recommendation | Do not support Recommendation | Do not support Recommendation | Significant change required | Significant change required | If the sunrise procedures are retained (a separate proposal calls for its elimination), then all details of any trademark relied uponto secure a sunrise registration shall be made public, in order to permit utilization of the SDRP. Details should include allinformation provided to the TMCH (e.g. country, registration number, TM registration date, TM owner, goods and services, etc.).Without limiting an implementation review team, such publication might be implemented by making it public at the source | No | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | No, I wish to continue to the next section | Significant change required | No | Do not support Recommendation | ||||||||||||||||||||||||
40 | 5/4/2020 15:35:37 | Jeffrey Reberry | Registrar | Yes | NameBright.com is an ICANN accredited domain registrar | No, I would like to continue to the next section | Do not support Recommendation | We support simple updating of the contact information on the domain name. But we do not support making any updates to the body of the Complaint or any amendments (changes) to the Complaint. Recommendation #1 is unclear as to what is being “updated.”. Updating the body (the actual contents of the complaint) may provide an unfair advantage to any Complainant. Amending any URS complaint (other than contact info) after the initial filing will add more complexity. This was not the intent of URS. Complaint should not be allowed to update or amend the Complaint to gain an advantage in a URS proceeding. As written, Recommendation #1 is not related to the pattern of bad faith - only updating the “contact” info - correct? One commenter has suggested the “wording of this recommendation is in no way tied to this goal” and the “rationale of the working group was to allow trademark owners to identify registrants who have engaged in a pattern of bad faith registrations.” It seems the wording may not appropriately reflect the goal. Why not? Are we only talking about changing the contact info (Whois) and Registrant contact info or actualy allowing the Complaint to update the body text? | No | We support this if only the Complaint will be updated with the contact information - but not any body or actual content of the Complaint. | Do not support Recommendation | This recommendation is incredibly vague and leaves out details about settlements, registrar requirements, and how things will be regulated. | Significant change required | We should not just have “Providers, Practitioners, Panelists” develop the materials or guidelines. Registrants are missing. We should be inclusive of all stakeholders and not disfavor registrants. Registrants and their rights must have a voice in this process as well. | It is imperative that the educational materials be developed by ALL relevant parties, not just those with upper level administrative stake in these matters and the IP interest. Registrars and registrants must be included for this to be fully inclusive and written to address all parties involved and affected. Right now, as proposed, this is only limited to “Providers, Practitioners, Panelists” - but registrants need to be involved as well. The whole community should be involved and all parties’ rights must be considered. | Do not support Recommendation | URS was expressly designed to apply only to clear-cut cases. By changing the technical requirements and to allow extensions or transfers of domains, this is adding more complexity to a very simple policy. Once you start introducing extensions and transfers - we are morphing URS into UDRP - and this was not the intent of URS. The URS was designed as a complement to rather than a substitute for the UDRP. Once the Complainant has the right to obtain the domain through this process - the whole thing starts looking very similar to UDRP. This recommendation assists bad faith filers to forum shop to try to find the best way to file a bad-faith complaint and creates a disadvantage for domain registrants. Under no circumstance should a domain be transferred under URS, a domain should only be suspended as was the intent of the creation of the URS, the Uniform Rapid Suspension System. If a complainant wants a domain transferred to them, then the proper procedure would be to file a UDRP. These need to be kept separate and their intent as created by ICANN should not be modified as it greatly diminishes the integrity of the URS. Settlements should absolutely be considered - as it is the most favorable option - where two opposing parties agree to move forward - and everyone is happy. | These FAQs should be developed by ICANN and the community. This should not be the responsibility of only certain groups. Development of these should be a joint effort by all involved stakeholders, and must include registrants. | No, I wish to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
41 | 5/4/2020 15:43:52 | Brian Beckham | WIPO | Yes | Submitted for WIPO Arbitration and Mediation Center | Support Recommendation concept with minor change | It does not make sense to eliminate the provision to include "...information known to Complainant regarding how to contact Respondent or any representative of Respondent, including [ ] based on pre-complaint dealings". As to the option to amend pleadings, while this makes sense on its own terms it should be weighed against the intended rapidity of the URS. | No | If this is considered, examiners should specifically weigh any request against 1.2.6.3.b regarding a pattern of conduct. | Support Recommendation as written | Support Recommendation concept with minor change | Rather than the predominant language, which may be difficult to ascertain, it should be the language of the registration agreement. | Do not support Recommendation | This is duplicative/unnecessary as ICANN already accredits (and can by implication, de-accredit) providers. Moreover, it is not clear that there is (widespread) evidence of "non-compliance". If such metrics are contemplated, there should be metrics for assessing registry and registrar compliance with obligations to lock domain names and implement decisions. | Support Recommendation as written | Agreed -- we have seen numerous problems with registrars not providing accurate and up to date contact information in UDRP cases over the years. | Do not support Recommendation | Disagree -- if examiners are not capable of understanding this fundamental legal concept, they should not be qualified to be examiners. There are two distinct issues here: one is understanding a legal concept, and the other is subjective application of legal principles to the facts and circumstances to individual cases; for the latter, a minimal "checklist" or "template" of facts to be included in a determination should already be included by *qualified* examiners. This also gets to a core issue of whether the URS itself could be managed in a "checkbox" fashion given the intended rapid nature and suspension remedy. | Support Recommendation concept with minor change | As mentioned in No. 6, a minimal "checklist" or "template" of facts to be included in a determination should already be included by *qualified* examiners. | Support Recommendation concept with minor change | Agree if strictly limited to a change of registrar (and not used to circumvent the remedy). | Support Recommendation concept with minor change | It should be possible to ascertain the language of the registration agreement from the registrar. From there, principles articulated in section 4.5 of the WIPO Overview should be applied (www.wipo.int/amc/en/domains/search/overview3.0/#item45). | Significant change required | Disagree as to No. 1; agree as to Nos. 2 and 3 (both of which should be up to the provider). | The providers' websites -- on which determinations are required to be published -- should be sufficient here. | Without opining on the fees, the concept appears to seek to reasonably accommodate a provider burden in managing late filings. | Any penalty for an abusive complaint should be accompanied by a penalty for repeat abusive registrations. | No opinion | No opinion | Support Recommendation as written | No opinion | (Presumably this is intended to refer to a different type of challenge mechanism than the already existing SDRP.) | Do not support Recommendation | Arguably publishing such list would be in the interests of all stakeholders; moreover, it would assist above recommendation No. 2. | No opinion | If adopted by ICANN, any such process should make clear that it has no relation to or impact on the underlying national or regional trademark registrations. | Support Recommendation as written | Here, ICANN or the IRT on this RPM WG should bear in mind TMCH recommendation No. 2. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
42 | 5/4/2020 15:51:53 | Megan Long | Corporate Counsel HugeDomains.com | No | No, I would like to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
43 | 5/4/2020 16:12:37 | Susan Payne | IPC Secretary | Yes | IPC | No, I would like to continue to the next section | No, I wish to continue to the next section | No, I wish to continue to the next section | Support Recommendation as written | As IPC participants have made clear throughout the discussion in the WG, we consider that limiting to exact matches only is inadequate to protect brand owner interests and avoid consumer deception. We are prepared to live with this in the spirit of compromise. | Support Recommendation concept with minor change | We strongly support this recommendation, and must ensure it is implemented in an appropriately robust and enforceable manner. See also our response on the TM-PDDRP Recommendation #1 | Do not support Recommendation | We would support a uniform challenge mechanism to challenge a registry operator’s designation of a name matching a TMCH-recorded mark as a premium or reserved name, and thereby unreasonably inhibiting the relevant brand owner from securing the name either during Sunrise or general availability. In our experience, registry operators will consider changing such designations on an ad hoc basis in response to direct, individual outreach from the brand owner, but there is no uniformity, transparency, or accountability around these informal communication channels, which would be improved through a single uniform mechanism applicable to all registries. | Support Recommendation concept with minor change | It is important to note that disclosure of a reserved names list (or part of the list) may ultimately prove necessary, for example in the context of a dispute resolutioon/challenge process, in order to ensure that registry operators are not using them to circumvent RPMs, for example, by reserving all names in the TMCH or targeting specific trademarks. Due to the expressed concerns of some Working Group members regarding the confidentiality of registries' business plans in relation to the publication of all Reserved Names in the new gTLD, we propose a compromise solution to address the need for compliance, transparency, uniformity, and operational effectiveness of the Sunrise RPM. Specifically, we propose that second-level strings reserved by the registry operator prior to, and during the Sunrise Period, shall be reflected in some form as reserved in the Registry Data Directory Services system. This solution will enable trademark owners who are prevented from defensively registering domain names during Sunrise because the New gTLD Registry has reserved the domain name to perform a Look-Up query to identify the domain name as reserved by the registry, without interfering with the ability of the registry operator to maintain a confidential list of all reserved strings. | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | Although we support the concept behind this recommendation, paragraph 3 should be amended: rather than a RO immediately deleting a domain name following a finding by the TMCH that it was based on an invalid TMCH record, the name ought to be suspended for a period in order to allow for the exhaustion of any time period to challenge that finding. | Support Recommendation as written | This was discussed extensively by the WG, and for all the reasons put forward during those discussions we do not support limiting the scope of sunrise registration in this was | he unintended effects of the Sunrise Period that we have identified relate to the abuses of the system by some registry operators ( see Sunrise Q 2 below). Sunrise recommendation #2 would play an important oart in remedying this, as would a the adoption of a challenge mechanism such as is referred to at Sunrise recommendation #3. It is also essential that ICANN Complance adopts a robust and proactive approach to compliance with the Sunrise, which is mandatory for the Contracted Parties. The implementation of Sunrise by registry operators in any subsequent rounds of new gTLDs must conform to the spirit and letter of the RPM, including clear triggering mechanisms and timelines to provide ICANN Compliance the ability to prevent Sunrise abuses which circumvent, discourage, and/or defeat the purpose and use of the RPM. | Yes | We have identified multiple systematic abuses of the Sunrise by new gTLD registries. In many cases, the abuse of Sunrise has the net effect of reducing the efficacy of the RPM, leading to increased levels of domain registration abuse, consumer confusion, and a reduction in consumer trust in the DNS. Additionally, Sunrise abuse also imposes significant external costs on right holders to the detriment of ICANN's New gTLD Program. Some primary forms of Sunrise abuse include: (1) the withholding, reservation or self-allocation of trademark-corresponding domains with the intent of circumventing or discouraging the use of the Sunrise Period; and (2) discriminatory pricing practices designed to leverage the need for defensive Sunrise registrations, including the excessive and exorbitant pricing of Sunrise domains with the intent of targeting trademark owners either specifically, or as a general class of registrants. The following non-exhaustive list of resources provide documentation of Sunrise abuse: 1) ICANN's Competition, Consumer Trust, and Consumer Choice Review Team Final Report, see page 131 of the report. 2) The Panel Report of ICANN's Public Interest Commitment Dispute Resolution Procedure (PICDRP), finding that the .feedback registry engaged in Sunrise abuse. 3) Correspondence from the Federal Trade Commission (FTC) outlining the FTC's assessment of Sunrise abuse in the .sucks new gTLD, available at: https://www.icann.org/en/system/files/correspondence/ramirez-to-jeffrey-27may15-en.pdf. Also see related 2015 communications from the IPC, BC, and ICANN Org on the Correspondence page. The FTC letter expresses concern on the manner the .sucks registry operated its Sunrise and that "it may well very well be that stronger rights protection mechanisms or amendments to the registry agreement are needed to ensure IP rights holders are adequately protected." | No, I wish to continue to the next section | Support Recommendation concept with minor change | The IPC does not believe there is evidence that there have been "unintended effects of deterring good-faith domain name applications". This reference in the first paragraph should therefore be amended to refer to "decreasing any possibility of deterring good faith registrations". IPC would revise the recommendation to more specifically note that either ICANN Org or an IRT tasked with implementing these proposals should solicit and consider input from resources that are expert in communicating complex issues relating to intellectual property to general public as part of its consideration of revision of the Claims notice language. In this regard, IPC believes that it is important to note that the Claims notice was co-written during the implementation phase for the 2012 Round. While it is therefore appropriate, at this point, to review and seek to improve the Claims notice to address any lessons learned to date, any future redraft will undoubtedly still result in a notice which is the result of compromise. | Members of the Intellectual Property Constituency who are members of the GNSO Rights Protection Mechanism Review PDP did work with other members of the PDP to draft possible revisions to the standard American Trademark Claims Notice. However, they stopped this effort when it became clear that making such revisions would require more time and close focus in that was possible in the PDP, and would be better handled by the Implementation Review Team implementing the actions recommended by the PDP or a team formed for that goal. At the same time, however, that draft prepared during the PDP discussions that might be used as a starting point for developing a more clear, understandable, and comprehensive Trademark Claims Notice than is currently being used. | Support Recommendation concept with minor change | IPC believes that Trademark Claims Notices can only effectively fulfill their intended function of notifying domain name applicants of potential conflicts with trademarks if they are clear and are understood. We therefore believe that reasonable steps should be taken to ensure that applicants understand the notice. We believe requiring that notices be provided in the languages of domain name registration agreements is a reasonable and necessary step to ensure that they are understood and enable applicants to knowledgeably determine the action they wish to take in response to the notice. The final bullet should be amended "The Claims Notice MUSTinclude..." | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
44 | 5/4/2020 16:25:19 | Wikimedia/Yale Law School Initiative on Intermediaries and Information | Yale Law School - Information Society Project | No | No, I would like to continue to the next section | Do not support Recommendation | There are concerns that this process may be used to backdoor privacy protections for registrants, by allowing complainants to insert redacted data into the complaint (which will, ultimately, be made public). Given that complainants are already permitted to file Doe complaints, the necessity of these amendments is unclear. | Yes | This should be the default - relying on respondents to opt in to anonymity protections is problematic given low response rates of URS cases. | Support Recommendation as written | This seems like a no-brainer, given the low response rates. We should be doing as much as possible to ensure that respondents have notification that a process against them is ongoing. | Support Recommendation as written | Again - this is clearly necessary in light of low response rates, and would seem to be the bare minimum that procedural fairness requires. | Support Recommendation as written | Over the course of the working group's deliberations, there were serious questions raised regarding compliance to even the minimum procedural protections laid out in the rules. This is clearly problematic, and supports the need for monitoring and oversight. | Support Recommendation as written | This seems to be common sense, with no particular harm to it. | Support Recommendation as written | Uniformity is important for a proper standard of review. This is just better practice for any adjudicative process. | It would be good to drill down more deeply into what the standard of proof is, with illustrative examples from successful and unsuccessful claims. | Obviously the Examiners would be important to consult, as well as attorney's (or civil society stakeholders) who work both sides of these issues. It would be important to incorporate a balance of perspectives, to ensure that the final product is fairly calibrated. | Providers, supplemented by volunteer contributions from ICANN's constituencies. | Yes | Support Recommendation as written | Again - this is basic procedural fairness. If the rationale isn't documented - how do we know the examiners are even reading the materials, as opposed to just rubber stamping them through? This is not to accuse anyone of a lack of diligence - but the legitimacy of these processes derives from a demonstrable belief that the questions have been fairly considered. Absent documentation, it's impossible to see the process as fair. | No opinion | No opinion | Support Recommendation as written | Yes - the correct language can be tricky to ascertain in different parts of the world. Supporting that determination would seem to be a good step. | Support Recommendation as written | ICANN, in consultation with the providers, and its constituencies as reflective of the different stakeholders in this process. | Some folks have raised the point that a disproportionate amount of late responses come from the U.S., which may suggest that the fees are having a disproportionate impact on people from the global south. It would be good to consider a sliding scale, which takes into account differences between the strengths of different currencies. | This is very strange framing. On the one hand - it's certainly possible for complainants to abuse the URS process (for example, by launching frivolous claims, or attempting to time a complaint for when they know a person is going to be offline). Though I am not aware of this being a common phenomenon. The question of what counts as an "abuse" by a respondent is more difficult. It doesn't seem possible for the "process" to be abused by respondents given the narrow procedural scope of the URS - so I assume this is meant to refer to the broader phenomenon of abusive registrations. If so - the question is misleading. I would be opposed to any measures to beef up penalties for respondents who lose under the URS - that's hugely problematic given the high default rates, and the speedy nature of the process. If we're going to attach greater weight to the outcome of proceedings, like barring future registrations as the IPC folks have proposed, then we would need to boost the procedure and available defences significantly, which would defeat the purpose of the URS. | No | No, I wish to continue to the next section | Significant change required | The expansion of trademark protections to apply without regard to categories of goods or services is a total anathema to how trademark law works. We know for a fact that the TMCH has been used abusively, to register a number of generic words. Option 3, which limits dictionary terms to the categories of goods and services which the trademark protects, is an attempt to bring the TMCH system back into the realm of how IP protections actually apply - it's frankly ludicrous that no such system of classification already exists for the TMCH, given the centrality of such classes to the trademark registration system. | No, I wish to continue to the next section | Support Recommendation as written | Given that the existing protections extend far beyond the ambit of trademark law protections, I do not support extending it further. | Do not support Recommendation | This recommendation raises a lot of questions. What is the practical enforcement mechanism for this? What is a "reasonable use" of the mechanism (given that typical uses extend far beyond the ambit of trademark law)? In the absence of any documented cases of abusive conduct by registries, or any fully thought out way of implementing this, it looks to me like that this is just being pushed forward as a way of browbeating registries into lowering costs for sunrise registrations. | No opinion | No opinion | Support Recommendation as written | In the absence of any evidence that the current period is insufficient, or that folks are missing out, there doesn't seem to be any reason to extend it. | Do not support Recommendation | As currently applied, the Sunrise grants trademark protections that go vastly beyond the scope of trademark law (see https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3528237). As a consequence, and absent major reforms to bring it back into line with legal standards, it should be scrapped. | Support Recommendation as written | The TMCH dispute resolution procedure is insufficient to correct the problem of bad-faith registrations in the database, but is better than nothing. | Do not support Recommendation | This recommendation is essentially a decision to continue awarding protections to trademark registrants which have no basis in law, in any country in the world. | The documented number of abusive registrations is clearly an unintended impact. The solution to this starts with transparency for the TMCH, followed by an audit to remove improper registrations, followed by tighter ruled on the registration and use of generic or dictionary words. | Yes | See Andrew Allemann, How Common Words Like Pizza, Money, and Shopping Ended Up in the Trademark Clearinghouse for New TLDs, DOMAIN NAME WIRE (Feb. 10, 2014), https://domainnamewire.com/2014/02/10/how-common-words-like-pizza-money-and- shopping-ended-up-in-the-trademark-clearinghouse-for-new-tlds/ [https://perma.cc/V5RZ -LZJP]. | No, I wish to continue to the next section | Support Recommendation as written | Yes | The working group discussed clarifying this, to make it easier to understand what is and is not being communicated in non-legal terms. This seems like a good idea. | Support Recommendation as written | |||||||||||||||||||||||||||||||||||||||||
45 | 5/4/2020 16:29:07 | Karen Lentz | ICANN org | Yes | ICANN org | No, I would like to continue to the next section | The System for Standardized Access/Disclosure to non-public gTLD registration data ("SSAD") model described in the Initial Report of the Phase 2 Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team proposes two (2) business days as contracted party response targets for requests related to administrative proceedings (such as response to a URS filing). ICANN org suggests that the RPM WG consider if this proposal regarding a SSAD model may impact the ability of URS Providers to provide timely updated registration data as well as the overall timeline for a URS proceeding. | ICANN org uses a Memorandum of Understanding (MoU) to govern the relationship with each of the selected URS Providers. Each of the URS Providers agrees to provide URS services in accordance with the URS Rules and Procedure as found in the Applicant Guidebook, as well as to develop and maintain provider-specific supplemental rules and procedures. As such, ICANN org has the ability to investigate any complaints against URS Providers and has worked with providers on a case-by-case basis to remedy any issues related to the Rules or the Procedure. ICANN org’s Contractual Compliance (“ICANN Compliance”) function enforces the requirements set forth in ICANN's agreements with contracted parties (registries and registrars). ICANN Compliance also provides Internet users with a URS Complaint Form (https://forms.icann.org/en/resources/compliance/registries/urs/form) that allows users to submit a complaint to ICANN regarding enforcement of a URS decision. However, investigating complaints about Provider conduct or performance is a different function and falls outside the scope of the ICANN Compliance process. Implementing this Recommendation will entail establishing a new and separate complaints mechanism. Given that MoUs with URS Providers are already in place, does the WG envision that ICANN org should expand upon the terms of existing MoUs to specify performance measurements and reporting requirements expected from URS Providers? With regard to developing metrics to assist in evaluating the performance of registries and registrars in the URS process, is it envisioned that current agreements with contracted parties should be amended to include performance levels specific to the URS? | ICANN org notes that registries, registrars, and URS Providers are not currently subject to any contractual requirements related to keeping their contact details up to date. Per the Registrar Information Specification of the 2013 RAA, registrars are required to provide and maintain general contact information, however, registrars have limited requirements in terms of keeping specific contact details in connection with this recommendation up to date. While ICANN org supports the current preliminary recommendation and we do not foresee any operational challenges with implementation and keeping ICANN org’s contact details up to date, it would be helpful to understand whether the intention of this recommendation is that new requirements be included in the agreements with the relevant parties and as such, these obligations would then be made enforceable. In addition, as this recommendation is aimed at multiple parties, keeping each other’s contact details up to date may pose some challenges as ICANN org has faced some difficulties in obtaining accurate and up-to-date contact data from the contracted parties. | ICANN org notes that the RPM Requirements, specified in Section 1 of Specification 7 to the Registry Agreement and that each Registry Operator must comply with, state that the “Registry Operator has discretion to implement its TLD startup phases in accordance with its own business and operational models, so long as the minimum requirements contained in, and the objectives of, these TMCH Requirements are met.” Specification 7 of the Registry Agreement specifies that “Registry Operator shall implement and adhere to the rights protection mechanisms (“RPMs”) specified in this Specification. In addition to such RPMs, Registry Operator may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Registry Operator will include all RPMs required by this Specification 7 and any additional RPMs developed and implemented by Registry Operator in the Registry-Registrar Agreement entered into by ICANN-accredited registrars authorized to register names in the TLD. Registry Operator shall implement in accordance with requirements set forth therein each of the mandatory RPMs set forth in the Trademark Clearinghouse.” ICANN org understands that the Working Group acknowledges that determining the price of a given domain name remains at the discretion of the operating registry. ICANN org’s compliance role and scope is to ensure that ICANN 's contracted parties fulfill their contractual requirements, by enforcing the terms and conditions of the base gTLD Registry Agreement. While ICANN org does not foresee any issues with adding such a provision as described in the current preliminary recommendation to the Registry Agreement for future new gTLDs, there may be challenges in enforcing the requirement as written. For clarity, it will be helpful to understand which if any specific registry behaviors are expected to trigger enforcement action by ICANN org. | ICANN org interprets the absence of wide support for a change to the status quo, as a recommendation to maintain the current requirements as applied to the gTLDs delegated under the 2012 New gTLD Program round. While new gTLD registries are required to offer a Sunrise period, ICANN org notes that Specification 13 provides qualified .Brand TLDs certain modifications to the New gTLD Registry Agreement. To avoid confusion in implementation, ICANN org suggests clarifying that the mandatory Sunrise period applies to TLDs that do not have Specification 13 incorporated into the New gTLD Registry Agreement. | ICANN org notes that the first item listed in this preliminary recommendation appears to have a different goal than points 2 and 3. The TMCH dispute resolution procedure mentioned in point 1 serves a different purpose than the Sunrise Dispute Resolution Policy (“SDRP”) mentioned in point 2. The TMCH dispute resolution procedure is used for challenging a decision of the Verification Provider that a Trademark Record was valid on the grounds that the Trademark Record has been incorrectly verified. The SDRP, in comparison, is to be used for challenges to Sunrise Registrations related to a Registry Operator’s allocation and registration policies, including on the grounds that the domain name that was registered does not match the trademark record on which the Sunrise-eligible rights holder based its Sunrise registration. All Registry Operators with Sunrise periods are required to develop a SDRP mechanism in accordance with Section 2.3.5 of the RPM Requirements. The third item listed in this preliminary recommendation appears to combine points 1 and 2. ICANN org suggests that the WG consider clarifying this recommendation to distinguish between the two procedures. On point 2, ICANN org notes that the text of the current requirement in the Registry Agreement that each Registry Operator must provide a mechanism to resolve disputes regarding its Sunrise registrations was adopted only after extensive consultation with the ICANN community. It was developed based on extensive community feedback and public comments from a variety of stakeholders, including negotiations between ICANN and registry applicants. In light of this, ICANN org suggests that the WG seek specific input from contracted parties concerning its recommendation to remove grounds (i) and (iii) in Section 6.2.4 of the current TMCH Model of Module 5 of the AGB. ICANN org understands, further, that the effect of this recommendation is that, if grounds (i) and (iii) are eliminated, the only grounds remaining for challenging Sunrise Registrations via the SDRP will be for domain name registrations that do not match a trademark record on which a domain name registrant based its Sunrise registration. In addition, ICANN org notes that the Trademark Clearinghouse Validation Framework Agreement includes Service Level Agreements on dispute resolution services that are provided to users by the TMCH Validation Service Provider as agreed upon in the contract. These Service Level Agreements provide metrics to measure performance of the TMCH Validation Function, such as time to resolution of a dispute from a Trademark Holder, Trademark Agent, or third party contesting result of validation or proof of use, as well as time to resolution of a dispute from a third party based on new information not previously considered. | Trademark Claims Recommendation #1 advises ICANN org to work with the IRT to revise the language of the Trademark Claims Notice to maintain brevity and also to provide additional relevant information, as well as to consider input from external resources. While ICANN org understands the objective with this recommendation, ICANN org notes that balancing these potentially conflicting goals could be problematic in practice; for example, maintaining brevity while adding more text and information. Obtaining input from multiple external sources for this one recommendation could add further complexity to what might otherwise be a relatively straightforward implementation step. | ICANN org believes that this recommendation is feasible to implement; however, providing the Trademark Claims Notice in English, which is a service already provided by the TMDB, as well as translating it into all of the languages of the registration agreement, may be a cost or operational consideration for registrars. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
46 | 5/4/2020 16:29:59 | Samantha Demetriou, RySG Vice Chair Policy | Registries Stakeholder Group (RySG) | Yes | Joint comment submitted on behalf of the CPH ( RySG and RrSG ) | No, I would like to continue to the next section | Support Recommendation as written | Yes | We wish to highlight that registries who disclose registrant data to a URS provider are still controllers of the data. We would suggest that rather than a default publish or not publish updated registrant data, the URS examiner must consider the question of whether to publish updated registrant data in line with applicable laws. | We assume that all involved will abide by applicable laws, including GDPR and that nothing in the policy should be construable otherwise. The RySG is of the opinion that the transfer by URS Provider of PII to the Complainant is a justifiable purpose in the context of a URS Dispute Resolution. If it is published based on registrant consent then the WG should clarify how that would be done/managed in context of applicable law. The RySG notes that consent does not transfer under GDPR. Therefore, if PII is published with a URS Determination on the basis of Registrant/Respondent consent, this consent would not transfer to registries and registrars. | Support Recommendation as written | Support Recommendation concept with minor change | Comment of clarification: The language is not the predominant language of *respondent* but rather the predominant language used in the registrant’s country. | Do not support Recommendation | Given the related questions, this recommendation appears premature and any recommendation along this line should await answers to the question. Nonetheless, we believe that compliance steps should be limited to the extent permitted by applicable law/regulation. The CPH also believes it is not in the purview of a PDP working group to direct ICANN’s compliance actions. ICANN Org has a robust compliance department and established practices for enforcing registry and registrar compliance with policies. The PDP WG should focus instead on developing clear and well-formed policies. | Support Recommendation as written | It would be ideal for ICANN to maintain a single source of accurate and up-to-date contact information that registries, registrars and URS providers can check against. | Yes | Yes | Certain emails have been signed with self-issued certificates, which has led to questions about the legitimacy of those emails among some registry operators. | Support Recommendation as written | The WG should consider consolidating this with Recommendation #10 and ensure a standard disclosure template, supplemented by variations in URS provider supplemental rules and fees. | We believe educational materials should be kept brief and high-level in order to be maximally usable. These educational materials must avoid even the appearance of providing legal advice. | ICANN should develop these materials. | ICANN should bear the cost of developing these materials. | The CPH supports translating these materials into all of the official ICANN languages, as well as any language that comprises more than 5% of the total number of URS complaints filed, such as German. | Support Recommendation as written | Do not support Recommendation | The CPH found URS Recommendation #8 somewhat confusing. We do support the idea of having the IRT consider reviewing implementation issues with respect to the Registry Requirement 10 in the “URS High Level Technical Requirements for Registries and Registrars” and amending the Registry Requirement 10, if needed. We recommend that the IRT consider the issues noted by The Providers Sub Team and we also encourage the WG to catalogue other issues in this regard, if any, in the Final Report. For instance, there may well be issues in cases where the URS parties settle their claim or where a URS winner is unable or unwilling to pay for a further 1 year renewal. These should be catalogued/clarified in the FR. | Yes | Support Recommendation concept with minor change | The CPH proposes the following implementation guidance: Guidance be developed to assist URS providers determine what language should be used during a URS proceeding and when issuing a Determination. Such guidance should consider the following factors: -> Language used by the registry and/or predominant language of the country of the registry; -> Language used by the registrar and/or predominant language of the country of the registrar; -> Whether the domain was registered through a privacy or proxy service, and/or the location of the privacy or proxy service; -> Any other pertinent information about the registrant, which may be limited depending applicable laws, particularly privacy laws. | Support Recommendation concept with minor change | This is a requirement for URS Providers and therefore the effort and cost to develop these materials should be borne by them. If ICANN wants to (and they already do some of this) provide an informational page on URS with FAQs and links to providers then they are able to do that within their current budget. Providers would then bear the requirement to translate the FAQs and information into whatever languages they choose. | We support penalties for Respondents being introduced, given that Complainants already face penalties for misuse. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | The CPH supports the recommendation in principle, noting that implementing RPMs is required through Specification 7 of the base Registry Agreement. This means that ICANN Compliance has a role in ensuring that RPMs are not circumvented and that the use of Sunrise is not restricted. However, the phrasing "effect of circumventing RPMs or restricting use of Sunrise” is much too vague to be implemented. If the WG plans to pursue this recommendation, the CPH believes that the language must more precisely set forth what conduct may be curbed. To that end, the WG might consider creating a non-exhaustive list of conduct that clearly demonstrates such prohibited conduct while being drafted in a tight enough manner as to make such conduct reasonably certain. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Implementation Guidance: To the extent that this recommendation is supported by consensus of the RPM Working Group, the actual amendments to the Applicant Guidebook should be taken up by the same Implementation Review Team that is set up to implement the recommendations and implementation guidance proposed by the Subsequent Procedures PDP (and approved by the GNSO Council and ICANN Board). | Support Recommendation as written | Not sure | We find it difficult to answer these questions. It is not clear if they ask about Trade Mark owners abusing the TMCH or other parties violating the rules of the Sunrise Period. | Specification 9 exempt Registry Operators, including Registry Operators with Specification 13 in their Registry Agreements, should be exempt from running a Sunrise period. Specification 9 exempt gTLDs are not permitted by contract to allow third party registrations - including Sunrise registrations. The inability for third parties to register domains in a Specification 9 exempt gTLD provides complete rights protection on its face in these gTLDs and as such a Sunrise period should not be required. | No, I wish to continue to the next section | Support Recommendation as written | We support the recommendation but note the importance of providing very clear guidelines, intent, and scope for anything left to the IRT to develop. | |||||||||||||||||||||||||||||||||||||||||||||||||
47 | 5/4/2020 16:56:44 | Susan Payne | IPC Secretary | Yes | IPC | No, I would like to continue to the next section | Support Recommendation as written | No | The IPC does not support the notion that there should be an option for a determination to be published without the names of the parties involved. Not publishing the name of a Respondent involved in a proceeding creates uncertainty and allows for a bad faith actors to shield their prior activities. The decisions in these proceedings are meant to be publicly available and searchable, and the privacy concerns are not greater in these types of administrative proceedings than those in court actions which typically publish the names of the parties involved in a matter. | Support Recommendation concept with minor change | Support the recommendation as written, with the caveat that if the registry or registrar do not timely provide, or fail to provide, within the designated period of time, the underlying information regarding the Respondent, the URS provider shall then send the notice by the prescribed manner to the Respondent at the contact information that is then available. | Significant change required | The IPC supports the intent of this recommendation, requiring URS Providers quickly and effectively provide registrant with notification of a Complaint, in clear and understandable language. Compliance with these notice requirements bolsters the efficiency and integrity of the URS mechanism. The IPC believes there would be benefit in more closely aligning the relevant language with that of the UDRP, where the reference is to the language of the registration agreement. For the avoidance of doubt, if recommendation #3 is retained then URS Procedure 4.2 provides that "The Notice of Complaint shall be in English and translated by the Provider into the predominant language used in the Registrant’s country or territory" rather than "the prodominent language of the respondent", and so recommendation #3 should be amended accordingly to accurately reference the existing procedure. | Support Recommendation concept with minor change | The IPC supports the intent of this recommendation, which aims to ensure that there is a designated compliance mechanism to enforce the rules and requirements of the URS process. The IPC agrees that is important for interested parties to be able to raise issues with ICANN Compliance and have an effective mechanism for addressing non-compliance issues. The IPC notes that interested parties can already reach out to ICANN Compliance regarding contracted parties and dispute providers, and we believe that Compliance should be equally applicable for URS, just as it should be for UDRP. However, a number of the recommendations of this WG are essentially to the effect that the URS procedure and rules should be followed, indicating that the community considers existing compliance mechanisms to be inadequate or are not being followed. Additionally, the IPC would like to see a specific mechanism in place whereby failure to comply with reveal requests from a party with a legitimate interest should be an automatic trigger allowing for ICANN Compliance to act. The IPC further believes that such failures to respond to reveal requests occur too frequently, and undermine the effectiveness of dispute resolution mechanisms. | The IPC believes the question of compliance issues in URS processes parallel issues in the UDRP. Both the URS and UDRP are reliant on responses by registrars to reveal requests and access to accurate registrant data in order for the RPM to be effective. So even if the number of compliance issues raised directly in URS processes to registries and registrars may be small, the need for consistent and effective relief exists. Registrar members of the IPC have encountered losing registrars who have failed to transfer a name as ordered by a UDRP panel, subsequently allowed it to lapse, thereby resulting in it being registered again and lost to the winning brand owner. In such circumstances, ICANN Compliance has appeared unwilling to take any action or impose any sanction. See also our comments on URS Recommendation #8 | The IPC would suggest that a critically important step towards enhanced compliance would be to ensure reasonable access to accurate, current registrant data upon legitimate request. However, the IPC recognizes that the EPDP is not proceeding in a manner that will allow for this (i.e., not dealing with accuracy). Unfortunately, the IPC believes the efficiency and usefulness of the URS is diminished without such guarantees of access to accurate and current registrant data. | Support Recommendation as written | Support Recommendation as written | A high standard of proof is the fundamental characteristic of the URS. By requiring ‘clear and convincing’ evidence, there are no disputed questions of material fact. Clear-cut trademark infringement provides the basis for expedited remediation. It is, therefore, critically important that the standard is applied consistently, even by multiple URS Providers who pull Panelists from various countries where evidentiary standards may vary. The IPC believes that uniform application of the ‘clear and convincing’ standard for URS filings results in consistent outcomes, shared understanding by all the parties, a reduction in frivolous or malformed filings, and provides the basis for future performance evaluation. Such uniformity could also reduce undesirable activities like forum-shopping and complaints against Panelists. Therefore, the IPC supports the formation of a small group of experienced URS Practitioners (both Complainant & Respondent), Providers, and subject matter experts to draft educational materials elucidating the ‘clear and convincing’ standard in a simple, easily understandable format such as a checklist or guide. ICANN's participation to facilitate production of the materials, but no to opine on the legal standard, would be desirable. It should be noted that Panelists are vetted and selected because of their expertise in these matters. The IPC believes that the educational material should not constrain their ability to make fair and sound decisions relevant to the specifics of each dispute. Rather the IPC supports a simple document that can facilitate a consistent interpretation of the standard. Lastly, it is the opinion of the IPC that this proposal has the support of the community. Although (2) of (3) URS Providers offered a tepid response when surveyed, the remaining Provider supported the development of such guidance and a plurality of Practitioners representing both Complainants & Respondents agreed that more guidance would be helpful. | As Panelists are experts selected for their in-depth knowledge of the subject matter, the content should be a concise & specific description of the standard as applied to the URS, which should be provided in a simple format such as a checklist or worksheet. To be clear, these materials are not legal advice, rather they are intended to give guidance for panelists to bear in mind when they are making their own expert determination, based on the facts of each case before them. | Given the technical nature of the subject matter, the IPC recommends convening a small group of experienced URS Practitioners (both Complainant & Respondent), Providers, and subject matter experts to draft the educational materials. Once approved, the educational materials should be provided to the IRT team tasked w/ implementing the RPM working group proposals. | ICANN should pay for educational materials developed to clarify its enforcement mechanisms and benefit the community at large. | Yes | Support Recommendation as written | There is disagreement as to the extent that this is an issue. The vast majority of URS decisions have a reasonably stated rationale for the decision and there is only a small set of URS decisions that might fall in this category of not stating a rationale. That being said, the IPC supports the idea of a requirement that Panelists provide a reasonably expressed rationale for the decision issued. The IPC does not support the notion of a detailed checklist of items to be included or a template to be followed. There is no need for such as most decisions have clearly expressed rationales and the possibility of imposing detailed requirements could become onerous in what is supposed to be a streamlined process. In addition, given the fees paid to Panelists for a URS decision, imposing strict requirements may deter many good Panelists from not wanting to take on URS cases, which will harm both Complainants and Respondents. In addition, imposing strict checklist requirements or templates are likely to create additional issues and burdens on Providers as well as the possibility of challenges of decisions on technical grounds, if only to delay the conclusion of proceedings. As such, the IPC believes that this issue, which involves a small number of cases, can be handled more easily and efficiently by simply requiring that Panelists provide a reasonably expressed rationale for their URS decisions, and by requiring providers to not release a decision until such contains a stated rationale for the decision. | Support Recommendation as written | IPC encourages IRT to ensure that Rrs, Rys, & Providers understand their roles & responsibilities in implementing URS outcomes; timely perform their duties; & that compliance mechanisms are created/strengthened and made accessible to ensure URS functions as intended. Given seriousness of the abuse and high standard of proof, relief should be swiftly implemented & capably administered. Important deficiencies exist. Provider survey indicates CP confusion about their role in extending suspensions. Providers encountered difficulties: slow response, slow/no response to provider info requests; delayed lock notification; delay notifying completion of suspension; and inaction/lack of communication to Providers requesting notification. Note there seems no consensus among Providers on whether Registrant info of suspended domains may be changed on suspension renewal. Some FORUM Examiners supported alteration. Practitioners survey also reveals suspension problems. 1/3 Practitioners said “problems with the implementation of the relief awarded following a URS decision.” Including difficulties: renewing suspensions, paying for renewals, & re-registration by losing Respondents or other “cybersquatters”. Some Practitioners consider this reduces/eliminates value of URS. INTA survey found “While the URS is helpful, the escalated proof required & limited remedy makes it of limited usefulness” noting utility of the mechanism is lost when the only relief, suspension, is not swiftly & correctly applied. Therefore, vital that CPs understand their responsibilities & the required technical procedures. Even domain investors note flaws. DomainNameWire: “It seems that the way URS works doesn’t fit into any existing automated procedures. It’s manual and requires a lot of human intervention, including when it comes time for renewal/expiration. That human intervention can be a problem… In some cases, the domain name registrar might have overlooked a manual process, and in others the registry did.” | Yes: As discussed in the WG, there can be circumstances where it is appropriate to move the domain from the registrar of record to an alternative registrar in order to enable the complainant to pay for the additional year's renewal anticipated by te URS - for example where the complainant cannot pay the existing registrar due to OFAC concerns, or where the registrar is one with a reputation as a bad actor. | Support Recommendation as written | The IPC believes it is important that there be consistency in guidance across URS service providers to ensure greater consistency in both instructions and resulting decisions. See our comments on URS recommendation #3 above,which would address the privacy/proxy concern. | Support Recommendation as written | The IPC agrees that ICANN should develop educational materials for Complainants & Respondents which outline the URS process. The materials should include an easy-to-understand, concise process overview, simple FAQ page, and copies of common documents; list links to Provider websites and compliance mechanisms; and be translated into the six United Nations languages. Much of the Providers’ processes are automated and offered online, so Complainants and Respondents are often on their own when navigating the procedure. MFSD and ADNDRC have a manual administrative review following submission. Deficient complaints are dismissed without prejudice (they cannot be amended), but the filing fee is not refunded. The RPMs PDP, Session 4 (March 15, 2018/San Juan) showed little uniformity in how the URS is administered by the three Providers: • ADNDRC, a collaboration of four Asian organizations, communicates only in English • FORUM provides downloadable documents and step-by-step explainer videos on their website • MFSD provides detailed descriptions of the URS program, rules and fees on their website • ADNDRC has six unlinked bullet points for rules & procedures, a flowchart, and submission guide • FORUM is aware that some Respondents did not file a response as they did not know how to proceed • FORUM received a number of complaints about their online portal • The Providers were generally amenable to the creation of these materials to supplement the information they already offer NOTE: Providers should be allowed to provide additional resources that may be useful to the parties and information on their own services and practices. The recommended guidance would demystify the URS, set reasonable expectations, and increase URS use and satisfaction. The IPC supports these goals. | ICANN should draft for the community to comment. | This is a situation that rarely occurs and is one that in most instances would be known to a Respondent, and which should be raised by a Respondent. To the extent there is consensus that there is a need to address this rare issue that may in fact have never occurred, then it should be limited to a simple check by a provider (as part of their normal review of a matter) of existing online databases of pending cases to make sure that the domain name at issue is not involved in another case. | The late fees as written are reasonable. The Respondent has the choice of paying the late fees to avoid a default. | URS Q #10 refers to penalties for a complainant or respondent who abuses the URS process. Whilst the URS procudure does include specific penalties for a complainant found to have abused the the process, there is in fact no penalty for an abusive respondent, whether this takes the form of abusing the URS process or repeated cybersquatting. In order to bring appropriate balance, and to encourage good behaviour, there should also be penalties for abusive respondents. Regarding the existing penalties for complainants, the IPC considers these to be more than sufficient. Indeed, in the absence of the balance that would be brought by penalties for the respondent, we consider these to be unduly harsh. | Yes | See URS Q10a | No, I wish to continue to the next section | Do not support Recommendation | The IPC supports maintaining the status quo on questions 1 and 3. The IPC does not support maintaining the status quo on question 2. As noted in related comments on the exact match issue below (see comments on Sunrise Recommendation #1 and Trademark Claims Recommendation #6) we consider the matching rules ought to be expanded. Given the substantial number of URS and UDRP decisions involving disputed domains incorporating a brand owner's mark in its entirety, some consideration for expansion should be given. The IPC suggests that for the purposes of Trademark Claims in particular we would strongly support expanding matching to also include "mark plus" and “mark-contained” variations. We would support expanding the matching rules to any variation in which the entire mark is contained – we believe this is important in terms of deterring bad faith registrations that rely on variants and not exact matches of a TMCH-recorded mark and to enhance the ability of TMCH-recorded mark owners to more robustly monitor new registrations for possible infringement and bad faith registration/use. | No, I wish to continue to the next section | Support Recommendation as written | As IPC participants have made clear throughout the discussion in the WG, we consider that limiting to exact matches only is inadequate to protect brand owner interests and avoid consumer deception. We are prepared to live with this in the spirit of compromise. | Support Recommendation concept with minor change | We strongly support this recommendation, and must ensure it is implemented in an appropriately robust and enforceable manner. See also our response on the TM-PDDRP Recommendation #1 | Do not support Recommendation | We would support a uniform challenge mechanism to challenge a registry operator’s designation of a name matching a TMCH-recorded mark as a premium or reserved name, and thereby unreasonably inhibiting the relevant brand owner from securing the name either during Sunrise or general availability. In our experience, registry operators will consider changing such designations on an ad hoc basis in response to direct, individual outreach from the brand owner, but there is no uniformity, transparency, or accountability around these informal communication channels, which would be improved through a single uniform mechanism applicable to all registries. | Support Recommendation concept with minor change | It is important to note that disclosure of a reserved names list (or part of the list) may ultimately prove necessary, for example in the context of a dispute resolutioon/challenge process, in order to ensure that registry operators are not using them to circumvent RPMs, for example, by reserving all names in the TMCH or targeting specific trademarks. Due to the expressed concerns of some Working Group members regarding the confidentiality of registries' business plans in relation to the publication of all Reserved Names in the new gTLD, we propose a compromise solution to address the need for compliance, transparency, uniformity, and operational effectiveness of the Sunrise RPM. Specifically, we propose that second-level strings reserved by the registry operator prior to, and during the Sunrise Period, shall be reflected in some form as reserved in the Registry Data Directory Services system. This solution will enable trademark owners who are prevented from defensively registering domain names during Sunrise because the New gTLD Registry has reserved the domain name to perform a Look-Up query to identify the domain name as reserved by the registry, without interfering with the ability of the registry operator to maintain a confidential list of all reserved strings. | Support Recommendation as written | Support Recommendation as written | Support Recommendation concept with minor change | Although we support the concept behind this recommendation, paragraph 3 should be amended: rather than a RO immediately deleting a domain name following a finding by the TMCH that it was based on an invalid TMCH record, the name ought to be suspended for a period in order to allow for the exhaustion of any time period to challenge that finding. | Support Recommendation as written | This was discussed extensively by the WG, and for all the reasons put forward during those discussions we do not support limiting the scope of sunrise registration in this was | he unintended effects of the Sunrise Period that we have identified relate to the abuses of the system by some registry operators ( see Sunrise Q 2 below). Sunrise recommendation #2 would play an important oart in remedying this, as would a the adoption of a challenge mechanism such as is referred to at Sunrise recommendation #3. It is also essential that ICANN Complance adopts a robust and proactive approach to compliance with the Sunrise, which is mandatory for the Contracted Parties. The implementation of Sunrise by registry operators in any subsequent rounds of new gTLDs must conform to the spirit and letter of the RPM, including clear triggering mechanisms and timelines to provide ICANN Compliance the ability to prevent Sunrise abuses which circumvent, discourage, and/or defeat the purpose and use of the RPM. | Yes | We have identified multiple systematic abuses of the Sunrise by new gTLD registries. In many cases, the abuse of Sunrise has the net effect of reducing the efficacy of the RPM, leading to increased levels of domain registration abuse, consumer confusion, and a reduction in consumer trust in the DNS. Additionally, Sunrise abuse also imposes significant external costs on right holders to the detriment of ICANN's New gTLD Program. Some primary forms of Sunrise abuse include: (1) the withholding, reservation or self-allocation of trademark-corresponding domains with the intent of circumventing or discouraging the use of the Sunrise Period; and (2) discriminatory pricing practices designed to leverage the need for defensive Sunrise registrations, including the excessive and exorbitant pricing of Sunrise domains with the intent of targeting trademark owners either specifically, or as a general class of registrants. The following non-exhaustive list of resources provide documentation of Sunrise abuse: 1) ICANN's Competition, Consumer Trust, and Consumer Choice Review Team Final Report, see page 131 of the report. 2) The Panel Report of ICANN's Public Interest Commitment Dispute Resolution Procedure (PICDRP), finding that the .feedback registry engaged in Sunrise abuse. 3) Correspondence from the Federal Trade Commission (FTC) outlining the FTC's assessment of Sunrise abuse in the .sucks new gTLD, available at: https://www.icann.org/en/system/files/correspondence/ramirez-to-jeffrey-27may15-en.pdf. Also see related 2015 communications from the IPC, BC, and ICANN Org on the Correspondence page. The FTC letter expresses concern on the manner the .sucks registry operated its Sunrise and that "it may well very well be that stronger rights protection mechanisms or amendments to the registry agreement are needed to ensure IP rights holders are adequately protected." | No, I wish to continue to the next section | Support Recommendation concept with minor change | The IPC does not believe there is evidence that there have been "unintended effects of deterring good-faith domain name applications". This reference in the first paragraph should therefore be amended to refer to "decreasing any possibility of deterring good faith registrations". IPC would revise the recommendation to more specifically note that either ICANN Org or an IRT tasked with implementing these proposals should solicit and consider input from resources that are expert in communicating complex issues relating to intellectual property to general public as part of its consideration of revision of the Claims notice language. In this regard, IPC believes that it is important to note that the Claims notice was co-written during the implementation phase for the 2012 Round. While it is therefore appropriate, at this point, to review and seek to improve the Claims notice to address any lessons learned to date, any future redraft will undoubtedly still result in a notice which is the result of compromise. | Members of the Intellectual Property Constituency who are members of the GNSO Rights Protection Mechanism Review PDP did work with other members of the PDP to draft possible revisions to the standard American Trademark Claims Notice. However, they stopped this effort when it became clear that making such revisions would require more time and close focus in that was possible in the PDP, and would be better handled by the Implementation Review Team implementing the actions recommended by the PDP or a team formed for that goal. At the same time, however, that draft prepared during the PDP discussions that might be used as a starting point for developing a more clear, understandable, and comprehensive Trademark Claims Notice than is currently being used. | Support Recommendation concept with minor change | IPC believes that Trademark Claims Notices can only effectively fulfill their intended function of notifying domain name applicants of potential conflicts with trademarks if they are clear and are understood. We therefore believe that reasonable steps should be taken to ensure that applicants understand the notice. We believe requiring that notices be provided in the languages of domain name registration agreements is a reasonable and necessary step to ensure that they are understood and enable applicants to knowledgeably determine the action they wish to take in response to the notice. The final bullet should be amended "The Claims Notice MUSTinclude..." | |||||||||||||||||||||||||||||||||||
48 | 5/4/2020 17:33:26 | Myrtha Hurtado Rivas | Novartis International AG | Yes | No, I would like to continue to the next section | Support Recommendation as written | No | The question of transparency must be considered for this option. Risks making this URS process inefficient should be minimized. | Support Recommendation as written | We should keep up the good work done until now by the whole EPDP team, and especially during the 2020 virtual ICANN summit. In fact, URS providers should send better and more specific notices to the Respondent if they do receive relevant and verified data from the Registry/Registrar. Cooperation between teams should be enhanced from the beginning of the process to its end. The fight against Intellectual Property Rights infringements and cybersquatting is a global issue which needs to be tackled decisively and collaboratively. | Support Recommendation concept with minor change | We suggest to change “AND” postmail into “OR” postmail. It would then state: “The Working Group recommends that URS Providers must comply with URS Procedure para 4.2 and para 4.3 and transmit the Notice of Complaint to the Respondent, with translation in the predominant language of the Respondent, via email, fax, or postal mail. URS Provider should not be submitted to complicated proceedings in order to contact the Respondent, especially as the email address is usually the sole reliable information.” | Support Recommendation concept with minor change | Where it is noted: “The Working Group recommends that such compliance mechanism should include an avenue for any party in the URS process to file complaints and seek resolution of noncompliance issues”, this should be specified. Indeed, enhancing compliance cannot be limited to a possibility of investigation of complaints and seek of resolution. It is imperative to allow the ability to enforce sanctions, where appropriate, and within reasonable timelines. | In order to enhance compliance of URS Providers, Registries, and Registrars in the URS process, we suggest a deposit mechanism when registering a domain name (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”) or at least a sanction mechanism should be applied to all actors if not respecting with compliance needs. An evolving sanction process could be implemented as follows: a simple reminder of URS rules and requirements in the event of first compliance violation; a financial sanction (or any other type of penalty, this can be discussed further) upon recidivism. The deposit mechanism could permit in case of non-compliance with the URS rules to have more leverage as there are direct assets to seize. Then it could permit to optimize some other related process like UDRP rules, etc. (e.g. the losing party could be the one paying. The winning party shouldn't support costs, otherwise it is always worth trying for the cybersquatters). | Support Recommendation concept with minor change | As it has been said in URS Recommendation #2, cooperation between teams should be enhanced from the beginning of the process to its end and exchange of information is key to cooperate successfully. It is crucial to have verified and up-to-date reliable information in order for this URS mechanism to be useful. | Support Recommendation as written | Educational materials are always useful, especially when developing new practices. We would suggest that this material, when ready to be transmitted to the parties concerned, should be presented by its authors in a webinar/presentation. | These educational materials should be simple guiding documents such as online leaflets or PowerPoint presentations. On top of that, we suggest it should be divided into different parts/modules referring to different types of infringements. Either way, these materials should include a suggested list of the evidence that should be provided to support the conclusion that a domain name has been registered and used in bad faith and clear explanations of the three parts of the relevant test. | Gathering stakeholder input once a draft has been put together would make sense. On the other hand the exercise should be pragmatic and not cost too much time. | The costs should be borne by ICANN’s as part of its arbitration mission. Interested actors should be given the opportunity to take part in its development (cf. Q4b). On top of that, URS providers should be involved. | Yes | Support Recommendation as written | Support Recommendation as written | Yes | Support Recommendation concept with minor change | We do understand “the fact that domains subject to a URS Complaint may have been registered via a privacy or proxy service”. Nevertheless, this whole URS process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. In fact, certain URS proceedings should be registered as best practices in order to gain some time when facing similar proceedings or Determination. | Support Recommendation as written | Following above principle FAQs should be developed thanks to cooperation and inclusion of all stakeholders, whilst respecting suitable time lines and being pragmatic. | When attempting to lock a domain name upon receipt of a URS complaint, the Registrar should advise the URS provider whether or not, the same domain name is already locked pursuant to a concurrent legal proceeding. | Yes | As there has been no evidence of abusive Complainants, there is no need to provide any further procedures here. However, the procedures do not establish concomitant penalties for abusive Respondents. This system is unfair, because it presupposes that only one party could act in an abusive manner, which is not the case. | Yes | In accordance with answer to URS Q10 above, we recommend the creation of a system that would penalize abusive complainants indeed, but also abusive respondents. Therefore, deliberate material "falsehoods” should be extended to apply to Respondents, and not just Complainants. A deposit mechanism paid by the Registrant at the moment of the registration of the domain name would permit to establish a better balance regarding the burden of the penalties and an efficient way to recover money in case of abuse by the Respondent (as developed in the URS Individual Proposal #15 and #22 below “loser pays system”). It could then be a way to stop the fact that Complainants have to pay for UDRP and that there are no penalties for Respondents. This mechanism is encouraging cybersquatters as there is no risk at all except the fact that they may lose a domain name (extremely low cost: 10USD compared to UDRP: 1500USDmin fees). | No, I wish to continue to the next section | Support Recommendation as written | Considering the working group’s discussions and opinions, we agree on maintaining “TM+50” criteria as it is, as same as the limitation of sunrise and claims RPMs to certain gTLDs. Regarding the “Exact match” criteria, we would suggest putting more efforts on evaluating whether this latter criterion still matches its intended purposes. If not, we would suggest reviewing it or making the necessary changes in order to allow it to return to its original objectives. As a suggestion, “Exact match” criteria, should be expanded to cover certain variants such as singular and plurals. | No, I wish to continue to the next section | Support Recommendation concept with minor change | Support Recommendation as written | The recommendation is of crucial importance to prevent any risks of non-compliance with the mandatory Rights Protection Mechanisms imposed by ICANN and on which we are asked to give our feedbacks here. We stress the importance of a policy of severity and strictness for the disrespect of these RPMs. Indeed, tolerating non-compliance to RPMs would indirectly lead to an influx of intellectual property rights’ infringements, as well as cybersquatting. | Significant change required | We believe this recommendation (“[…] the Working group does not recommend the creation of a challenge mechanism”) needs to be reconsidered. Regarding the context given: “The Working Group had diverging opinions on whether Registry Operators should be required to create a mechanism that allows trademark owners to challenge the determination that a second level name is a Premium Name or Reserved Name”, we believe trademark owners should be better considered here, with regard to the protection of their IP rights. We support the proposition of some working group members regarding the creation of a uniform challenge mechanism and implementation guidance that would allow this mechanism to be used more wisely and widely. We do not think the elements given by opposition members to this challenge mechanism are convincing enough, especially concerning the possibility of increasing the Registry Operators’ workload. | No opinion | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Limiting the scope of Sunrise Registrations could increase “the uncertainty regarding the scope and extent of abuses of the Sunrise Period”. If Sunrise was limited to the categories of goods and services for which the TM is actually registered, it would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). It is very important to take into account the fact that the more widely we can eradicate all types of abuse of the Sunrise mechanism, the more effectively we will be able to protect RPMs, and more precisely trademark rights. | In fact, as it was justified in URS recommendation #9, this whole RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | No, I wish to continue to the next section | Support Recommendation concept with minor change | This recommendation is central in the development of Rights Protection Mechanisms. Indeed, having as much clarity and simplicity as possible during the trademark claims process is crucial. As it is one of the most vital aspects of ICANN’s work regarding trademark rights, it is essential to ensure efficiency, clarity, precision and conciseness. | Support Recommendation concept with minor change | As proposed in URS recommendation #9, this RPMs process should at least have English as a common language, on top of the language of the location of the service, in order to have a worldwide understanding of each process. | |||||||||||||||||||||||||||||||||||||||||||||
49 | 5/4/2020 17:56:32 | Jason Schaeffer | ESQwire.com P.C. Registrant and Registry Counsel | No | Support Recommendation as written | Yes | In the event facts show a respondent is not the registrant. Cases of theft or fraud could give rise to circumstances that would justify withholding the updated identification. | The respondent should be provided notice of this limited option. | Do not support Recommendation | Support Recommendation as written | Support Recommendation as written | Through contractual provisions with URS providers (subject to review and recertification) and uniform supplemental rules. | Support Recommendation as written | Support Recommendation as written | Highly suggest that a guide or document (like the WIPO Consensus View) be created to provide guidance. | Instruction on the "clear and convincing" standard and summaries of URS cases and/or application of the test. Guide for practitioners and panelists to help streamline and unify the process. | Through a community lead process with expert review and participation. | ICANN and/or DRPs | Yes | Support Recommendation as written | Fairness dictates that decisions provide the rationale and basis for decision in sufficient detail to understand how the threshold for finding the elements have been met. | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | ICANN in connection with DRPs. | Searchable database. | Yes, provided the are reasonable. | No. | Yes | Penalties for abusive filings should cover the firm or organization, not just the actual filer. | No, I wish to continue to the next section | Support Recommendation as written | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The TMCH should be a searchable database to help avoid abuse of the TMCH and Sunrise process. | Yes | This issue was extensively discussed in the WG and the WG reviewed materials that provided examples of abusive registrations that would allow parties to obtain priority registration for domain names. This abuse or "gaming" should also be considered in the context of Sunrise Recommendation #2 concerning Registry Operators ("ROs") and the ROs ability to properly manage reserve lists and premium pricing in good faith, and in a way that is fair and appropriate. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Claims Notices should not be overreaching or expand TM rights. The messaging should be clear to the average person that this is not an indication that you have acted improperly. The current Notices may have an improper and undesired chilling effect on free speech and legitimate use. Care must be taken when drafting a new version. | Support Recommendation as written | |||||||||||||||||||||||||||||||||||||||||||||||||||
50 | 5/4/2020 18:11:26 | Ephraim Percy Kenyanito | ARTICLE 19 | Yes | Do not support Recommendation | The proposal would certainly enable violation of registrant data and would be contrary to the Global Principles on Protection of Freedom of Expression and Privacy which can be found here:- http://article19.shorthand.com/ | Yes | any form of disclosure of registrant data should be done within the framework of WHOIS/RDDS and must be in line with the Global Principles on Protection of Freedom of Expression and Privacy which can be found here:- http://article19.shorthand.com/ | Yes, there is need for operational changes to be in line with the following data protect rights which include but are not limited to the: i. Right to ensure that data is stored and processed lawfully (on the basis of consent or some other lawful basis laid down by law),fairly and securely; ii. Right to know what personal data is held about them by controllers (right of access) and for what purpose; iii. Right to seek to correct that data when it is inaccurate (right of rectification); iv. Right to demand that data be deleted when it is no longer necessary for the permitted purpose, when it is irrelevant or out-of-date, when consent has been withdrawn and there is no other lawful basis, when the data has been unlawfully processed, or when it has been made public without justification (right to erasure); v. Right to receive one’s personal data from a data controller for the purpose of changing a service (data portability); and vi. Right to object to the processing of data for particular purposes, including for direct marketing and profiling, where certain conditions apply (right to object). | Support Recommendation as written | Support Recommendation as written | This is a welcome proposal as it respects the rights listed below: i. Right to ensure that data is stored and processed lawfully (on the basis of consent or some other lawful basis laid down by law),fairly and securely; ii. Right to know what personal data is held about them by controllers (right of access) and for what purpose; iii. Right to seek to correct that data when it is inaccurate (right of rectification); iv. Right to demand that data be deleted when it is no longer necessary for the permitted purpose, when it is irrelevant or out-of-date, when consent has been withdrawn and there is no other lawful basis, when the data has been unlawfully processed, or when it has been made public without justification (right to erasure); v. Right to receive one’s personal data from a data controller for the purpose of changing a service (data portability); and vi. Right to object to the processing of data for particular purposes, including for direct marketing and profiling, where certain conditions apply (right to object). | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The materials should be translated to all the UN languages and should be simple enough for an ordinary registrant to understand. | The materials should be developed through a multi stakeholder process. | ICANN should bear the cost as part of the implementation process. | Yes | Support Recommendation as written | No opinion | No opinion | Support Recommendation as written | This recommendation should respect registrants rights listed below: i. Right to ensure that data is stored and processed lawfully (on the basis of consent or some other lawful basis laid down by law),fairly and securely; ii. Right to know what personal data is held about them by controllers (right of access) and for what purpose; iii. Right to seek to correct that data when it is inaccurate (right of rectification); iv. Right to demand that data be deleted when it is no longer necessary for the permitted purpose, when it is irrelevant or out-of-date, when consent has been withdrawn and there is no other lawful basis, when the data has been unlawfully processed, or when it has been made public without justification (right to erasure); v. Right to receive one’s personal data from a data controller for the purpose of changing a service (data portability); and vi. Right to object to the processing of data for particular purposes, including for direct marketing and profiling, where certain conditions apply (right to object). | Support Recommendation as written | These should be developed in consultation with ICANN Org and the community to ensure uniformity. | We submit that the proposed fees are too prohibitive for developing country participants. | The proposal of introducing penalties is contrary to the purpose of URS, which is supposed to be a different system as compared to the UDRP. | No | Any attempt to expand is contrary to the purpose of URS, which is supposed to be a different system as compared to the UDRP. | No, I wish to continue to the next section | Significant change required | We support the changes proposed by NCSG. | Support Recommendation as written | Do not support Recommendation | We reject the proposal as it is vague/ too broad and open to misinterpretation. | Do not support Recommendation | We reject the proposal as it is vague/ too broad and open to misinterpretation. | No opinion | Support Recommendation as written | Do not support Recommendation | We support the position by NCSG. | Support Recommendation as written | Do not support Recommendation | We support the position by NCSG. | We support the position by NCSG. | Yes | We support the position by NCSG. | Support Recommendation as written | Yes | The TM Claims notice is not registrant/ user friendly enough and should be revised further. | The language should be translated and be easier to understand by the average registrant. | Support Recommendation as written | The language should be translated and be easier to understand by the average registrant. | |||||||||||||||||||||||||||||||||||||||||||||||
51 | 5/4/2020 19:01:11 | Steve DelBianco | NetChoice | Yes | ICANN Business Constituency (BC) | No, I would like to continue to the next section | Support Recommendation as written | The BC supports this change since it merely reflects proposed rule changes to mirror the current approach taken in practice for the UDRP. Complainants file complaints based on publicly available Whois data, providers reveal underlying registrant data, and then Complainants have an opportunity to update their complaints to reflect actual respondents. | In general, no, we don’t need that amendment. Except in rare exceptions for minors and victims of certain crimes, parties to legal disputes are uniformly made a matter of public record, thus serving important notice and public policy goals. The URS is no different, and should remain no different. | In general, no, we don’t need that amendment. Except in rare exceptions for minors and victims of certain crimes, parties to legal disputes are uniformly made a matter of public record, thus serving important notice and public policy goals. The URS is no different, and should remain no different. | Support Recommendation as written | The BC supports this change since it merely reflects proposed rule changes to mirror the current approach taken in practice for the UDRP. Once a domain name is locked by the registrar, URS Providers may send requisite notices. | Support Recommendation concept with minor change | The BC supports this change since it merely reflects proposed rule changes to mirror the current approach taken in practice for the UDRP. Importantly, by default, the “predominant language of the Respondent” must be determined by the language of the domain name registration agreement. | Support Recommendation concept with minor change | While we support the Recommendation, it should also provide for the elaboration of consistent enforcement mechanisms, including sanctions for non-compliance. | The compliance requirement for URS and UDRP are similar, and therefore should be enforced consistently. | Uniform supplemental rules, and a comprehensive URS provider contract instead of a Memorandum of Understanding, together with an established compliance mechanism To enhance compliance, it’s critical to have access to accurate, current registration data upon legitimate request. GNSO Council and the EPDP should act on the matter of accuracy. | Support Recommendation as written | Support Recommendation as written | The BC supports this change since it is designed to ensure that complainants, respondents, and URS panelists each set out specific fact-based evidence, conclusions of law, and persuasive precedent, as opposed to mere conclusions. | Materials must contain a proposed illustrative checklist of evidence to support the conclusion that a domain name has been registered and used in bad faith. For example, Nominet has useful resources, at https://www.nominet.uk/domain-support/uk-domain-disputes/ Detailed information on the three-part tests and what they mean and require, in particular what “clear and convincing” requires. Detailed summaries of applicable precedent and case law, eg a “Consensus View” A help line for procedural issues. | By the community, URS providers and panelists and ICANN Org. | These materials can be developed on a volunteer basis by providers and panelists (at no cost), coordinated and supported by ICANN Org. | Yes | Support Recommendation as written | Examiners should certify that their decisions must include an explanation of their rationale in reasonably brief and sufficient detail so that a reader or review body can understand the basis for the decision and not merely set out that the tests have been met. | Support Recommendation as written | The BC supports any changes necessary to permit Registry Operators to offer the option to URS complainants to extend suspension for an additional year after expiry. | Yes | Support Recommendation concept with minor change | The BC views such implementation guidance as inappropriate coming from the Implementation Review Team. Such guidance is the responsibility of the providers and its panelists, which should accord with the body of determinations already well established and used to determine the language of the proceedings under the UDRP. We need all URS providers to follow the same rules, and we can`t leave it up to the providers to individually determine what language to use without any guidance on this issue. | Support Recommendation as written | The working group should look to existing examples, perhaps from WIPO or other providers, to determine whether or not there are industry best practices that could be applied. | These educational materials should be developed as the result of volunteer efforts by URS providers and panelists, coordinated and supported by ICANN Org. | The responsibility to notify URS providers of concurrent proceedings between the parties properly falls to the parties themselves. This is particularly the case in putative instances of domain names subject to receivership. That said, when attempting to lock a domain name upon receipt of a URS complaint, it should be the registrar’s responsibility to advise the URS provider whether or not the same domain name is already locked pursuant to a concurrent legal proceeding. | N/A | Yes. The BC supports certain reasonable Respondent fees—whether for late responses, multiple domain names, or repeat serial cybersquatters—designed to better apportion proceeding costs between the parties. There should be standardization of late fees across all dispute resolution providers. | Yes with respect to complainants, who are currently penalized for “deliberate material falsehoods.” And the BC recommends that comparable penalties apply to respondents who abuse the URS process | Yes | The BC recommends that the prohibitions against “deliberate material falsehoods” be explicitly extended to apply to respondents, not just complainants | No, I wish to continue to the next section | Support Recommendation as written | The BC supports the status quo for these three elements of the TMCH. However, the BC also supports relaxed evidentiary standards to support TM + 50 entries (meaning that determinations should be sufficient without referring to specific trademark registration numbers) and “exact match” rules should be expanded to cover certain variants such as singular and plurals. Finally, the BC opposes any formalized limitation on the scope of RPMs based on the categories of goods or services arguably related to a particular gTLD. | No, I wish to continue to the next section | Support Recommendation as written | Support Recommendation as written | The BC supports this recommendation, prohibiting the circumvention or RPMs by registry operators. | Support Recommendation as written | Support Recommendation as written | The BC supports this recommendation as the default rule. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The BC would oppose any proposed limitations on sunrise registrations to specific categories of goods or services. Such a limitation would be an entirely subjective analysis, subject to differing interpretations regarding related or overlapping goods or services. Limiting Sunrise to the categories of goods and services for which the TM is actually registered would be both inappropriate and impossible. There can only ever be one string (as opposed to co-existing TMs for different classes and services). | The BC is confident that the current challenge procedure for sunrise registrations adequately addresses any “unintended effects” or gaming. It is incumbent upon the parties alleged to have been affected by such “unintended effects” to actually use the relevant registry SDRP. | Yes | Back in 2015, the BC wrote to ICANN Org with serious concerns about brand domain name pricing abuses in the Sunrise period for .SUCKS, including this: Vox Populi plans to take trademarks registered in the TMCH and sell corresponding domain names at “$2499 and up,” a price much higher than the cost recovery basis contemplated by the consensus policies as reflected in the gTLD Applicant Handbook. This approach turns the creation of the TMCH on its head – instead of using the TMCH to promote an efficient approach to dealing with recognized trademarks, it penalizes businesses that have chosen to use the process and register their marks in the TMCH. If Vox Populi was populating the list using data from the TMCH, that too would be a breach of its registry agreement with ICANN prohibiting such activity. see https://www.bizconst.org/assets/docs/positions-statements/letter-to-icann-dotsucks.pdf The TM-PDDRP was written to prevent Registry Operators from taking unfair advantage of trademark owners. Fortunately, other ICANN policies and AGB terms have prevented many of the harms the TM-PDDRP was designed to address. As a result, the TM-PDDRP is not regularly used. However, new issues like price gouging (that was not considered as part of the original TM-PDDRP) are consistent with the premise for creating the procedure - helping guard against bad actor Registry Operators. We propose the Working Group consider a few minor wording adjustments to be provided to allow brand owners to use the existing procedure to seek recourse against Registry Operators engaging in egregious pricing practices. We note several guardrails that will prevent over-reach: 1. Higher prices alone are not de facto price gouging. Registries often charge slightly higher prices for Sunrise based on their costs. 2. Price gouging does not include listing an otherwise generic name at a higher price unless it is specifically targeted based on the TLD term (e.g., apple.computer vs. apple.food) 3. The policy can only be used against a Registry Operator that shows a pattern of bad faith behavior, not a few isolated incidents. 4. The system is loser-pays. 5. Compliance still must still determine the appropriate remedy. 6. This change does not add any new rights, but merely proposes a new way to enforce the existing policies and procedures. [ the above response is repeated for TM-PDDRP Rec 1 ] | Yes | At the outset, entry of non-English trademarks into the TMCH yielded its own set of difficulties, including: the lack of publicly accessible national trademark databases, or databases in a language accessible by the TMCH; and rejection of TMCH entries based on minor discrepancies and issues lost in translation by the TMCH. | Focus on reducing the barriers to entry at the TMCH for non-English scripts and languages. | No, I wish to continue to the next section | Support Recommendation as written | Yes | The Claims Notice is only issued in English. The BC recommends that the Claims Notice be translated and delivered in all official United Nations languages. | The Claims Notice is only issued in English. The BC recommends that the Claims Notice be translated and delivered in all official United Nations languages. We should also make notices more user friendly and provide more information, including explanation that it does not mean that you have necessarily done anything wrong or that the referenced trademark owner has any superior rights. This will help avoid the notice appearing to be spam as per Recommendation #1. Could also give examples of why a registration subject to a Claims Notice may be lawful or unlawful. | Support Recommendation concept with minor change | It is likely easier for registrars to deliver a single notice, containing the recommended hyperlink to translations in all official United Nations languages. The mandate to issue the Claims Notice in “the language of the registration agreement” may prove impractical in jurisdictions where registrars do not use one of the six United Nations languages. | ||||||||||||||||||||||||||||||||
52 | 5/4/2020 18:56:48 | At-Large Staff | At-Large Advisory Committee (ALAC) | Yes | Staff submission on behalf of At-Large Advisory Committee (ALAC) | No, I would like to continue to the next section | Support Recommendation as written | The Working Group believes that its recommendation is consistent with the EPDP Phase 1 Recommendations #21, #23, and #27. | No | N/A | N/A | Support Recommendation as written | Consistent with GDPR implementation and EPDP Recommendations 23 and 27. | Support Recommendation as written | Translation of complaint into predominant language of the Respondent is consistent with ALAC principles. | Support Recommendation as written | Consistent with principles of accountability, reliance on metrics and ability to seek redress. | Support Recommendation as written | Process improvement. | N/A: For registry operators only. | N/A: For registry operators only. | N/A: For registry operators only. | Support Recommendation as written | Provides assistance to those who may not be able to afford the assistance of counsel. | Content should be readily accessible to the average reader. | Collaboration with both experienced individuals, organizations and end users. | URS providers should bear the cost of providing these materials as, in the end, it will save time and effort in any proceedings. | Yes, at a minimum to the usual ICANN languages; also to languages in which URS cases could be brought. | Support Recommendation as written | Consistent with principles of accountability and transparency. | No opinion | Technical Issues not of significant concern to end-users. | No opinion. Technical Issues not of significant concern to end-users. | Support Recommendation as written | Consistent with principles of using primary languages of participants where possible. | Support Recommendation as written | Consistent with principles of using primary languages of participants where possible. | Providers, in collaboration with both experienced individuals, organizations and end users. | No opinion, technical issue not of significant interest to end-users. | N/A | N/A | No opinion. Issue not of significant interest to end-users. | No opinion. Issue not of significant interest to end-users. | No opinion. Issue not of significant interest to end-users. | No opinion. Issue not of significant interest to end-users. | No, I wish to continue to the next section | Support Recommendation as written | The current rules appear to be working as intended. | No, I wish to continue to the next section | Support Recommendation as written | The current policies appear to be working as intended. | Support Recommendation as written | Consistent with principles of allowing ICANN policies to operate as written. | Support Recommendation as written | The current policies appear to be working as intended. | Support Recommendation as written | The current policies appear to be working as intended. | Support Recommendation as written | The current policies appear to be working as intended. | Support Recommendation as written | The current policies appear to be working as intended. | Support Recommendation as written | These are process improvements that will allow policies to work as intended and improve transparency and comprehension by all involved. | Support Recommendation as written | The current policies appear to be working as intended. | N/A | No | N/A | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to Registry Operators only. | N/A: applies to trademark holders only. | N/A: applies to trademark holders only. | N/A: applies to trademark holders only. | No, I wish to continue to the next section | Support Recommendation as written | Consistent with policies of transparency, clarity and comprehensibility for the broadest group of end-users and other participants. Also consistent with principles of turning to multiple points of experience in the global community. | Support Recommendation as written | Consistent with principles of supporting uses of languages other than English and using primary languages of participants. | |||||||
53 | 5/4/2020 19:24:02 | Abram Massey | Domain Name Rights Coalition | No | No, I would like to continue to the next section | Do not support Recommendation | We disagree with this recommendation and cite evidence provided by The Forum: "No Complainants have expressed a desire to amend based on registration data. The Examiner has access to the registration data obtained from the Registry (or Registrar) and, if need be, is able to address the full data if appropriate. As a practical matter, it seems that allowing 2-3 days for amendment will only delay the issuance of a Determination which is counter to the quick determination the Complainant is hoping to achieve with a URS filing.” Further, allowing an amendment will require Forum to modify its online filing platform, which will require costs disproportionate to the filing fees it receives from URS cases." Further, due to automated URS systems, TM owner's amendment will result in disclosure of potentially "personal" and "sensitive" data of non-profit organizations, individuals and home-based businesses in violation of GDPR and other privacy provisions -- even if there is no allegation of a pattern of abuse and/or default and/or no finding against registrant. Overall, purpose unclear, costs (privacy and financial) too high – and without show of need. | Yes | We oppose the change which will automatic publication of personal/sensitive data in URS Rec#1 above. But there may be ways to do it. Publication can and may take place, but only for the specific "purpose" we understand the change is for -- to identify those registrants with a pattern of *proven* bad faith registrations. Accordingly, and upon a) loss by the Registrant of this URS case, b) based on the showing of a proven pattern of bad faith registrations, c) and after an opportunity for the Registrant to know of the disclosure of their personal or sensitive data and respond with legal concerns, d) then the Examiner may be allowed to publish the true identity of Respondent(s). | Yes, the recommendation triggers automatic action that should not take place automatically. Far better to continue current practices, and give the Examiner the opportunity to disclose personal/sensitive data per the guidelines in Q1b above. This limited disclosure process will protect Registries, Registrars and Providers (as well as providing legal rights to Registrants). | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The materials should explain the importance of giving full and clear rationales for decisions by Examiners, including short and clear statement of facts (or lack thereof) and conclusions leading to the findings and decision. | The educational materials should be developed with input by stakeholders. | As part of its implementation work, ICANN should bear the cost of the development of these materials and then sharing them with Stakeholders and Providers for review, discussion and input. Alternatively, Providers could develop -- and publish -- their own clear statements. | Yes | Support Recommendation as written | Support Recommendation as written | No | Support Recommendation as written | Support Recommendation as written | Providers and ICANN should share the rather light responsibility of developing a uniform set of basic FAQs for trademark owners and registrants. These materials should be translated into all the languages of key ICANN documents. It seems a clear and easy step towards fundamental fairness and clearer understanding of the URS system. | No, the fees are not fair because they appear too high for registrants from the Global South. Evidence shows that respondents from Japan, China, Australia and the US have paid response fees, however, response fees should be set so all registrants have the opportunity to respond to a URS filing -- with discounts for regions including Latin America and Africa. | We know there will be calls to raise penalties on Respondents, and we object. The URS was designed for dealing with the "slam-dunk" cases quickly and cheaply. There is not much opportunity for registrants to abuse the process, and default rates are already far too high. There is no evidence to indicate there should be additional penalties for registrants -- their loss/suspension of the domain name is the agreed-upon penalties. There may be additional penalties we should be considering together for Complainants, and we look forward to seeing proposals made and discussion to come. | No | No, I wish to continue to the next section | Significant change required | Exact match should continue to be the standard. But the separation of trademarks from their goods and services is an over-expansion of trademark rights and far beyond the rights granted by national law. So the TMCH, and its use in RPMs, must be linked to categories of goods and services of the national trademark registration. Further, the TMCH database must become open and public to allow transparency and accountability - that trademark owners are using their trademarks within their rights. This openness also will allow easy elimination of those almost everyone would agree are "gaming" the system (as reported in a number of investigative journalist pieces). The goal of the system has always been to allow brand owners to protect their brands, and legitimate small businesses and entrepreneurs to create new brands. | No, I wish to continue to the next section | Support Recommendation as written | As noted above, the exact match standard, without examination of goods and services, is too broad. We need additional protections for basic redundant use of ordinary words and names -- as allowed under existing law. | Do not support Recommendation | This recommendation is not worded to correspond to the context. That context states that the recommendation is limited Premium Names, and if that would the case, it would fine. But as written, the recommendation could be very broadly interpreted to damage Registries who do not create policies far above existing consensus policies to further protect trademark owners. We can't agree. | Do not support Recommendation | The "context" indicates that this recommendation applies to premium and reserved names, and if that were the case, it would be acceptable. However, as written, this recommendation could be interpreted to bar challenges overall -- and that is not something the WG has studied, discussed or agreed. | No opinion | Support Recommendation as written | keeping the current limited scope of the Sunrise period is a key part of its fairness and balance. | Do not support Recommendation | We strongly recommend returning to original option: Sunrise Period OR Trademark Claims. Further, with a secret TMCH database and an inability to monitor the registration of ordinary names and words into the TMCH, the Sunrise period is far broader and less fair than intended by those who adopted it originally. There are good reasons for it to be removed as we move forward with new rounds of gTLDs. | Support Recommendation as written | Do not support Recommendation | Oppose. It is a fundamental principles of the RPMs that they not expand trademark rights. But taking trademarks out of their context -- out of the goods and services for which the national governments grant a trademark - is essentially protecting the string itself. This is far beyond the rights granted by national law, and far beyond the ICANN Community's agreement and mandate. This is the time to correct the over-protection and return to a balance that also protects entrepreneurs, small businesses, individuals and organizations -- and the full scope of allowed fair use and redundant use. | The WG notes show research by members, investigative reporters, and the Analysis Group of those who register trademarks solely for the purpose of registering ordinary words as domain names across many new gTLDs. This is an unintended effect that must be closely reviewed and corrected before going forward with finalized recommendations of RPMs. Let's nip this abuse in the bud before new rounds of gTLDs open. | Yes | See answer above. The research of the WG shows clear abuses, as does the Analysis Group and investigative reporters. Ordinary words are being registered -- and the inability to audit or review the TMCH database compounds the problem. This has resulted in a clear misuse and abuse of the Sunrise Period which no one would want to defend. In the interest of the integrity of the ongoing RPMs and ICANN, it is critical to correct these problems now, before they become compounded in future rounds of new gTLDs. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Many inadequacies and shortcomings have been identified in the Claims Notice. We look forward to the new draft that will be issued before the next round -- one much more understandable to registrants (and translated into languages of their registration agreements)! | clear language, translations, a fair assessment of the concern being expressed (and the rights they may have to move forward with registration). | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||
54 | 5/4/2020 19:29:21 | Charles Duan | Director, Technology & Innovation Policy, R Street Institute | No | I am providing these comments in my capacity as a website host and domain name holder. I additionally draw from my knowledge and experience on Internet policy as reflected in my position as a policy researcher at a think tank. | No, I would like to continue to the next section | Do not support Recommendation | The ability of a domain name registrant to protect private, sensitive information from public disclosure is an essential right, now protected under GDPR and other legal privacy regimes. To the extent that an amendment permitted by this recommendation causes the public disclosure of personally identifiable information about a registrant that was not otherwise available, it potentially violates the law and offends registrants' right to privacy. | Yes | The information should remain unpublished, with only the public WHOIS data being published, unless the registrant agrees to its publication or, following a determination adverse to the registrant, it is found to be necessary to disclose the registrant's personally identifiable information in order to prevent further abuse. | There is at least some possibility that unscrupulous entities may try to use the URS process in order to unmask domain name registrants rather than to pursue a legitimate complaint of domain name abuse. Such concerns may seem remote, but in numerous legal fields that the commenter has observed, a seemingly innocuous adjudication procedure can turn into a minefield of abusive tactics in the hands of clever and enterprising lawyers. All caution must be taken to avoid this possibility. | Do not support Recommendation | It is imperative that any rights arising during the Sunrise Period be as analogous as possible to rights available under corresponding national trademark laws. To allow otherwise would let holders of marks designated for particular goods or services to exercise effective control over bare words. Trademark laws do not contain these limitations without good reason; the consistent requirement that trademarks be tied to goods or services is to ensure minimal disruption to principles of free expression, criticism, and open societies. Furthermore, if ICANN processes offer broader rights than ordinary trademark law, then trademark holders will likely resort to domain name dispute resolution procedures rather than national courts to an inappropriately large extent, which would unnecessarily burden both registrants and the gTLD operators. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
55 | 5/4/2020 19:52:02 | Konstantinos Zournas | Website developer and domain name owner | No | No, I would like to continue to the next section | Do not support Recommendation | Yes | At the option of the registrant, if and only if they are a natural person covered by applicable privacy legislation. | Support Recommendation concept with minor change | Significant change required | Significant change required | Support Recommendation as written | Do not support Recommendation | Support Recommendation as written | Do not support Recommendation | Significant change required | Do not support Recommendation | Support Recommendation as written | Significant change required | Do not support Recommendation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
56 | 5/4/2020 20:33:03 | Jonah Sanders | Brandeis Initiavie For Technology, Machines, Applications, and Programming | Yes | This is an organization dedicated to furthering the technology related needs at Brandeis University. | No, I would like to continue to the next section | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Significant change required | If a dictionary term is used, it should only be used if the trademarked goods and services relate to the new gTLD. | Support Recommendation as written | Do not support Recommendation | Do not support Recommendation | Support Recommendation as written | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
57 | 5/4/2020 19:56:35 | Mitch Stoltz | Electronic Frontier Foundation | No | No, I would like to continue to the next section | Do not support Recommendation | This proposal would create a means for trademark holders to de-anonymize registrants without sufficient process or justification, by amending the URS caption to identify the respondent to the public. This harms registrants' privacy and may create a means to circumvent the procedure being worked out in the EPDP on registrant privacy. Disclosing registrants' private information to the public without regard to the purpose for such disclosure would violate privacy laws. It may also give the URS complainant undue leverage over the respondent, even if the respondent wins the URS proceeding. | Yes | Absent a determination by a panel that a registrant has engaged in a pattern of bad faith registrations, disclosure of the registrant's private information should never be disclosed through URS processes without the registrant's consent. Inaction by the registrant should never be sufficient for disclosure. | Yes. The publication of the respondent's redacted and private information should not be automatic. It should not occur unless the respondent wins and the grounds include a pattern of bad-faith registrations. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The materials should emphasize the importance of giving specific rationales for the panel's decision, with reference to the facts presented. They should include model decisions. | The materials should be developed by a cross-section of stakeholders. | ICANN. | Yes | Support Recommendation as written | No opinion | No opinion | Support Recommendation as written | Making the URS process comprehensible to people around the world in the language they speak is an important component of due process. Registrants must be able to understand the nature and content of proceedings against them. | Support Recommendation as written | ICANN, in conjunction with URS providers. This will promote uniformity. | No. The late fees are too high, especially for registrants in the global south. The limited data available shows very few response fees paid outside the developed countries, suggesting that registrants in the global south may be unfairly having their domain names suspended. | The current penalties are more than sufficient. The URS is designed to be a fast, abbreviated process for the clearest cases of cybersquatting. Additional penalties would also transform the URS into a high-stakes forum where proceedings will be bitterly fought. Moreover, respondents do not choose to be brought into URS proceedings and have little opportunity to respond, so there is not much opportunity for "abuse." Finally, there are no additional "penalties" that could reasonably be added to a voluntary arbitration process like URS. Neither URS panels, nor registrars, nor any other participant in the domain name system currently has the power or jurisdiction to levy fines or impose penalties beyond suspension, transfer, or other disposition of a domain name. Creating the mechanisms to even attempt this would fundamentally change the nature of URS proceedings and the relationship of registrants to the DNS. In short, it would change URS proceedings into court proceedings and registrars into bailiffs. Registrants will not tolerate a domain name system with the power to levy fines, and even attempting to enforce such a system would destroy its credibility. | No | They should not be expanded because expansion would fundamentally change the relationship of registrants to the DNS. | No, I wish to continue to the next section | Significant change required | The TMCH needs more limits, not less. TM+50 was not the product of any multistakeholder process, and must not become part of the TMCH without such process. The "exact match" rule should be maintained. Dictionary words entered as marks in the TMCH should qualify for Sunrise registrations only when the TLD is relevant to the category of goods and services for which the mark is registered. The current operation, which does not take the category of goods or services into account, represents a vast expansion of trademark rights under the law of any country—effectively transforming trademarks into the ownership of dictionary words. This is a significant problem: according to the Analysis Group report, the most commonly matched terms in the TMCH are common dictionary words, which have numerous legitimate uses other than as trademarks, and may even serve as trademarks for entirely separate goods and services. This should end. | No, I wish to continue to the next section | Support Recommendation as written | Exact matches for Sunrise are already too broad, because they apply regardless of the categories of goods and services for which the underlying trademarks are registered. | Do not support Recommendation | This recommendation is worded far more broadly than its rationale in the report would justify. This would be used as a club by any complainant who didn't like an outcome of any RPM application, and would permanently bias all of the RPMs against ordinary registrants. We strongly oppose this recommendation. | Significant change required | This recommendation is too vague. If "challenge mechanism" is defined to apply only to Reserved and Premium names, then we would support it. Otherwise, it is open to a variety of misinterpretations, possibly years from now. | No opinion | Do not support Recommendation | There has not been shown sufficient justification for the Sunrise Period at all. | Do not support Recommendation | Sunrise has not been shown to be necessary. It is little used, and there has not been a flood of abusive registrations in the new gTLDs. | Support Recommendation as written | Do not support Recommendation | Limiting Sunrise Registration to approximate the bounds of the underlying legal rights that it seeks to vindicate is the minimum needed to make Sunrise acceptable. | Make the TMCH searchable by the public. | Yes | Abuses are very hard to measure because the TMCH is not readable by the public. However, the Analysis Group report shows the presence of common dictionary words, registered for the purpose of gaining privileged access to new domain names. | No, I wish to continue to the next section | Support Recommendation as written | Yes | Claims Notices are intimidating to legally unsophisticated registrants. | Notices should be written in more plain language and explain that while trademark holders may have rights to certain uses of a string, the potential registrant has rights as well. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||
58 | 5/4/2020 19:57:41 | Ted Chang | None - Individual | No | Do not support Recommendation | Please drop this nonsense. Why do poor people have to suffer for just trying to make a living? How much damage can anyone make without this nonsense proposal? Is it going to make rich people lose their superyachts without this proposal? I don't think so. If you have a soul or heart left in you, please just drop this nonsense proposal of yours. | Instead of using all these law jargon to make things harder to understand, it's better to just drop this entire nonsense proposal. | Significant change required | If the whole URS nonsense is dropped, everything else is irrelevant. | Significant change required | If the whole URS nonsense is dropped, everything else is irrelevant. | Significant change required | If the whole URS nonsense is dropped, everything else is irrelevant. | Why bother when this whole URS nonsense should be dropped in the first place? | Why bother when this whole URS nonsense should be dropped in the first place? | Significant change required | If the whole URS nonsense is dropped, everything else is irrelevant. | Why bother when this whole URS nonsense should be dropped in the first place? | Why bother when this whole URS nonsense should be dropped in the first place? | Why bother when this whole URS nonsense should be dropped in the first place? | Do not support Recommendation | Can't you just stop this nonsense? But you can't, can you? Surely doing very evil things to poor people who are just trying to make a small living will just be very satisfying to you, am I right? | None. Irrelevant if you just get rid of this whole URS nonsense. | By not developing them. Irrelevant if you just get rid of this whole URS nonsense. | Nobody, if you just get rid of this whole URS nonsense. | No, if you just get rid of this whole URS nonsense. | Significant change required | Why bother when this whole URS nonsense should be dropped in the first place? | Do not support Recommendation | Unnecessary amendments to make rich people richer? Wow, you really have no heart nor soul do you? | No | Significant change required | How many more unnecessary questions will there be? All of them are unnecessary if you just drop this whole URS nonsense. | Do not support Recommendation | How many more unnecessary questions will there be? All of them are unnecessary if you just drop this whole URS nonsense. | Nobody, if you just get rid of this whole URS nonsense. | None, if you just get rid of this whole URS nonsense. | None, if you just get rid of this whole URS nonsense. | None, if you just get rid of this whole URS nonsense. | If you just get rid of this whole URS nonsense there won't be fees in the 1st place. | There should only be penalties for complainants since they are expert abusers and have all the richest resources anyway. Respondents are the real victims here for f's sake. | There should only be penalties for complainants since they are expert abusers and have all the richest resources anyway. Respondents are the real victims here for f's sake. | There should only be penalties for complainants since they are expert abusers and have all the richest resources anyway. Respondents are the real victims here for f's sake. | Significant change required | All irrelevant if this whole URS nonsense is dropped. | Significant change required | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | Do not support Recommendation | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | Support Recommendation as written | There won't be a "challenge mechanism" if this whole URS nonsense is dropped in the 1st place. | Do not support Recommendation | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | Do not support Recommendation | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | Do not support Recommendation | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | Significant change required | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | Significant change required | Who the hell is this "Sunrise"? Why the hell are you letting some 3rd party decide YOUR policies? All these are irrelevant if you drop this whole URS nonsense. | The best remedy? KILL THIS URS NONSENSE ALREADY. | Yes | This whole URS nonsense is a major abuse against human rights and livelihoods. | No, because I'm not rich enough to buy domains at such high prices. | Not a registry operator, but marks should at least be pre-validated. | Yet another unnecessary question if this whole URS nonsense is dropped. | Significant change required | Irrelevant if this whole URS nonsense is dropped. | Yes | Giving rich people more room to do as they wish against the poor is just pure injustice. | Yes, by dropping this whole URS nonsense. | Do not support Recommendation | Irrelevant if this whole URS nonsense is dropped. | |||||||||||||||||||||||||||
59 | 5/4/2020 22:17:00 | Brian Winterfeldt and Griffin Barnett | Winterfeldt IP Group | Yes | These comments are submitted on behalf of the Global Brand Owner and Consumer Protection Coalition (GBOC). GBOC is an organization of global industry-leading businesses and brand owners working together to address common concerns in the online consumer and brand protection space. Members of GBOC represent leaders in software and technology, consumer goods, hospitality, and apparel, among other sectors. | Support Recommendation as written | No | Publication of details in the context of a legal proceeding is necessary for transparency and due process, and does not violate GDPR. Parties can already request redaction of such details if necessary to protect sensitive information, mitigate identity theft issues, etc. without the need for a URS Rule change. | Support Recommendation as written | Support Recommendation concept with minor change | Rather than relying on the potentially subjective determination of “predominant language of the Respondent” these notices should be sent in English and the language of the registration agreement (if not English). Otherwise, we support. | Do not support Recommendation | URS provider compliance is already possible through ICANN Compliance, on the basis of the MOUs and URS Rules/Requirements applicable to Providers. Thus, this recommendation is unnecessary and could simply lead to confusion if implemented. That said, if there is overwhelming support to retain this recommendation, we can live with it, but again would first identify whether existing Compliance processes are adequate and if not, why not. | Support Recommendation as written | Do not support Recommendation | We do not believe such “educational materials” are needed, and would simply impose an implementation burden and cause more problems than they would solve. We have not identified a meaningful problem in terms of consistency of URS decisions, nor a meaningful absence of information about the URS to inform all parties that might be involved in a URS case about the nature of the proceeding, requirements, etc. | In the event Recommendation #6 is retained, we suggest adhering the content and format to a similar approach employed by WIPO in its Jurisprudential Overview 3.0. | These materials could be developed by the IRT, with input from URS Providers. | ICANN should bear the cost as part of implementation for this PDP. | Yes: Translations in the UN6 languages would be appropriate. | Support Recommendation as written | Support Recommendation as written | Yes | Do not support Recommendation | The URS also provides rules regarding determining the language of a proceeding. Other Recommendations also elaborate on this matter. This particular recommendation therefore seems unnecessary, as Panels are already well-equipped to make this determination on a case by case basis, pursuant to the existing Rules and proposed supplemental language in other PDP Recommendations. Further, in nearly all cases, P/P services are removed when a URS is filed, thus enabling a proper language determination to be made. URS Recommendation 1 will also facilitate this process. | Significant change required | While we do not oppose the availability of the proposed materials, we would note that many such materials already exist, so we would prefer not to duplicate efforts to re-create materials that are already adequate for the intended purpose. To the extent the WG determines that a need for further materials really exists, we would encourage a thorough review of existing materials provided by ICANN and individual URS Providers and only extending or unifying these materials in the implementation stage. | This should be a joint effort between ICANN Org and URS Providers, with oversight by the WG IRT. | Each URS Provider should establish a dedicated non-public email address that other Providers can use to confirm whether a new URS case has been filed involving a domain name already subject to an existing case with the other Providers. This administrative check should be part of the URS process, if not already being done by Providers. | We defer to the URS Providers regarding these fees, as they are mainly intended to cover their additional administrative costs to handle late responses. We believe they are likely reasonable. | Penalties for abusive complainants are adequate. There are currently no penalties for “abusive respondents” and it is not clear what conduct would constitute abuse on the part of a respondent in the context of how they participate in a URS proceeding. That said, we would support in principle certain penalties for abusive respondents, applicable for conduct such as the filing of vexatious supplemental materials, making false statements, or seeking to unreasonably delay or frustrate a URS proceeding. Such penalties should be commensurate with penalties for abusive complainants but without jeopardizing due process under the URS generally. | Other: See comments above | See comments above | Significant change required | While we support maintaining the status quo regarding parts 1 and 3 of this Recommendation, we strongly support a change to the status quo for part 2. In particular we would support expanding the matching rules for purposes of Trademark Claims only (not Sunrise) to any variation in which the mark is contained – we believe this important in terms of deterring bad faith registrations that rely on variants and not exact matches of a TMCH-recorded mark and to enhance the ability of TMCH-recorded mark owners to more robustly monitor new registrations for possible infringement and bad faith registration/use. False positives generated through this approach could be overcome through additional language in Claims Notices to registrants explaining the possibility of false positives and to evaluate their registration with this in mind, and brand owners receiving such false positive notices would be able to easily disregard them. We encourage the Working Group to reconsider this section of the recommendation with this in mind, and would urge the Working Group to instead adopt a recommendation supporting expanded matching for TM Claims for all “mark contained” variations. We suggest engaging providers of online trademark monitoring services to provide additional information about possible technical solutions to expanding Claims service to marks contained while limiting false positives. | Support Recommendation as written | Support Recommendation as written | This recommendation must be implemented and enforceable for it to have any impact. This would likely require an amendment to the base gTLD Registry Agreement, and specific challenge mechanisms and ICANN Compliance powers to address behavior that runs afoul of this requirement. The TM-PDDRP or PICDRP could be used to address such behavior (in addition to Compliance complaint mechanisms), if appropriately amended to specifically cover this type of activity. | Do not support Recommendation | We support a uniform challenge mechanism to challenge a registry operator’s designation of a name matching a TMCH-recorded mark as a premium or reserved name, and thereby unreasonably inhibiting the relevant brand owner from securing the name either during Sunrise or general availability. In our experience, registry operators will consider changing such designations on an ad hoc basis in response to direct, individual outreach from the brand owner, but there is no uniformity, transparency, or accountability around these informal communication channels, which would be improved through a single uniform mechanism applicable to all registries. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The prior recommendation that registries not employ practices that would circumvent Sunrise should help to mitigate some concerns about how certain registries operated Sunrise or other registry practices aimed at preventing brand owners from reasonably using Sunrise. However, this recommendation must be implemented and enforceable for it to have any impact. This would likely require an amendment to the base gTLD Registry Agreement, and specific challenge mechanisms and ICANN Compliance powers to address behavior that runs afoul of this requirement. The TM-PDDRP or PICDRP could be used to address such behavior (in addition to Compliance complaint mechanisms), if appropriately amended to specifically cover this type of activity. Other than these registry practices, we have not seen substantial evidence of other unitended effects of the Sunrise Period – any comments seeking changes to Sunrise policies bear the burden of proof that such problems exist and are reasonably pervasive enough to warrant policy changes. | Yes | The abuses we have identified are in the nature of practices adopted by registry operators that have had the effect of circumventing use of the Sunrise period by brand owners, such as through reservation and post-Sunrise release of TMCH-recorded names and through prohibitively high and discriminatory pricing applied to Sunrise registrations. Examples of registries that used such practices include .SUCKS and .FEEDBACK, although there may be others. These abuses are well-documented, including for example in the .FEEDBACK PICDRP report and related ICANN Complaints Office complaints. | As a representative of brand owners, we personally did not encounter struggles with the way ALP, QLP, or LRPs were integrated with Sunrise. | Yes | We represent certain trademark owners who use non-English scripts or certain special non-ASCII characters in certain of their trademarks. We encountered some issues in having these marks recorded in the TMCH, due to some discrepancies between the marks as entered into the TMCH system and supporting documentation (including proof of use). We were able to resolve these issues through communication with the TMCH operator, but additional TMCH examination/validation guidance around this issue could be helpful in facilitating more seamless review and validation by the TMCH of such marks. Once the marks were entered into the TMCH, we did not experience issues participating in Sunrises, although if a particular registry does not support certain IDNs in which the mark is represented (including certain non-ASCII characters), this could present technical challenges. | All gTLD registries should support all non-ASCII characters and IDN scripts to the extent technically feasible and not commercially unreasonable. | Support Recommendation as written | Other | It appears that in general the Claims Notice is working as intended, but could likely be improved to enhance comprehension among laypersons and to provide the Notice in additional langauges to aid comprehension by prospective registrants for whom English is not a native language. | We support reviewing and redrafting the Notice in the implementation stage of this PDP, with an eye toward making it more user-friendly, comprehensible to laypersons (i.e. avoiding overly-legal terminology), and adding resources for understanding the Notice in additional languages and resources for understanding the legal implications of the Notice in more detail. We will be happy to participate in the implementation process to help craft an updated version of the Notice along these lines. | Support Recommendation as written | ||||||||||||||||||||||||||||||||||||||||||||
60 | 5/4/2020 22:20:08 | Christine Haight Farley & Pat Aufderheide | American University | No | No, I would like to continue to the next section | Do not support Recommendation | This policy change would allow the trademark owner to amend the Complaint with registrant data which was redacted for privacy reasons (including GDPR and proxy registrations). Although the rationale of the working group was to allow trademark owners to identify registrants who have engaged in a pattern of bad faith registrations, the wording of this recommendation is not so narrow. Since the URS is a low-cost, low-overhead proceeding, the processes are streamlined by The Forum (the largest of the URS providers). If the trademark owner amends its complaint, that data will be published with the decision absent any further interference. Accordingly an individual’s name, or an organization’s location, may be disclosed in seeming contradiction to applicable personal and sensitive data protections, such as the GDPR. And curiously, such data would be disclosed even if the registrant wins. Any disclosure recommendation should be much more closely tied to the goal of disclosing those with a pattern of proven bad faith registrations. Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | Yes | See above. The disclosure of redacted and private data of individuals, organizations, and businesses must be done only to further the “purpose” presented in the Working Group – helping disclose those with a pattern of proven bad faith registrations. Absent such a showing, the registrant data should be published as shown in the public WHOIS/RDDS (as it is today). Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | Yes.Under this recommendation, once the complaint is amended, the redacted and private information is published. Such publication must not be automatic. Publication must only take place when a) the Complainant wins, and b) the grounds include a pattern of bad faith registrations. Even there, there may be compelling reasons for the protected data not to be published, and the Respondent must be able to provide it. Any procedure must take into account that many respondents default, and that there may be language difficulties involved. In no event must the publication of redacted data be automatic and un-reviewed. | Support Recommendation as written | Support Recommendation as written | This is a very important recommendation as the Registrant must be sent notice by all of these means in hopes that one reaches them. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The materials should include an explanation of the importance of giving rationales so that registrants, claimants, and others can understand the rationale of the decision. They should include model “good” decisions, which should include a short and clear statement of the facts (or their absence) leading to the relevant findings. The materials do not need to be extensive, but they should be clear that merely cutting and pasting the URS policy is not an acceptable decision. | The materials should be developed in consultation with stakeholders | If ICANN develops them as part of implementation followup, they can be developed within the ordinary volunteer consensus-building process. In the alternative, providers could develop their own clear statements. | Yes | Support Recommendation as written | An explanation is fundamental to a legitimate dispute resolution process. The explanation need not be extensive, but it should do more than cut and paste the URS standards: it should explain why those standards have or have not been satisfied. An explanation provides legitimacy to the participants and encourages the decisionmaker to check their reasoning. | No opinion | No opinion | Support Recommendation as written | In order to achieve fundamental fairness, registrants need to be able to understand the proceedings against them. | Support Recommendation as written | ICANN should work with the URS Providersto develop some clear and understandable FAQs for both Complainants and Responents. ICANN’s involvement is important for uniformity. Respondents, in particular, need this information. These materials should be translated into the basic language of key ICANN documents. | No, the response fees are too high for registrants in the Global South. Consistent with the accessibility of this quick, fast proceeding, prices should be set so every Registrant can respond. | The URS is designed to be a quick and simple system for dealing with the easiest cases. There is not much opportunity for respondents to abuse the process because there is only a limited ability to respond, and they don’t get a choice about whether the process is invoked in the first place. Other than prohibiting serial reverse domain name hijackers from invoking the process, there are no realistic penalties that can be imposed by a voluntary arbitration process. Any attempt to set penalties would be inconsistent with the low-cost, relatively low-involvement nature of the URS process, and would inevitably increase costs on participants. The default rates for respondents are already extremely high; any penalties would be uncollectable and create significant administrative costs in tracking, which would have to be borne by someone. | No | They should not be expanded because they cannot be expanded in a way that is fair and consistent with the goal of the URS to be a simple system. | No, I wish to continue to the next section | Significant change required | The TMCH should be more limited. Exact match should be maintained. Common words should be used for Sunrise only and only for related categories of goods and services. Otherwise ICANN would be expanding trademark rights beyond trademark law. Extending rights to a text string in unrelated categories of goods or services expands trademark rights substantially. The Analysis Group report shows that the top ten matched terms in the TMCH are common words: smart, hotel, one, love, cloud, nyc, london, abc, luxury. Because the The most common matches are ones for which these trademark owners are almost certain to preexisting rights. See http://domainincite.com/16492-how-one-guy-games-new-gtld-sunrise-periods; https://onlinedomain.com/2014/04/15/legal/fake-trademarks-stealing-generic-domains-in-new-gtld-sunrises/. | No, I wish to continue to the next section | Support Recommendation as written | Exact matches are already too broad. They discount the non-trademark and nominative fair use allowing trademark owners an unfettered right of first registration in gTLDs what are clearly unrelated to the categories of goods and services for which their trademarks are registered. | Do not support Recommendation | We strongly oppose this recommendation. It is over broad and will lead to misinterpretation. If the recommendation were limited to Premium Names as it was intended, it would be acceptable. As written, however, the recommendation can damage any registries who do not beyond the current consensus policies to further protect trademark owners. | Do not support Recommendation | This recommendation is very vague. It should be limited to Reserved and Premium Names. As written, it could be misinterpreted. | No opinion | Do not support Recommendation | Sunrise Periods should be revised to limit trademarks to their registered categories of goods and services. | Do not support Recommendation | Sunrise Periods should be revised to limit trademarks to their registered categories of goods and services. | Support Recommendation as written | Do not support Recommendation | We strongly oppose this recommendation. It is vitally important that the Sunrise Period be limited to allowing registrations of trademarks only in those gTLDs to which the trademark is logically related. Othewrise, the ICANN policy goes beyond trademark law to allow ownership of strings and words outside context or categories of goods and services. | The Analysis Group report and news stories (links above) shows that some trademark owners are registering common words for the purpose of gaining privileged access to new domain names in areas completely unrelated to their trademark rights. In doing so, they are depriving legitimate noncommercial organizations and entrepreneurs of their ability to register a domain name. These unintended effects should be more closely reviewed, and corrected, by the RPM WG. | Yes | The Analysis Group report and news stories (links above) show that trademark owners are registering common words in the TMCH. The secrecy and lack of transparency in the TMCH prevents any public investigation into abuse and misuse of Sunrise. This invites further abuse. See https://onlinedomain.com/2014/04/15/legal/fake-trademarks-stealing-generic-domains-in-new-gtld-sunrises/ (identifying 330 domain names for terms such as social, cloud, and direct (registered in Switzerland as trademarks for pens) registered across multiple unrelated gTLDs in Sunrise). | No, I wish to continue to the next section | Support Recommendation as written | Yes | The TM Claims notice is too difficult for most potential registrants to understand. It is too intimidating. These issues have adequately raised and should be cured soon. | Written in much clearer and more straightforward language with a fair and balanced explanation; and translated into many languages. | Support Recommendation as written | Translations are required for all registrants to understand the notice. | |||||||||||||||||||||||||||||||||||||||||
61 | 5/4/2020 22:44:50 | William | First Place Internet, Inc. | Yes | First Place Internet, Inc. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
62 | Rafik Dammak | Noncommercial Stakeholders Group | No | Do not support recommendation | This policy change would allow the trademark owner to amend the Complaint with registrant data which was redacted for privacy reasons (including GDPR and proxy registrations). Although the rationale of the working group was to allow trademark owners to identify registrants who have engaged in a pattern of bad faith registrations, the wording of this recommendation is in no way tied to this goal.
Since the URS is a low-cost, low-overhead proceeding, the processes are streamlined by The Forum (the largest of the URS providers). If the trademark owner amends its complaint, that data will be published with the decision absent any further interference. According an individual’s name, or an organization’s location, may be disclosed despite the protection of this data under the personal and sensitive data protections of the GDRP and completely in violation of these protections and privacy rights. Further, the data would be disclosed even if the respondent wins. Such disclosure – without regard to the “purpose” for which the PII is being obtained and disclosed – is a violation of privacy laws and principles. Any disclosure recommendation must be much more closely tied to the goal of disclosing those with a pattern of proven bad faith registrations. Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | Yes | As above, the disclosure of redacted and private data of individual, organizations and businesses must be done only to further the “purpose” presented in the Working Group – helping disclose those with a pattern of proven bad faith registrations. Absent such a showing, the registrant data should be published as shown in the public WHOIS/RDDS (as it is today).
Making nondisclosure contingent on action by the registrant is insufficient because the vast majority of URS cases do not generate a response from registrants, who may not understand that a default will expose their personal information. | Yes, once the complaint is amended, the redacted and private information is published. Such publication must not be automatic (and legally may not be). Publication must only take place when a) the Complainant wins, b) and the grounds include a pattern of bad faith registrations. Even there, there may be compelling reasons for the protected data not to be published, and the Respondent must be able to provide it. Any procedure must take into account that many respondents default, and that there may be language difficulties involved. In no event must the publication of redacted data be automatic and unreviewed – that would be a violation of law and private rights.
| Support Recommendation as written | Support Recommendation as written | This is a very important recommendation as the Registrant must be sent notice by all of these means in hopes that one reaches them. | Support Recommendation as written | Support Recommendation as written | Support Recommendation as written | The materials should include an explanation of the importance of giving rationales so that registrants, claimants, and others can understand the rationale of the decision. They should include model “good” decisions, which include a short and clear statement of the facts (or their absence) leading to the relevant findings. The materials do not need to be extensive, but they should be clear that merely cutting and pasting the URS policy is not sufficient for an acceptable decision. | The materials should be developed in consultation with stakeholders. | If ICANN develops them as part of implementation followup, they can be developed within the ordinary volunteer consensus-building process. In the alternative, providers could develop their own clear statements. | Yes | Support Recommendation as written | An explanation is fundamental to a legitimate dispute resolution process. The explanation need not be extensive, but it should do more than cut and paste the URS standards: it should explain why those standards have or have not been satisfied. An explanation provides legitimacy to the participants and encourages the decisionmaker to check their reasoning. | No opinion | No opinion | Support Recommendation as written | [Anything about fundamental fairness/need for registrants to be able to understand proceedings against them would be good] | Support Recommendation as written | ICANN should work with the URS Providers on clear and understandable FAQs for Complainants and Respondents. ICANN’s involvement is important for uniformity. Respondents, in particular, often have no idea of what the URS proceeding in and how they might respond. These materials should be translated into the basic language of key ICANN documents. | No, the response fees are very, very high for registrants in the Global South. Consistent with the accessibility of this quick, fast proceeding, prices should be set so every Registrant can respond.
Alternative answer: The limited data shows that Respondents from US, China, Australia and Japan are paying response fees. In the data analyzed by Rebecca Tushnet’s research assistants, roughly 1/3 of late responses came from the US, which is higher than the US representation in the database generally. The price may be unaffordable for Respondents from Africa and Latin America. Discounts should be allowed for these regions. | The URS is designed to be a “quick and dirty” system for dealing with the easiest cases, even easier than UDRP cases. There is not much opportunity for respondents to abuse the process because there is only a limited ability to respond, and they don’t get a choice about whether the process is invoked in the first place. Other than prohibiting serial reverse domain name hijackers from invoking the process—which doesn’t seem to be a real problem yet—there are no realistic penalties that can be imposed by a voluntary arbitration process. Any attempt to set penalties would be inconsistent with the low-cost, relatively low-involvement nature of the URS process, and would inevitably increase costs on participants in the system who have not been identified as wrongdoers. The default rates for respondents are already extremely high; any penalties would (1) be uncollectable and create significant administrative costs in tracking, which would have to be borne by someone; (2) deter legitimate responses. For (1), it is worth noting that US jurisdictions can spend much more money on administration than they collect when they fine populations who can’t or won’t pay. | No | They should not be expanded because they cannot be expanded in a way that is fair and consistent with the goal of the URS to be a simple system. | Significant change required | The TMCH should be more limited. Exact match should continue and be maintained. If a dictionary term is used, it should be used for Sunrise only for related categories of goods and services. Anything else is an overreach of TM rights and claims: ICANN has long indicated its goal of not expanding trademark rights beyond what is granted by national authorities, and extending rights to a text string in unrelated categories of goods or services expands trademark rights substantially. This expansion has major effects: the Analysis Group report shows that the top ten matched terms in the TMCH are dictionary terms with only limited trademark rights: smart, forex, hotel, one, love, cloud, nyc, london, abc, luxury. Because the TMCH is secret, we do not know how many other terms in the TMCH are similar dictionary terms, but we do know that the most common matches are ones for which potential registrants are almost certain to have legitimate uses. See also http://domainincite.com/16492-how-one-guy-games-new-gtld-sunrise-periods (discussing “cloud” registrant, who also claims “direct” and “social” and whose client claims “construction” and “build,” claimed as a trademark for pens); https://onlinedomain.com/2014/04/15/legal/fake-trademarks-stealing-generic-domains-in-new-gtld-sunrises/ (same registrants also claim “shopping,” “808,” “aloha,” “dating,” “vacation,” “tickets,” “finance,” “storage,” and “holiday”).
TM+50 should be deleted as it never arose through a Multistakeholder process. [optional] | Support Recommendation as written | Exact matches are already too broad. They discount the non-trademark and nominative fair use allowing trademark owners an unfettered right of first registration in gTLDs what are clearly unrelated to the categories of goods and services in which their trademarks are registered. | Do not support Recommendation | We strongly oppose this recommendation as it overbroad and stands to be misinterpreted in many ways. The context says that this recommendation is intended to be limited to Premium Names (domain names selected and then sold by new gTLDs at high prices), and if that were the case, the recommendation would be acceptable. However, as written, the recommendation can damage any registries who do not go above and beyond the current consensus policies to further protect trademark owners. That is not acceptable. | Do not support Recommendation | This recommendation is very vague. The “context” discussion indicates that it applies to Reserved and Premium Names, and if that is the case, we support the recommendation. But as written, it could be misinterpreted to mean that no challenges processes should be created – which is a conclusion the WG has not studied or made. | No opinion | Support Recommendation as written | If the Sunrise Period continues, then we recommend it continue with the existing terms, per this Sunrise Recommendation #5. But see #6 below. [Response to #6: Because of the secrecy of the Trademark Clearinghouse (something never stipulated or agreed by the initial drafters, the GNSO Council or the ICANN Board), and because the Sunrise Period rights for trademark owners extend far beyond the protected goods and services of their trademark rights (an overreach that the WG appears inclined to keep), we do not support the continuing use of the Sunrise Period. We further note that it was a little-used mechanism, likely indicating that trademark owners do not find it valuable either.]
| Do not support Recommendation | Because of the secrecy of the Trademark Clearinghouse (something never stipulated or agreed by the initial drafters, the GNSO Council or the ICANN Board), and because the Sunrise Period rights for trademark owners extend far beyond the protected goods and services of their trademark rights (an overreach that the WG appears inclined to keep), we do not support the continuing use of the Sunrise Period.
We further note that it was a little-used mechanism, likely indicating that trademark owners do not find it valuable either. | Support Recommendation as written | Do not support Recommendation | We strongly oppose this recommendation. It is vitally important that the Sunrise Period be limited to allowing registrations of trademarks only in those gTLDs to which the trademark is logically related. Otherwise, the ICANN policy goes far beyond law to allow ownership of strings and words outside context or categories of goods and services – which is a right never provided in trademark law. [See response to question 50] | The Analysis Group report and investigative stories show that some trademark owners are registering common words for the purpose of gaining privileged access to new domain names in areas completely unrelated to their legal rights. [See response to question 50.] In doing so, they are depriving legitimate noncommercial organizations and entrepreneurs of their ability to register a domain name. These unintended effects should be more closely reviewed, and corrected, by the RPM WG in this Phase 1. | Yes | The Analysis Group report and investigative stories researched and shared during WG meetings clearly show that trademark owners are registering common words into the Trademark Clearinghouse. [See response to question 50.] The secrecy of the Trademark Clearinghouse prevents any investigation or audit of abuse and misuse of Sunrise except on an anecdotal basis, but it is clear that TMCH misuse is occurring. See https://onlinedomain.com/2014/04/15/legal/fake-trademarks-stealing-generic-domains-in-new-gtld-sunrises/ (identifying 330 domain names for terms such as social, cloud, and direct (registered in Switzerland as trademarks for pens) registered across multiple unrelated gTLDs in Sunrise). | Support Recommendation as written | Yes | The TM Claims notice is very difficult for potential registrants to understand, and very intimidating. These issues have been discussed at length in the WG and we look forward to a newly draft notice soon. | Written in much clearer and more straightforward language with a fair and balanced explanation; and translated into many languages. | Support Recommendation as written | translations are key for registrants to be able to understand the notice. | ||||||||||||||||||||||||||||||||||||||||||||||
63 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
64 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
65 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
66 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
67 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
68 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
69 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
70 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
71 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
72 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
73 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
74 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
75 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
76 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
77 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
78 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
79 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
80 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
81 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
82 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
83 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
84 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
85 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
86 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
87 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
88 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
89 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
90 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
91 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
92 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
93 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
94 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
95 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
96 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
97 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
98 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
99 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
100 |