[Tmch-iag] Comments for T1 and T3

[Tom Barrett]

T1: Data Locations and T3: Implementation: Communications protocols

Tom Barrett

EnCirca

 

T1: Data Locations

I support the new proposed data flows for sunrise and trademark claims,
which eliminate the need for distributing any TMCH data to Registries and
Registrars.

 

The community can always revisit this issue if the TMCH vendor is unable to
meet the required SLA's.

 

IAG T3: Implementation: Communications protocols

 

Sunrise Process

 

I wonder if there might be an additional step at the Registry between steps
6 and 7, call it 6.5, where the Registry can perform additional checks for
sunrise or choose to allocate domains with methods other than first-come,
first-served.

 

The Registry may have some eligibility requirements that are based on data
maintained by the TMCH.  Examples include:

-         The jurisdiction of the trademark

-         The jurisdiction of the trademark owner

-         The trademark's goods and services

-         The date of validation (relevant if the TLD has a cut-off date)

 

Does each TLD have its cut-off date for Sunrise?

Are we assuming that in order to be eligible for a specific gTLD sunrise,
the trademark simply needs to be validated before the sunrise application
occurs?  

 

Or will gTLDs have an arbitrary cut-off date in order for trademarks to be
eligible for their sunrise period?  If each gTLD has its own date for
eligibility for the sunrise period, then a validation date check may be
required. 

 

If so, the Registry could decide to either have the TMCH:

- Check this date against the gTLD's eligibility requirement in step 6, or

- Return this date in Step 6 so the Registry can make its own determination
(new step 6.5)

 

 

How should a registry do the lookup to determine authorization to permit
sunrise registration of a given domain name and its auth code?

 

I suggest EPP be used for this purpose as Registries are already familiar
with this protocol.

 

How should a registry notify the TMCH of a successful sunrise registration?

 

I suggest EPP be used for this purpose as Registries are already familiar
with this protocol.

 

Trademark Claims Process

 

My thinking has evolved since we first reviewed this topic and it resembles
the new proposed data flow.  In this flow, the Registrars communicate
directly with the TMCH to check if a claims notice is required and then
again to retrieve the claims data.

 

The registrars will need to develop new code to process claims regardless of
whether they communicate directly with the TMCH or via the Registry.  If the
flow was routed through Registries, then EPP extensions may well be
required.  In the new flow, Registrars will have two interfaces to deal
with.  This places more of a burden on Registrars but is not unprecedented.
For example, for most of its life, the .JOBS registry has had this
requirement.  

 

The benefit of this approach is that Registries are eliminated entirely from
the data flow, thereby streamlining the data flow and making it more
efficient.  The TMCH is able to log every request of a claims notice, which
is crucial to detect data mining.  This approach also eliminates the risk of
data abuse inherent with data distribution.

 

Should trademark claims notices be transmitted via HTTP or web-aware WHOIS
(necessary for NON-ASCII character sets)?

 

When the registrar queries the TMCH to see if a claims notice is required,
the TMCH could respond with a temporary password or auth-code.  The
registrar could then use this temporary password to access a Whois-type
interface or static URL.

 

The Whois approach gives the registrar ultimate flexibility of retrieving
claims data in their preferred language and formatting the notice to match
their user interface.  I would think that this would be preferred over HTTP
since registrars could and should control the end-user experience.

 

There should be a contingency if the Registrar is unable to retrieve the
claims data within a specified time period for whatever reason.  They would
display a default claims notice to the potential registrant and instruct
them how to investigate the claim.  An email could be sent to the registrant
as a secondary step, perhaps containing the temporary password retrieved
from the TMCH.

 

How should a registrar notify the TMCH (or the registry for that matter) of
a trademark claims acknowledgment?

 

Registrar should notify the TMCH directly using EPP.  The Registry does not
need to be in the loop in real-time and could receive a report from the TMCH
if they needed to track this for compliance.

 

How should the registry notify the TMCH of a successful domain registration
during the claims period?

 

The TMCH could query the Registry to learn about which registrations require
a notice to the trademark owner.  Based on new proposed data flow, the TMCH
already knows what claims notices were retrieved by the Registrar.  The TMCH
could perform its own domain-checks for the gTLD (via EPP to the Registry)
to see if any of the domains associated with a claims notice becomes
registered.  When it finds a match, it could then generate the email to the
claimant.  

 

To have the Registry initiate this conversation would be inefficient.
Registries would need to first determine which registrations were associated
with a claims notice.  Registries would either:

-         Notify the TMCH of ALL registrations and let the TMCH sort out
which ones have claims notices, or

-         Query the TMCH for EVERY successful registration to determine
which registrations had a claims notice and then respond back to the TMCH
with the matches

-         Have a copy of ALL TMCH registrable strings and figure it out
themselves

 

None of these options would be as efficient as the TMCH running EPP queries
against the Registry consisting only of the domains that triggered the
display of a claims notice.


Best Regards,
 
Tom Barrett
EnCirca
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tmch-iag/attachments/20120206/af5e49cb/attachment-0001.html