[Gnso-epdp-team] UDRP Language - Additional Language to Consider

Mark Svancarek (CELA) marksv at microsoft.com
Tue Nov 20 14:18:43 UTC 2018


On the contrary, these are clear factual assertions squarely on point with a charter question.  I believe that they are not well understood by all reviewers and should be included in the report.

Note that the prescriptive language, which we might expect to see during public comment (“require the trademark holder…”) has been removed.

From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> On Behalf Of Mueller, Milton L
Sent: Tuesday, November 20, 2018 5:47 AM
To: Margie Milam <margiemilam at fb.com>; Gnso-epdp-team at icann.org
Subject: Re: [Gnso-epdp-team] UDRP Language - Additional Language to Consider

This appears to be another case of people wanting to put arguments they intend to make in their public comments into the initial report. It is one of the reasons the report is so bloated. I urge us all to stop playing this game. Unless the language changes affect the substance of a recommendation or there is a major error or misrepresentation in the body of the report, it is just not worth it at this stage.
--MM

From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org] On Behalf Of Margie Milam
Sent: Monday, November 19, 2018 2:55 PM
To: Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
Subject: Re: [Gnso-epdp-team] UDRP Language - Additional Language to Consider

HI All-

Per our discussion, here’s the revised wording in yellow. I have simplified the language, by deleting some of the possible policy solutions, although they are examples of how this problem could be addressed.

To answer the questions raised on this thread – the charter specifically calls out for changes to the UDRP in Part 3 so it is important to keep it in this EPDP, as it is relevant to the question o), and points to issues caused directly by the approach taken in the Temporary Specification.   I agree that we can focus on this in a later phase of this EPDP, so that’s reflected in the revised language.

All the best,

Margie

______________



….However this proposed addition was not supported by others who pointed out that in the case of privacy/proxy registrations complainants never often do not have access to registrant information pre-filing.  Some believe that GDRP redaction is distinguishable from a privacy/proxy registration because a privacy/proxy services  is a separate service (associated with a fee) that the registrant chooses, with separate ICANN policies, and a different set of responsibilities.  For example, the proxy service is considered the registrant, and under can face liability under RAA Section 3.7.7.3.

Similarly, concerns were expressed about how this pre-filing disclosures could be implemented in practice as it could result in information being disclosed to anyone claiming to be interested in filing a UDRP complaint, without any obligation to follow this through.  Some believe that this concern can be addressed through policy recommendations to be explored further in a later phase of this ePDP., such as,
o    Require the trademark holder to represent that they have a good faith intent to file a UDRP or other dispute resolution mechanism or cybersquatting action
o    Suggest that Dispute resolution providers be able to audit requests to ensure that the requester filed a UDRP/URS or legal complaint, or in good faith determined that no grounds existed.
o    Require the TM holder to have a TMCH filing with valid SMD file
o    Require the TM holder to agree to data processing standards (i.e. model clauses, or similar).
o    Limitations on the number of records accessible under this purpose

_______________________________________________





From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org<mailto:gnso-epdp-team-bounces at icann.org>> on behalf of "Mark Svancarek (CELA) via Gnso-epdp-team" <gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>>
Reply-To: "MarksvATmicrosoft.com" <Marksv at microsoft.com<mailto:Marksv at microsoft.com>>
Date: Sunday, November 18, 2018 at 9:45 AM
To: Matt Serlin <matt at brandsight.com<mailto:matt at brandsight.com>>, Amr Elsadr <aelsadr at icannpolicy.ninja<mailto:aelsadr at icannpolicy.ninja>>
Cc: GNSO EPDP <gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>>
Subject: Re: [Gnso-epdp-team] UDRP Language - Additional Language to Consider

______________

….However this proposed addition was not supported by others who pointed out that in the case of privacy/proxy registrations complainants never often do not have access to registrant information pre-filing.  Some believe that GDRP redaction is distinguishable from a privacy/proxy registration because a privacy/proxy services  is a separate service (associated with a fee) that the registrant chooses, with separate ICANN policies, and a different set of responsibilities.  For example, the proxy service is considered the registrant, and under can face liability under RAA Section 3.7.7.3.

Similarly, concerns were expressed about how this pre-filing disclosures could be implemented in practice as it could result in information being disclosed to anyone claiming to be interested in filing a UDRP complaint, without any obligation to follow this through.  Some believe that this concern can be addressed through policy recommendations to be explored further in this ePDP, such as,

     *   Require the trademark holder to represent that they have a good faith intent to file a UDRP or other dispute resolution mechanism or cybersquatting action
     *   Suggest that Dispute resolution providers be able to audit requests to ensure that the requester filed a UDRP/URS or legal complaint, or in good faith determined that no grounds existed.
     *   Require the TM holder to have a TMCH filing with valid SMD file
     *   Require the TM holder to agree to data processing standards (i.e. model clauses, or similar).
     *   Limitations on the number of records accessible under this purpose

_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181120/24a5770f/attachment-0001.html>


More information about the Gnso-epdp-team mailing list