[GNSO-RPM-WG] Edits and updates

Griffin Barnett Griffin at Winterfeldt.law
Mon Oct 26 15:47:45 UTC 2020


I don’t agree with your proposed revisions to this text.  I think the previous language more accurately reflected the WG discussions.  First, “TMCH Validation Provider” is not a new concept – we have used this term before to specify Deloitte as compared to IBM who is a “TMCH Provider” but is specifically the database provider and does not perform the validation role.  I think it is a useful distinction that should be preserved for the sake of clarity.  Further, your proposed revised text starting with “(1) mandatory RPMs should only be for word marks….” does not fully capture the appropriate scope of what we agreed to in our recommendations, and also moves away from the crux of the distinction being drawn in that section which relates to appropriate treatment of “trademarks” versus GIs and other types of source indicators that are not “trademarks” specifically.

Accordingly, I would oppose the adoption of these proposed revisions and support the prior version of the text here.

Thank you,



Griffin M. Barnett
Winterfeldt IP Group
1601 K Street NW, Ste 1050
Washington, DC  20006<x-apple-data-detectors://12/1>
griffin at winterfeldt.law<mailto:griffin at winterfeldt.law>
+1 202 759 5836

From: GNSO-RPM-WG [mailto:gnso-rpm-wg-bounces at icann.org] On Behalf Of Paul Tattersfield
Sent: Friday, October 23, 2020 7:14 PM
To: Kathy Kleiman <kathy at kathykleiman.com>
Cc: gnso-rpm-wg <gnso-rpm-wg at icann.org>
Subject: Re: [GNSO-RPM-WG] Edits and updates

Dear All,

Recommendation TMCH #1 Edits and Updates

I am concerned that the new language and the titles, separates and diminishes well-developed recommendation and guidance from each other. The precisely drafted clauses seem to be more separated from the policy principles than in the final language draft which published to the WG list for review September, 14th. The whole point of drafting precise language was to make sure unintended consequences were minimised in a way that is very hard to do with policy principles. It’s really a question of emphasis and weight. It feels the new language is introducing more and more potential for problems down the line.

Someone has introduced the new concept of “TMCH Validation Provider” and I wasn’t aware of this change being flagged to the working group. (Highlighted in the attached document)

This seems to me to be a new concept and potentially infers changes to the role of the TMCH provider whose job is primarily to authenticate rather than validate. Validation currently is for Sunrise and the newly introduced language may lead to the impression that  the working group wished a significant role change. Rebecca & I were very careful to ensure we did not take the ‘validation’ role for entry into the clearinghouse away from the trademark offices alone.

I am not aware of any of the above being highlighted on the call. Ideally I think we should return to the recommendation language of September 14th if there is to be no further discussion.

Context language

I believe the context language was very new and for me password protected until just before the RPM WG call at ICANN 69. So the review time for this language was very short and outside the normal working group weekly meetings times.

Again the Context language seems to me to want to put more distance between the precisely drafted clauses and the policy language. The policy recommendation came from the implementation guidance so this doesn’t seem quite right to say – “The Working Group ultimately agreed on the policy principles reflecting those ideas, which guides the suggested amendment to the Applicant Guidebook (AGB) text in the Implementation Guidance.

The second paragraph of the new context language needs a lot of work. It also just seems to triplicate (and triplicate incorrectly) what is already there twice. If it is necessary it would be an improvement to say:

(1) mandatory RPMs should only be for word marks, not other types of intellectual property or geographical indications; (2) while other types of marks can be entered into an additional/ancillary database maintained by the TMCH Provider, they are not eligible for Sunrise and Claims; and (3) the ability for the TMCH Provider and Registry Operators to offer additional/voluntary ancillary services should be preserved (e.g., via ancillary database).

Best regards, Paul

On Fri, Oct 23, 2020 at 11:20 PM Kathy Kleiman <kathy at kathykleiman.com<mailto:kathy at kathykleiman.com>> wrote:
Hi All,
Attached please find my proposed edits to the Background section of our report. We had a little more interaction with the EPDP report than noted -- and went past the summary wave table to the actual EPDP recommendations to determine that there was no conflict between them and our WG recommendations. I've proposed revisions to the background text to show this process with the steps involved. As a WG, we certainly did our due diligence on this important task!

Best and have a good weekend,

GNSO-RPM-WG mailing list
GNSO-RPM-WG at icann.org<mailto:GNSO-RPM-WG at icann.org>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20201026/f4c3a0b5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11124 bytes
Desc: image001.png
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20201026/f4c3a0b5/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 5910 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20201026/f4c3a0b5/image002-0001.png>

More information about the GNSO-RPM-WG mailing list