23 Provide name and full description of all the Registry Services to be provided

Prototypical answer:

In our original application in 2000, we provided a full technical plan complete with systems, operating system specification, and software solutions. We now have a fully functional registry in-house ready to accept EPP requests for the new .SHOP gTLD.

Commercial Connect, LLC established its own internal registry in 2011. We designed our registry system to closely mimic other significant registries so that continuity provisions are designed to become seamless.

In addition, we continue to show our commitment to the e-commerce community by focusing on only one application.

Services offered include:

(1) Operation of the Shared Registration System

SRS Transactions - Registrar Connections - EPP

A registrarʹs access to the SRS can be impacted by two issues; the number of connections and the available bandwidth. Registrar transactions traffic behavior can be divided into two categories; normal transactions and add-storm transactions. Normal transactions can be defined as the transactions generated by normal daily behavior of registrants, e.g., registering new names, modifying existing names, renewing names, etc. Add-storm transactions are those that are generated by attempts by the registrars to register a name that is expiring at a specific date and time. CCLLC has decided that the best solution would be to provide each registrar the same number of connections and to provide a separate connection for dropped domain names as to not impact normal operations.

SRS Transactions - Demand

The Capacity Planning Team estimated peak SRS transactions per second (TPS) based on data collected on existing TLDs.

By extrapolating data from other TLDs, the transaction growth rate can be estimated. An average peak day for SRS transactions is 5% of the total monthʹs transactions.

A peak 5 minutes is 5% of the peak day. The peak 5 minutes is such a large percent of the day because it includes add storm activity. The Capacity Planning Team has concluded that the overall CCLLC SRS must support the following capacities over the first 2 years.

It should be noted that these are very conservative estimates, and assumes that all TLDs will experience the same peak transaction levels experienced by larger, open TLDs. In fact, many of the TLDs, such as brand and community TLDs, will not experience the peak transactions that occur during add storms. However, following a philosophy of estimating conservatively, these plans are based on a high case scenario.

SRS Transactions - SRS Capacity

CCLLC uses this data to analyze the capacity of CCLLCʹs systems, including the EPP and application servers, and the database. In CCLLC’s SRS architecture, the database is the most limiting item. The architecture of the SRS utilizes server clusters for the application servers (EPP and Business policy engines) and the database.

Increasing capacity to those servers is a matter of adding more servers to the cluster. Their current deployed architecture supports 17k TPS. If necessary, we can increase this to 30k TPS in 2013 to maintain 2 times peak demand.

SRS Transactions - Bandwidth Capacity

Using historical registry data, an average SRS transaction size has been determined to be 1.3kb. Since CCLLC staggers the drop times of domains the peak TPS demand is spread out over many hours and over separate connections. As a result of the staggering process only 10% of the overall peak TPS will occur at any given time and will not impact the primary registration connections. This means the registry will need to support 39mbps of bandwidth during an add storm (3,750 x 10,400 bits = 39mbps).

The registryʹs primary and secondary SRS sites both have 200MBps of bandwidth. This is nearly 5 times the estimated demand.

(2) A Unique .SHOP Registry Service—Process Patent-Pending Verification Process for Transactions

As part of a registration for .SHOP the inclusion of a patent-pending verification process for transactions will be performed. In this process we use bank information already collected on an applicant to match against the registration data. If we verify that the information submitted to us matches the registrants bank account information whereby they had to provide photo identifications locally to their bank along with appropriate corporation and⁄or business articles, then we can feel more confident that the applicant is who they claim to be. We will make no claims to guarantee the identity of anyone but will explain that this is a much more confident means of verification than previously existed.

We can provide more information on this technique and process at ICANN’s request.

