As an industry insider and technologist, it's always tempting when discussing something new, such as the Trademark Clearinghouse (TMCH), to jump into the gritty details to try solving problems. However, in this case, we would be jumping a step ahead because it's fair to say most of the general community is not well informed about the current implementation challenges around the TMCH. Given that, I will do my best to simplify and relate the technical challenges directly to the business and policy challenges the TMCH is trying to address. So let's start with reviewing the problem set that the TMCH was trying to address.
Registrations, registrations everywhere:
As we all know, brand identity is considered valuable, and the domain name space has had its struggles with determining who has the right to a particular domain name and how it may relate to various forms of registered trademarks, usage, intellectual property and various other considerations. Over Time, the industry has developed dispute mechanisms to resolve contention over domain names and continues to add and refine those processes. We even came up with preventive measures such as "Sunrise" registration periods for new top level domains, allowing qualifying applicants to register their "mark"/domain prior to the public launch of a TLD. Part of the challenge has been that these processes require vigilance on behalf of the mark holders, and with the advent of many new TLDs, this became something of an exponential effort.
Enter the TMCH:
The basic goal of the TMCH is to allow mark holders to register their related domain(s) with one authority, that all TLD operators will recognize. The TMCH will look at each mark registered and verify whether it meets any ICANN mandated qualifiers such as a matching trademark. Once confirmed, the TMCH will store that information for verification by TLD operators and other qualifying parties. This is a big step forward in centralizing this information. Now what happens as a result is:
a) During Sunrise processes for a new TLD, the TLD operator will examine Sunrise applications and check the related domain to confirm its existence in the TMCH. The TLD operator may turn down a Sunrise application if the application does not match information in the TMCH or could, in addition, conduct a separate verification of the domain against other sources such as a country trademark database. At a minimum, though, the TLD operator must use the TMCH during Sunrise.
b) During at least the first 90 days of full TLD operation, all new domain registrations must be checked against the TMCH to see if there are matching entries in the TMCH. If so, the registrant and any mark holders must be notified. Again the first 90 days is mandatory for the TLD operator, but it could also choose to extend the use of the TMCH for as long as they see fit.
Ok, so what's the problem?
So now we come to the implementation challenges. There are a number of smaller issues that can be readily ironed out by technical/implementation teams. However, there are a few larger goals/principles currently causing friction between the TMCH providers/implementers selected by ICANN and those who are required to interact with and use the TMCH. Let's try and describe those.
1) Mark holders ideally want potential harms minimized to their brands and would like to see that a prospective registrant of a domain name already listed in the TMCH is confirmed as "notified" of this before the domain in question goes live.
2) Data stored in the TMCH is referenced by the registry operator and there is a goal to ensure that data is not being used for anything other than its intended purpose, or that any data not necessary to the process is revealed to the registry operator or any other party.
3) There is no dependency/impact on the registration process for either the registrar or registry operator in terms of performance or Service Level Agreement compliance with ICANN.
4) Secondary to number 3 above, but a point worth making, the TMCH provider should not have to be available for registration processes to continue. In other words, the process should be elastic enough to sustain a TMCH provider outage without pausing domain registrations through the TLD space.
ICANN has posted its current implementation plans and they are quite involved. I suggest you have your technical resources review in conjunction with your policy/legal resources. Other counter proposals have also been offered through various ICANN mailing lists and meeting forums. The main debate ultimately centers on implementation details that result from trying to complete the TMCH activities prior to a domain registration occurring. This is an important discussion for TLD operators; there is real cost involved in complying with the current draft proposal. ICANN had stated it would freeze the technical implementation mid-August this summer but now appears to be organizing a mid- to late August technical summit to discuss the implementation.
When they do announce the date of the technical summit, you, or your representative, need to be there.
A final thought. I promised I wouldn't try and solve technical problems in this particular article, but I can't help but point out one small but vital detail that can lead to a much quicker solution. Much of the existing proposal centers on how to achieve the TMCH activities prior to allowing a domain registration. This is not a hard problem to address during Sunrise because all domain registrations start out as provisional application during Sunrise. It becomes a real challenge when we start real-time registration periods that are "first come, first served" and the TMCH notice processes are expected to be completed prior to allowing a domain registration. This again was to minimize potential damage to mark holders. However, I think the same goal is accomplished if we allow the registration but HOLD DNS resolution until the TMCH notice processes are complete. This turns the TMCH process into an arrears process after registration, but it also protects mark holders by disallowing use of the domain until the TMCH notices are complete. From an implementer's point of view and a user of the TMCH, suddenly the technical challenges are significantly reduced and yet the mark holder is just as protected. So as you can see in this scenario, you can "pay me later" and there is no harm versus an extreme effort to try and pay the TMCH process up front.
By Michael Young, Chief Technology Officer at Architelos. He built the first modern EPP Top Level Domain registry in 2001 (.info) and subsequently built and operated the backend systems for numerous gTLDs, ccTLDs, IDN enabled registries and sponsored TLDs such as .org, .mobi, .in, .me and others. Architelos provides new gTLD application guidance and registry management services for clients in the DNS and IP industry. Mr. Young can be reached directly at firstname.lastname@example.org.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services
.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»