[Tmch-iag] comments on draft Trademark Clearinghouse implementation model
Shorter, Will
wshorter at verisign.com
Mon May 7 21:08:42 UTC 2012
Hello Karen and IAG participants, Specific comments regarding the draft model;
Part 3 - Sunrise and Trademark Claims Process
3.1
"the use of public/private keys would not be too burdensome, and could be useful for validating requests"
As described, the proposed model seems to be using a hash code with a shared secret key per Top-Level Domain instead of the use of public/private keys.
This approach does not seem to permit a domain name registry to access detailed trademark data for the purposes of executing sunrise eligibility for a new domain name application or for the purposes of resolving multiple sunrise applications for the same second-level domain name. Perhaps there is a yet to be communicated approach on how this data would be obtained, but this seems to be a gap. An alternative approach would be to have the Trademark Clearinghouse sign the relevant trademark information that is passed down from the mark holder to the registrar and finally to the registry. The trademark information could be verified with the Trademark Clearinghouse public key, and since the information is isolated to just the domain name being registered, more information would be available through the channel to make appropriate registration policy decisions. The data can be verified and only the trademark data relevant to the domain name registration would be exposed through the channel.
Some alternatives to protect mark holders information and provide data registries need would include;
The Trademark Clearinghouse creates a signed token that consists of the trademark information (string, type, locality, etc.), the client (registrant to registrar to registry) can pass the plain text trademark information for the registry to apply registration policy decisions. This model does not include the risk of mining since the registrant is explicitly passing the relevant information for the registration request that can be trusted based on the use of a digital signature and verifiable via the Trademark Clearinghouse public key. There are three different models for verifying the trademark information:
1. Mark Code that is verified directly with the Trademark Clearinghouse Service. Additional information could be returned if everything matches the Trademark Clearinghouse service for making registration policy decisions.
2. Mark Code that is verified with the sunrise local file cache. The only thing that is contained in the cache is the code as defined by the current approach.
3. Signed token using PKI. Registrant gets sent or requests a signed sunrise token for one or more domain names. The token can contain any amount of information necessary for the Registry to make registration policy decisions and verified by the Registry using the Trademark Clearinghouse public key.
3.1.1 Sunrise Preparation
Please confirm that once a sunrise preparation file with sunrise codes is created and retrieved by the domain name registry from the Trademark Clearinghouse that updates/versions will or will not be made. The next version of the draft model will need greater specification on the timing and mechanics of these files leading up to each sunrise launch.
3.2 Trademark Claims
" The Trademark Claims service provides a real-time notice to a party attempting to register a domain name that matches a Clearinghouse record, as well as notifying relevant rights holders when a domain name is registered that matches a Clearinghouse record."
At the time of the Trademark Claims Service period the Trademark Clearinghouse provides a local copy with detailed data to the registries, which is not impenetrable to potential mining attempts. A registrant could mine the trademark information through the channel by simply checking a large set of domain names that will return the desired trademark information.
Mark holders should be aware that a lookup service to the Trademark Clearinghouse is the only method to receive a near real-time check for a prospective registrant in matching a domain name to a mark in the Trademark Clearinghouse. When Registries use the proposed local file to respond there will be a delay from the time a mark is inserted into the Trademark Clearinghouse until the Trademark Clearinghouse publishes a new trademark file, the registry pulls down and integrates the new file. This document does not propose how long that delay should occur, but will need to be agreed upon and fully tested to confirm viability.
3.2 Protocols to Send Data to the Clearinghouse
Use of Rsync and SSH with batch processing doesn't fall in line with what has become standard for system to system interaction in domain name industry. Was a protocol like EPP or even REST considered for the interface between the Registry and the Trademark Clearinghouse? The Trademark Clearinghouse acts as a registry of trademarks, and a secure protocol should be used for the system to system interface in place of a batch file interface over Rsync and SSH.
3.2.1 Claims Preparation
In future versions of the model draft please provide the available refresh interval for the claims data, and the file format (UTF-8?).
3.4.3 EPP Protocol Extensions
We certainly appreciate the complexity of integrating the claims service into the domain name purchase flow. However, we are greatly concerned that this document seems to mandate new protocol extensions to the EPP CHECK and CREATE commands without any mention of involving the protocol experts at the Internet Engineering Task Force (IETF) in determining the best solution.
Specifically, the significant alteration of the DOMAIN CHECK command may or may not be appropriate, but there are established processes to follow that involve the appropriate protocol experts who will need to implement and manage the final solution.
Part 5 - Additional Considerations
5.2 Matching Rules & Executive Summary (Variants)
"The trademark claims notice data is obfuscated such that the only way to see the claims notice data is to check based on a specific mark. "
The obfuscated data includes a unique lookup key per domain name that requires generating the lookup key using the domain name with the TLD specific secret key. The unique generated lookup key supports only direct lookup. This works well if there is a direct match of the domain name, but does not work when a domain name can generate a gigantic number of variant strings that would need to be searched one-by-one using the generated lookup key.
"The Clearinghouse will accept trademark information in its native form (i.e., using the Unicode character set); specific variant character mappings must be handled by the registry."
The method which this document requires registries to lookup the data and check all potential variants is untenable in some scripts. The only way to realistically include the variant information in the claims notice is to have access to the raw Unicode strings for those variants. Two solutions include where the registry only performs an exact matching of the domain names with the marks (without any variant rules) or the trademark raw Unicode strings are made available in the trademark claims notice data file so the Registry can effectively check for the matching variants.
Will Shorter
Product Management
wshorter at verisign.com
Office: 703-948-3806
VerisignInc.com<http://www.verisigninc.com/>
[Verisign(tm)]
This message is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission.
From: tmch-iag-bounces at icann.org [mailto:tmch-iag-bounces at icann.org] On Behalf Of Karen Lentz
Sent: Thursday, May 03, 2012 3:14 PM
To: tmch-iag at icann.org
Subject: Re: [Tmch-iag] comments on draft Trademark Clearinghouse implementation model
Jeff,
Yes, I will be following up with some date/time options for scheduling the call.
Thanks for your comments on the timeline. The objective is still to have the Clearinghouse tested and established before any new gTLDs are operational. I am writing a more detailed response on the schedule to try to provide more clarity here. Any feedback on the draft model is still helpful as early as we can get it.
Best regards,
Karen Lentz
ICANN
From: Neuman, Jeff [mailto:Jeff.Neuman at neustar.us]
Sent: Thursday, May 03, 2012 6:36 AM
To: Karen Lentz; tmch-iag at icann.org
Cc: Neuman, Jeff
Subject: RE: [Tmch-iag] comments on draft Trademark Clearinghouse implementation model
Karen,
Do you have an update on the date and time? Are you doing a doodle poll to see when we can be available?
With respect to your response below, can I just clarify that we will be discussing during the call the selection process for the provider and the affect that this nearly 3 month delay will cause on the work that this group (and the community) need to do with the provider to ensure that final requirements on implementation are developed in time.
I also want to get on the record something that I know lots of other people are thinking, but may not have stated outwardly. I am enclosing the original presentation in Dakar from October 26, 2011. Many of us in Dakar thought that the schedule laid out there was extremely aggressive. Some even thought impossible. Now we are 3 months behind (at least). According to the schedule in that presentation, not only was the selection of the provider supposed to happen in mid-February, but the IAG was supposed to have at least a month to work with the provider to finalize the details. Implementation of the requirements was supposed to happen at the beginning of Q2 and testing between the TMCH and the registries/registrars at the end of Q2. Testing was to be completed in Q3 and the TMCH was to go live in Q4. This was all designed such that a new gTLD that was approved and ready to launch 9 months after submitting the application (using the schedule in the Guidebook), could do so in early Q1 2013.
Now with the 1 month delay with the TAS, the earliest launch may not be until late Q1 2013, but still potentially in Q1. Even if that slips to early Q2, how is it going to be possible that the TMCH will be ready? How and when will testing occur with the registries and registrars? Registries and registrars will need time to build out their systems depending on what the final requirements are. We need to get the requirements, analyze how we will need to change our systems to accommodate the new requirements, and put them into our development cycles. As I am sure you are aware, many companies have development cycles that are determined 6 months, 1 year or longer in advance. Then of course, registries and registrars must conduct internal testing, QA, etc.
How will trademark owners have had enough time to get their marks into the TMCH? The collection and entry of that data into the system takes quite some time as well (which others that do this on a daily basis can provide much more insight into).
It is one thing for the application process to be delayed due to a glitch in the application system. That is hard enough to swallow for a number of the applicants. But a further delay once registries have been selected, entered into an agreement with ICANN, entered into the root and ready to launch, simply because the TMCH selected by ICANN is not ready, will be inexcusable. Even if the TMCH is ready, delivering the final requirements to registries/registrars must be done with sufficient time to enable them to be ready to support the launches. ICANN cannot simply state that it has released the final requirements many months late, then just blame the registries, registrars and trademark owners for not being able to launch on time. I can just see the PR-spin. "ICANN has TAS system ready to launch" announced by in Q1 next year and then answering a question from the press stating "I don't know why new TLDs cant launch in Q2....we announced we were ready in Q1."
As you can see, the ripple effect of this delay is tremendous and detrimental to the successful on-time launch of any new gTLD registry.
Best regards,
Jeffrey J. Neuman
Neustar, Inc. / Vice President, Business Affairs
From: tmch-iag-bounces at icann.org<mailto:tmch-iag-bounces at icann.org> [mailto:tmch-iag-bounces at icann.org]<mailto:[mailto:tmch-iag-bounces at icann.org]> On Behalf Of Karen Lentz
Sent: Tuesday, May 01, 2012 2:42 PM
To: tmch-iag at icann.org<mailto:tmch-iag at icann.org>
Subject: Re: [Tmch-iag] comments on draft Trademark Clearinghouse implementation model
Jeff,
With regard to provider announcement and possible participation on the call, at the current time this is still to be determined.
However, one of the things we will cover on the call will be an update on this area with the expected steps/envisioned timeline for milestones going forward.
Best regards,
Karen Lentz
ICANN
From: Jeff Eckhaus [mailto:eckhaus at demandmedia.com]
Sent: Tuesday, May 01, 2012 11:13 AM
To: Karen Lentz; tmch-iag at icann.org<mailto:tmch-iag at icann.org>
Subject: Re: [Tmch-iag] comments on draft Trademark Clearinghouse implementation model
Karen,
Thanks for the update on the timing of the comments and the call. Is there any update to the timing of the reveal of the TMCH provider? Do you believe we will have the provider on the call that is scheduled for the week of May 14-18 to discuss implementation?
Jeff
From: Karen Lentz <karen.lentz at icann.org<mailto:karen.lentz at icann.org>>
To: "tmch-iag at icann.org<mailto:tmch-iag at icann.org>" <tmch-iag at icann.org<mailto:tmch-iag at icann.org>>
Subject: Re: [Tmch-iag] comments on draft Trademark Clearinghouse implementation model
All,
Thank you for the comments and the interest in having a call. I am working on scheduling a call during the week of May 14-18. In light of this, comments can continue to be submitted through Friday, 18 May. I will provide more call details as soon as I can confirm the date/time.
Best regards,
Karen Lentz
ICANN
From: Hong Xue [mailto:hongxueipr at gmail.com]
Sent: Tuesday, May 01, 2012 2:54 AM
To: Karen Lentz
Cc: tmch-iag at icann.org<mailto:tmch-iag at icann.org>
Subject: Re: [Tmch-iag] Keith Barritt comments on draft Trademark Clearinghouse implementation model
Dear All,
I agree with the proposal that a call be scheduled to discuss the details of the implementation model. Q&A would be useful. If taken the call into account, the commentary period should be reasonably extended.
With respect to the substance of the draft, I welcome its reference to the IDN readiness. "The Clearinghouse will accept trademark
information in its native form (i.e., using the Unicode character set); specific variant character mappings must be handled by the
registry." It seems each Registry are obliged to handle IDN variants issues but are not provided any guidance for handling. It would inevitably result in discrepancies. Also, should a Registry notify the TMCH of its variants management policy so as to ensure TMCH to implement that policy in authentication and validation? I feel many details are missing and gaps are wide open.
P.33 refers to "Local Caching at Registry", does it refer to new gTLD registries, not local CH providers? If data could be locally cached, why then service provider must be centralized as one?
Hong
--
Dr. Hong Xue
Professor of Law
Director of Institute for the Internet Policy & Law (IIPL)
Beijing Normal University
http://www.iipl.org.cn/<http://iipl.org.cn/>
19 Xin Jie Kou Wai Street
Beijing 100875 China
On Tue, May 1, 2012 at 3:10 AM, Karen Lentz <karen.lentz at icann.org<mailto:karen.lentz at icann.org>> wrote:
Keith, thank you for these comments which we are reviewing.
As a reminder to all, the draft implementation model and summary of IAG input are available on the wiki and comments are requested by Friday, 4 May. I will send out a reminder notice shortly.
Best regards,
Karen Lentz
ICANN
From: Keith Barritt [mailto:barritt at fr.com<mailto:barritt at fr.com>]
Sent: Wednesday, April 25, 2012 4:07 PM
To: Karen Lentz; tmch-iag at icann.org<mailto:tmch-iag at icann.org>
Subject: Keith Barritt comments on draft Trademark Clearinghouse implementation model
Dear All:
I appreciate and commend all the hard work that ICANN has put into summarizing input from the IAG and in preparing the draft implementation model. However, I do have a few comments below on the draft implementation model.
My primary concern is that there are many instances where the recommendations are somewhat vague and the relative roles of ICANN and the TMC are unclear. In the absence of specific requirements from ICANN upon which to comment, I am concerned that at some point in the future we will be presented with a "final" document that was not fully vetted by the community For example:
Page 4: "Standards ensuring that the Clearinghouse is in the role of 'fact verifier' will be in place, limiting the discretaion that can occur in any result, and creating consistency across the process." While the goal is beyond question, the question remains as to precisely what those standards will be.
Page 10: It is unclear to me if ICANN is proposing to allow entities other than the rights holder to obtain Sunrise registrations. Page 10 refers to the submission of "assignment documentation" if the names do not match, but does not clarify if licensees can qualify. Section 6.2.3 of the "Trademark Clearinghouse" Section of the final Applicant Guidebook states that the "proposed" Sunrise eligibility requirements include ownership of a mark, so a licensee would not qualify under the earlier "proposed" requirements, but what is the final rule going to be? As I have commented during the IAG process, I believe only the rights holder as reflected in the TMC's records should be eligible, for ease of administration and to allow third parties to challenge undeserved Sunrise registrations.
Page 11: "Penalties should be in place to help deter fraudulent submissions." While we all want to deter fraud, it would be helpful to have an opportunity to comment on specific proposed penalties and their triggers. See also page 17 that states "Penalties for failing to keep the information current can include removal of a record." The "can include" leaves the full scope of potential penalties unknown. Will ICANN be specifying the penalties, or will the TMC have discretion that is not subject to community input?
Page 12: It is not clear what "equitable treatment" with respect to verifying registration numbers really means. Does it mean that all rights holders should pay the same to have their rights recorded in the TMC, or that rights holders from jurisdictions where information is not on-line should pay more, since the verification process will be more complex?
Page 13: "[I]t is recommended that the TMC verify that the court existed as of the date of the order . . ." Is this really an ICANN "recommendation" or mandate? Will the TMC have discretion on how to verify certain factual information?
Page 15: Is the "recommended" declaration a suggestion or mandate to the TMC? Will the TMC have discretion on what the declaration will say?
Page 16: Is the "recommendation" that the sample of use be of a particular type a mere suggestion or mandate to the TMC? I also believe that the "without the possibility of confusion" standard is asking the TMC to make a legal judgment beyond its scope. I understand and agree that the TMC needs some discretion in the particulars of what to accept. However, I note that under U.S. trademark law at least, an application for a business license would not be considered use of the mark, as it is not use before the public in a trademark sense. Likewise, the appearance of the mark in a license is not public use. Thus, these two examples should be stricken from the list.
Page 18: "An authenticated Clearinghouse record should be renewed once per year. . . . The renewal process should not require resubmission or re-authentication of information that was previously provided. . . . [i]t is recommended that the annual renewal for the record not require submission of a new sample [of proof of use]. However, submission of a curent sample should be required at a longer interval (e.g. every five years). . ." Are these suggestions or mandates to the TMC? Will the TMC have discretion in how often certain information needs to be renewed?
Page 19: "The Clearinghouse provider should publish and supply notice of any grace period procedures that are instituted." Will ICANN be mandating a grace period, or will the TMC have discretion?
Page 20: "A Sunrise code should be unique per mark." If a "Sunrise code" approach is adopted so that a TMC record can be relied upon only once per Sunrise per new gTLD, I believe this sentence should be "A Sunrise code must be unique per mark."
Other issues include:
1) I continue to believe "verifies" as a single verb suffices in place of "authenticates" and "validates." With each use of "authenticate" or "validate" we will likely see terms like "authenticate the contact information" and "validate the proof of use." Why not just "verify" for both? It has been suggested these are two different activities, but so is checking an elecronic database to verify the trademark registration number and reviewing a paper record to verify a registration's expiration date, but we don't feel compelled to have two verbs for these different activities. I suspect this is a lost cause, but I continue to resist the unnecessary introduction of terms that have specialized meaning when in practice we will likely need to specify what we mean anyway. I can see the conversations with clients now:
Lawyer: "Your filing has been authenticated by the TMC, but not yet validated."
Client: "Huh?"
Lawyer: "The TMC has verified that your trademark registration data is correct, but hasn't yet verified your proof of use."
Client: "Oh, why didn't you say so in the first place?!"
2) I commend ICANN for abandoning the use of "registrant" to refer to a trademark rights holder who has recorded its rights with the TMC. However, I note that on page 37 the term "registrant" is evidently inadvertently used to refer to a rights holder that is applying for a Sunrise registration.
3) The declaration for submission of information to the TMC referred to in Section 2.1.5 on page 12 should be "to the best of the submitter's knowledge," similar to the declaration to accompany proof of use (see page 15).
4) I believe more detail should be provided regarding Sunrise eligibility disputes, and particularly regarding proof of use issues. ICANN should specify that a third party can challenge a Sunrise registration based on lack of use. The role of the TMC and registry in such disputes should be clarified (see pages 42-43). Under Section 6.2.4 of the "Trademark Clearinghouse" section of the AGB, the TMC is to hear challenges regarding Sunrise eligibility requirements, which would include proof of use.
5) Will rights holders be able to submit information to the TMC only for Sunrise, and opt out of the Claims service?
6) Should the TMC validate proof of use only when a Sunrise application is filed to reduce the burden of validation of records for which proof of use may never be an issue, or is it unrealistic to expect the TMC to be able to validate fewer records at Sunrise but on short notice?
7) Can a rights holder submit proof of use after a trademark is recorded in the TMC, in anticipation of a particular Sunrise filing?
Keith Barritt
[Description: Description: Description: Description: http://fishnet.fr.com/C15/Marketing%20Department%20Policies/Fish%20Logos/frlogo.bmp]Fish & Richardson P.C.
1425 K Street N.W.
Suite 1100
Washington, DC 20005
Phone: (202) 626-6433<tel:%28202%29%20626-6433>
Fax: (202) 783-2331<tel:%28202%29%20783-2331>
www.fr.com<http://www.fr.com>
From:tmch-iag-bounces at icann.org<mailto:tmch-iag-bounces at icann.org>[mailto:tmch-iag-bounces at icann.org]<mailto:[mailto:tmch-iag-bounces at icann.org]>On Behalf Of Karen Lentz
Sent: Friday, April 13, 2012 8:34 PM
To: tmch-iag at icann.org<mailto:tmch-iag at icann.org>
Subject: [Tmch-iag] IAG summary and draft Clearinghouse implementation model
Dear colleagues,
Please see attached 2 documents: (1) a draft implementation model for the Trademark Clearinghouse (reflecting many of the inputs from the IAG), and (2) a summary report compiling the feedback received from the IAG process.
These documents are for your review and comment - please submit any comments to the list by Friday, 4 May so that we can also compile these and take them into account.
We do not have any additional IAG calls scheduled currently, although we can schedule a call, or an open webinar to walk through the model, if there is interest in doing so.
These materials have also been posted on the wiki at https://community.icann.org/display/cctrdmrkclrnghsiag/Documents. We look forward to your comments.
Best regards,
Karen Lentz
ICANN
****************************************************************************************************************************
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized use or disclosure is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
IRS CIRCULAR 230 DISCLOSURE: Any U.S. tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.(FR08-i203d)
****************************************************************************************************************************
_______________________________________________
tmch-iag mailing list
tmch-iag at icann.org<mailto:tmch-iag at icann.org>
https://mm.icann.org/mailman/listinfo/tmch-iag
________________________________
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tmch-iag/attachments/20120507/44f48e1a/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 131 bytes
Desc: image002.gif
Url : http://mm.icann.org/pipermail/tmch-iag/attachments/20120507/44f48e1a/image002-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 934 bytes
Desc: image004.jpg
Url : http://mm.icann.org/pipermail/tmch-iag/attachments/20120507/44f48e1a/image004-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3105 bytes
Desc: image001.gif
Url : http://mm.icann.org/pipermail/tmch-iag/attachments/20120507/44f48e1a/image001-0001.gif
More information about the tmch-iag
mailing list