ARI Registry Services Publishes A White Paper Calling An Alternative Model To Trademark Clearing House

ARI Registry Services, working in consultation with Neustar, Verisign and Demand Media , published today three white papers that outline concerns with ICANN’s current Trademark Clearing House (TMCH) proposal and “provide an alternative model that addresses those concerns whilst meeting all the requirements outlined in the Applicant Guidebook and those further stipulated by ICANN”.

The proposed ICANN model can be found at the following link”

In the cover sheet on the white papers the author said:

“”It’s time for the community to demonstrate its resolve to see ICANN implement a successful and effective Trademark Clearinghouse (TMCH).”

“Let’s be clear here. The current ICANN implementation model and approach is flawed and needs attention.”

“Following more than three months of consultation and negotiation, today I’m pleased to be able to present the domain name and trademark protection industries with an alternative solution for the operation of ICANN’s Trademark Clearinghouse for the new Top-Level Domain (TLD) program.

ARI Registry Services – working in consultation with Neustar, Verisign and Demand Media – have developed three white papers for public review and comment.

The white papers outline concerns with ICANN’s current TMCH proposal and provide an alternative model that addresses those concerns whilst meeting all the requirements outlined in the Applicant Guidebook and those further stipulated by ICANN.”

The first white paper:

“The following is a summary of the issues we perceive with the Trademark Clearinghouse (TMCH) model as is currently proposed by ICANN.

As registrars, registry operators and backend registry service providers, we have significant concerns about the ICANN proposed sunrise model. In summary the issues we have with this model are as follows:

Obscure codes, that do not have any relation to the actual domain label they represent This makes diagnosing errors and providing customer support difficult for both registries and registrars.

No access to trademark information for registries, meaning this information is unable to be used in applying further eligibility rules, for hierarchical allocation models or displayed in the WHOI

This means registries will need to independently request and re-validate trademark information increasing costs for sunrise registrations.The unnecessary burden placed on the TMCH to generate codes for; and o Registries to replicate codes for every eligible (for some definition of eligible) mark in the TMCH, despite only a small percentage of those marks will participating in each sunrise.The unnecessary burden of replicating data to all the different registries.There are alternative models that meet all the objectives of all parties and don’t suffer from any of the issues raised here without requiring replication of TMCH database data.”

You can read the balance of the first white paper here which details each of the above.

In the Second White Paper, ARI lays out the proposed claims model for the TMCH:

”

1 Proposed model for trademark claimsThe following proposed model is offered for trademark claims, improving the proposed ICANN model while meeting all requirements set forth in the Applicant Guidebook.
This proposed model simplifies the ICANN model by separating the claims process in to two key questions:
1. Does a claim exist for this DNS label?; and
2. Give me the claims notice for this DNS label.
This keeps the bulk of the data centralized at the Trademark Clearinghouse (TMCH).
2 Details of the proposed modelThe steps of operation of the proposed model are as follows:
1. The TMCH periodically publishes a list of DNS labels that are known to match trademarks registered in the clearinghouse (see publishing the list below in section 3.1). This list includes a random unique string that is assigned to the label. Registries can download this list and use it in their registration systems to answer question 1 above.
2. A potential registrant approaches a registrar to register a domain name (or submit an application for a domain name).
3. The registrar checks if the name is available using the normal EPP Check mechanism (if this is applicable). The registrar can continue to do all the normal value adds they may offer such as ‘name spinners’ or the like.
4. Once the registrant has identified the name they would like the registrar then uses a new EPP command (to be standardized as part of the EPP extension – this is further discussed in section 4) to check with the registry if the domain name matches a claimed mark. The registry will check to see if the label is present on the list of marks downloaded in step 1.
  1. If there is a match the registry returns the unique string to the registrar and this process continues, otherwise
  2. The registration/application continues as normal for that TLD and we move to step 8.

The registrar now has access to the unique string that they will need to use in the HTTP query below.

