[Tmch-iag] T1 Data Locations

Tue Feb 7 00:51:12 UTC 2012

Hi Chris,

I used daily loads for current gTLD's that have been in existence for at
least five years and already have hundreds of thousands registrations.  In
my mind, this represents an extreme CONSTANT peak loading scenario for the
claims period of new gTLDs.  I assumed 1,000 TLDs/year and 50,000
registrations/TLD during the 60-day claims period.

It would be interesting to develop a model using the actual historical data
from the first 60 days of the same gTLD's and see how they compare.  The
ICANN website has registry reports going back 10 years.  I think the average
numbers I used for the full 60 days far exceed the spikes that any of the
gTLD's experienced during the first few days of their launch.

My calculations did not take into account the existing checks-to-creates
ratios as of October, 2011, because this would not be applicable to the
TMCH.  As you know, the reason for this high ratio are "add-storms" that
occur during drop-catching or first-come, first-serve launches.  Most of the
"checks" and "creates" fail because the domain has already been registered.
Oftentimes, registrars will skip the "check" and blindly do a "create" in
order to save precious milli-seconds in the quest to register the premium
generic terms.

Increasing, these premium generic terms are grabbed during sunrise or
auction-based landrushes.  Trademark owners are more likely to defensively
register these generics than simply relying on claims for protection.

Regarding the proposed data flow for claims that was distributed last
Thursday:  With this flow, the ratio of "checks" to "creates" would be
comparing step 2 to step 12.

But if the registrar follows the recommended data flow for claims, most of
their "checks" sent to the registry in step 2 will fail.  The TMCH will see
none of this traffic.  

Let's say that a registrar does not follow the recommened data flow and
instead of running "checks" first, as prescribed in step 2, goes straight to
step 4 and just fires off claims queries without regard if the domains are
available for registration.  Most of these queries should fail since there
should be no reason for registrars to display claims notices for already
registered domain names.  I mentioned earlier that this type of behavior is
a red flag for possible data mining.  This should be a clear violation of
policy and should result in a rapid cut-off and sanctions. 

The key question is: what will be the ratio of successful "checks" to
successful "creates" under the new gTLDs?  It is not definitely not the
ratio of failed checks to creates.  I also would be interested in your
feedback on the other assumptions made, such as the number of TLDs/year-
does 1,000/year sound right?, How about the average number of 50,000
registrations per TLD during claims?

I'm sure there are better or more sophisticated ways of modeling how to size
the TMCH for the extreme case.  Let me know if you're interested in
exploring this further.

Best regards,

Tom

-----Original Message-----
From: Chris Wright [mailto:chris at ausregistry.com.au] 
Sent: Monday, February 06, 2012 5:35 PM
To: tbarrett at encirca.com; tmch-iag at icann.org
Subject: RE: [Tmch-iag] T1 Data Locations

Coming in late here I know,

The problem with your calculations Tom is that you have used average loads,
systems need to be designed to sustain peak loads, not average load
otherwise they go down. This is something that Registries are all too
familiar with. Also, at least in our experience, your ratio of check to
create commands is off by a very large factor its more in the region of
500-1000:1.

Thanks

Chris Wright
Chief Technology Officer
----------------------------------------------------------------------------
-----------
ARI REGISTRY SERVICES
Level 8, 10 Queens Road. Melbourne. Victoria. Australia. 3004.
P  +61 3 9866 3710  F  +61 3 9866 1970  M  +61 401 873 798 E
chris.wright at ariservices.com ariservices.com
----------------------------------------------------------------------------
-----------
ARI Registry Services is an evolution of AusRegistry International.
Follow us on Twitter
----------------------------------------------------------------------------
-----------
The information contained in this communication is intended for the named
recipients only. It is subject to copyright and may contain legally
privileged and confidential information and if you are not an intended
recipient you must not use, copy, distribute or take any action in reliance
on it. If you have received this communication in error, please delete all
copies from your system and notify us immediately.

-----Original Message-----
From: tmch-iag-bounces at icann.org [mailto:tmch-iag-bounces at icann.org] On
Behalf Of Tom Barrett
Sent: Tuesday, 31 January 2012 9:37 AM
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