[Tmch-iag] T1 Data Locations

[Tom Barrett]

Hi Will,

Thanks for continuing this discussion.  The estimates I referred to were in
the attachment to the email.  You can also access it on the IAG Wiki at
https://community.icann.org/display/cctrdmrkclrnghsiag/Home

I also would like to draw your attention to the revised proposed dataflows
issued by ICANN for this week's call.  The data flow for trademark claims
proposes a streamlined approach where registrars retrieve claims data
directly from the the TMCH.  With this approach, there doesn't appear to be
any need for registries to have copies of the TMCH data, nor presumably
would they then have an SLA for trademark claims.

The time-critical interface becomes the one between the TMCH and Registrars
for processing trademark claims.  There should be a contingency for
registrars if the TMCH does not maintain the required SLA, or there is some
unrelated connectivity issue with the TMCH.

I agree with you that registries will need query access to resolve
sunrise-related conflicts, which does not require the registries to have
copies of the TMCH data. 

I agree with you that there are several dimensions to how the TMCH should
scale:  I address only the peak transactions for sunrise and claims.  But
the number of potential registries, registrars and registrants needing to
query the TMCH could be modeled as well.  The protocols are also on the
table this week for discussion.

I believe that there should be a requirement for the logging of the display
of claims notices.  This would be a key reporting metric to measure the
effectiveness of the trademark claims as a Rights Protection Mechanism.
With this week's proposed data flow for claims, registrars would query the
TMCH directly, which would provide for this logging.  There should not be
any charge by the TMCH to log this event.

Logging this data is the starting point in any efforts to detect attempts at
data mining of the TMCH data. 

Logging the claims notices also allows for a more efficient method of
determining if there was a successful domain name registration during the
claims period.  Since the TMCH would already be aware of what claims notices
were displayed for a particular TLD, it could simply do EPP check queries
against the registry to determine which of the claims notices resulted in a
domain name registration.  This is far more efficient than the registry
querying the TMCH for each new registration to see if a claims notice
exists.  It also completely relieves registries from doing anything related
to trademark claims.
(this is the one change I am suggesting to the new claims data flow)

Best regards,

Tom
EnCirca


-----Original Message-----
From: Shorter, Will [mailto:wshorter at verisign.com] 
Sent: Monday, February 06, 2012 10:56 AM
To: 'tbarrett at encirca.com'; 'tmch-iag at icann.org'
Subject: RE: [Tmch-iag] T1 Data Locations

Hi Tom, thanks for your note. Follow up below;


1.	"After comparing estimates of the maximum volumes for the TMCH"

*	Can you please provide the estimates that you refer to for review? I
missed this data.

2.	"it seems very clear that the TMCH data could be kept solely in a
central database utilizing a technical architecture similar in scale to some
of the existing smaller gTLD registries, such as .MOBI and .TEL"
		
*	Use of solely the query volume is not enough to define architecture
necessary to support the TMCH.  The number of participants and the level of
access is different with the TCMH than with a standard gTLD domain name
registry.  


3.	"This level of architecture for the TMCH could ensure the uptime and
responsiveness required by registries and registrars while satisfying the
trademark owner concerns for data security."
	
*	The TMCH does not have well defined uptime (availability)
requirements for the different interface points (Registrant to TMCH,
Registrar to TMCH, and Registry to TMCH).  The interface between the domain
name registry and the TMCH is more sensitive considering that the domain
name registries have both a contractual response time / availability SLA to
meet, and just as important an established customer experience. I suppose
that ICANN could update new gTLD registry agreements to waive response time
and availability SLA's during these periods or just not measure. I'm really
not sure how ICANN probes could possibly measure or definitively tell if a
Registry is meeting its SLA's during periods when the registry is dependent
on the TMCH.


4.	"The TMCH data is proprietary to trademark owners and is not
currently in the public domain

We agree with and confirm the following:

The TMCH data is proprietary to trademark owners and is not currently in the
public domain Prevention of data mining should be a priority for the TMCH
Distributing the TMCH data makes data mining impossible to prevent
Distribution of the TMCH data is not even necessary given the expected scale
of the TMCH"
----


The TMCH data can be centralized but the data needs to be made available for
the following:
a.	For the domain name registrant to be able to review marks that match
their domain name registration requests during the trademark claims services
period.  
b.	The data needs to be made directly available (e.g. whois-like
service) or indirectly available (e.g. via Registrar), but if there is a
concern with making the data available at all then how can the trademark
claims service period be successfully implemented based on the Application
Guidebook?  
c.	The data needs to be made available to the domain name registries
for purposes of resolving overlapping sunrise domain name applications.
Without this domain name registries may default to first-come-first-servce
or auction selection process which may not meet the needs of the trademark
holders or domain name registries, and potentially result in higher costs
for the community.  
d.	The data could be made available based on different levels of access
and needs.  For example, the TMCH support for the standard sunrise and
trademark claims service period flows should provide for a basic level of
trademark data that is not personally identifiable.  Additional data access
is needed to support resolution of multiple applications for the same domain
name or to meet the specific policies of a registry (there are many ccTLD's
that have reqiured a local presence/mark to register a domain name, for
instance)   

"But the TMCH should also record the display of the claims notice itself,
even if no registration follows."

*	There is no requirement to log the generation of the claims notice.
The key is to identify when someone has accepted and went through to domain
name registration.  What would logging accomplish and what would be logged?
Would the TMCH propose to bill for logging this information?  

Thanks,
Will


Will Shorter
Product Management
wshorter at verisign.com
Office: 703-948-3806

VerisignInc.com


Will Shorter
Product Management
wshorter at verisign.com
Office: 703-948-3806

VerisignInc.com 




-----Original Message-----
From: tmch-iag-bounces at icann.org [mailto:tmch-iag-bounces at icann.org] On
Behalf Of Tom Barrett
Sent: Monday, January 30, 2012 5:37 PM
To: tmch-iag at icann.org
Subject: [Tmch-iag] T1 Data Locations



IAG T1 comments - Distribution of TMCH Data January 30, 2012 Tom Barrett -
EnCirca

The main topic of discussion for the IAG last week was concerned with
distribution of TMCH data.

After comparing estimates of the maximum volumes for the TMCH to the query
volume, uptime and responsiveness of existing registries, it seems very
clear that the TMCH data could be kept solely in a central database
utilizing a technical architecture similar in scale to some of the existing
smaller gTLD registries, such as .MOBI and .TEL.  This level of architecture
for the TMCH could ensure the uptime and responsiveness required by
registries and registrars while satisfying the trademark owner concerns for
data security.

We agree with and confirm the following:
. The TMCH data is proprietary to trademark owners and is not currently in
the public domain . Prevention of data mining should be a priority for the
TMCH . Distributing the TMCH data makes data mining impossible to prevent .
Distribution of the TMCH data is not even necessary given the expected scale
of the TMCH

Please see the attached document for a detailed examination of these issues,
including an analysis of how big the TMCH needs to be compared to existing
gTLD registries.

I look forward to your comments.

Best regards,

Tom Barrett
EnCirca

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4792 - Release Date: 02/06/12