1. The registrar then obtains the claims notice content from the Claims Notice Info Service (CNIS) using the HTTP protocol (which is further discussed in section 3.2). As part of getting this information the registrar provides the unique string obtained from the step 4.a. as well as the complete domain name being registered/applied for.
2. The CNIS returns the claims notice information accompanied with a Signed Claims Notice Signature (SCNS) that is digitally signed using the TMCH private key. The SCNS (further described in section 3.4) includes a timestamp of when it was generated, a validity period, and the domain name used in the CNIS request which is all digitally signed using an XML signature. The SCNS can be used by the registrar with a subsequent domain create command and then can be validated by the registry.
The registrant reads and accepts the claim notice.
The registrar then sends the create command to the registry to create the domain name. This command will include the SCNS that must have been obtained from the TMCH. This command will also include the details of who accepted the notice (the client IP address) and a timestamp of when the notice was accepted.
The registry verifies whether or not the DNS label is subject to a claim and that, if so, an SCNS is present.
1. If an SCNS is not required, the domain name is registered as normal, otherwise
2. The SCNS is validated using the TMCH’s public key and the information within is cross checked with the domain name being created. If matching the registration succeeds, if not it fails. The registry records the SCNS identifier included in the SCNS along with the client IP address and acceptance timestamp.
The registry notifies the TMCH of the registered domain names for the purpose of notifying mark holders about the fact that a domain name was registered that matches their mark as well as reporting purposes. These notices will be referred to as ‘Notification Of Registered Name’ notices (NORN) and is described in 3.5. This notice should include the identifier from the SCNS. This combination of the domain name and the SCNS identifier can be used to trace the claims notice end-to-end (TMCH to Registrar to Registry to TMCH). A daily upload of registered domain names to the TMCH is sufficient for this purpose.

This proposed solution works for those that are conducting ‘first come, first served’ or landrush style processes.

You can read the second white paper in full including all of the details of the above outline here

As for the third white paper dealing with Sunrise claims here is the ARI model:

The following proposed model is offered for sunrise, improving the proposed ICANN model while meeting all requirements set forth in the Applicant Guidebook. This proposed model simplifies the ICANN model by decreasing the coupling between the Trademark Clearinghouse (TMCH) and registries. The model is as follows:

The TMCH generates and maintains a global public-private key pair and provides the public key to the registrars and registries. This can be done simply by publishing the public key on the TMCH website. This website should be provided over HTTPs using a digital certificate from a reputable certificate authority. The DNS records associated with this website should be protected using DNSSEC. We believe that there are no issues with security of the public key and anyone in the world can have access to it.
Once the TMCH has authenticated the trademark information provided by the trademark holder, and validated the use requirements for eligibility to participate in sunrise, the TMCH signs the sunrise (trademark) data with its private key. The digitally signed information is referred to as the ‘Signed Mark Data’ (SMD) and is provided to the mark holder. Typically, this would be in the form of a file download from the TMCH website. The SMD includes all of the domain labels (domain names) possible to be used in registrations for the validated trademark (IDN variants excluded).
As each TLD begins its sunrise phase, the mark holder selects a registrar and provides the registrar with the SMD as part of an application for a name within the applicable sunrise period. The registrar (or its reseller) has the ability, if it chooses to, to validate the information using the TMCH public key and then forward the information to the registry to create the application.
The registry verifies the signature of the SMD with the public key and verifies that one of the labels within the SMD matches the domain label being registered. The registry may also then verify any other information in the SMD to ensure it is consistent with the registry’s sunrise eligibility policies. The application, or domain name, is then created.
At the closure of the sunrise round, the registry operator will then make allocations of domain names.
The registry notifies the TMCH of the registered domain names for the purpose of notifying mark holders about the fact that a name was registered that matches their mark as well as reporting purposes. These notices will be referred to as ‘Notification of Registered Name’ notices (NORN). We believe that a daily upload of registered names to the TMCH is sufficient for the purpose of generating NORN notices.

This solution also works for those that are conducting ‘first come – first served’ style sunrise processes.

You can read the details on the ARI Sunrise Plan for the TMCH here