“Registry Services” are, for purposes of the Registry Agreement, defined as the following: (a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry DNS servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the registry operator is required to provide because of the establishment of a Consensus Policy as defined in Specification 1; (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above.

(3) Provision of WHOIS service

CCLLC operates two active WHOIS sites, each consisting of 3 servers behind a load balancer. CCLLC has tested this configuration in CCLLCʹs lab. Each WHOIS site will be able to support 2875 QPS. This is 5X the estimated 2013 capacity need.

(4) DNS resolution for registered domain names

DNS for Commercial Connect includes 16 name server sites located throughout the world. Each site will contain at least two resolving servers. The domain name servers will support 50K queries per second.

Based on the peak queries per second the estimated bandwidth needed will be 105 Mbps. This is based off of .0014 Mbps X 75,000 queries per sec = 105Mbps for estimated bandwidth [bits per second X queries per second = total bandwidth needed (in bits per second)] .

Each name server will have a minimum of two 100 MBps connection, which is 2x the peak capacity load required.

High Capacity Systems

As described above, each element of the registry has been designed for high capacity. The DNS has over 10 times the estimated query capacity required for all TLDs combined; the SRS over 3 times the estimated domain capacity, and WHOIS over five times the estimated query capacity.


Registry Operator Code of Conduct

1. In connection with the operation of the registry for the TLD, Registry Operator will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or other related entity, to the extent such party is engaged in the provision of Registry Services with respect to the TLD (each, a “Registry Related Party”), to: a. directly or indirectly show any preference or provide any special consideration to any registrar with respect to operational access to registry systems and related registry services, unless comparable opportunities to qualify for such preferences or considerations are made available to all registrars on substantially similar terms and subject to substantially similar conditions; b. register domain names in its own right, except for names registered through an ICANN accredited registrar that are reasonably necessary for the management, operations and purpose of the TLD, provided, that Registry Operator may reserve names from registration pursuant to Section 2.6 of the Registry Agreement;
c. register names in the TLD or sub-domains of the TLD based upon proprietary access to information about searches or resolution requests by consumers for domain names not yet registered (commonly known as, ʺfront-runningʺ); d. allow any Affiliated registrar to disclose user data to Registry Operator or any Registry Related Party, except as necessary for the management and operations of the TLD, unless all unrelated third parties (including other registry operators) are given equivalent access to such user data on substantially similar terms and subject to substantially similar conditions; or e. disclose confidential registry data or confidential information about its Registry Services or operations to any employee of any DNS services provider, except as necessary for the management and operations of the TLD, unless all unrelated third parties (including other registry operators) are given equivalent access to such confidential registry data or confidential information on substantially similar terms and subject to substantially similar conditions.

2. If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will, or will cause such
Registry Related Party to, ensure that such services are offered through a legal entity separate from Registry Operator, and maintain separate books of accounts with respect to its registrar or registrar-reseller operations.

3. Registry Operator will conduct internal reviews at least once per calendar year to ensure compliance with this Code of Conduct. Within twenty (20) calendar days following the end of each calendar year, Registry Operator will provide the results of the internal review, along with a certification executed by an executive officer of Registry Operator certifying as to Registry Operator’s compliance with this Code of Conduct, via email to an address to be provided by ICANN. (ICANN may specify in the future the form and contents of such reports or that the reports be delivered by other reasonable means.) Registry Operator agrees that ICANN may publicly post such results and certification.

4. Nothing set forth herein shall: (i) limit ICANN from conducting investigations of claims of Registry Operator’s non-compliance with this Code of Conduct; or (ii) provide grounds for Registry Operator to refuse to cooperate with ICANN investigations of claims of Registry Operator’s non-compliance with this Code of Conduct.

5. Nothing set forth herein shall limit the ability of Registry Operator or any Registry Related Party, to enter into arms-length transactions in the ordinary course of business with a registrar or reseller with respect to products and services unrelated in all respects to the TLD.

6. Registry Operator may request an exemption to this Code of Conduct, and such exemption may be granted by ICANN in ICANN’s reasonable discretion, if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for its own exclusive use, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (iii) application of this Code of Conduct to the TLD is not necessary to protect the public interest.

Similar gTLD applications: (0)