ICANN | Questions to and Answers from Applicant for .i

Questions to and Answers from Applicant for .i

ICANN Questions:

ICANN is in the process of reviewing Sarnoff's TLD Application. As outlined in the October 23, 2000 TLD Application Review Update which appears at http://www.icann.org/tlds/tld-review-update-23oct00.htm, ICANN may "gather the additional information [it] require[s] by posing specific questions to applicants in e-mail and requesting a written response."

Keeping in mind the goal to evaluate applications to operate or sponsor new TLDs in as open and transparent a manner as possible, both the questions posed by ICANN and the Applicant's responses will be publicly disclosed on the ICANN website. Accordingly, ICANN requests your reponses to the following questions:

1. Identify and summarize Applicant's assumptions with respect to the existence of other general purpose TLDs in determining the total number of registrations in your application.

2. Identify and describe in detail the your average and worst case transaction time for post to confirmation of acceptance.

3. Identify and describe in detail the service level to which you are willing to contractually commit for transaction time from post to confirmation of acceptance.

Sarnoff Responses:

1. The projections in the application are based on a top down analysis of the market, including the estimated number of Internet users and Internet-enabled devices. We believe the critical factors driving adoption will be the availability of an organized name space for this market (people and devices); inexpensive, fair and equitable access; functionality and technological innovation; and, branding and marketing.

As it is difficult to estimate how many general purpose or specific purpose TLDs will be introduced by ICANN that target the people and web-enabled devices market, we have made no specific assumption about the number of other TLDs created for this space over time, either in competition with the .i TLD or as a complementary name space. Overall, we recognize that there is a great need for the DNS to expand to accommodate the needs of individuals and to create TLDs that can provide a service provider invariant point of contact through which various communications, applications and services can be received.

Given the vast size of this unserved market, we believe that the presence of a large number of TLDs targeting this market, even if they were in direct competition with the .i TLD, would actually help to expand penetration significantly, while also helping to create a greater variety and depth of services offered by various vendors.

Actual registrations are likely to be affected by a number of factors, including the way this market and Web enabled devices actually evolve. The registrations for the proposed TLD also assume a large number of free domain name registrations that account for up to 40% of the total registrations. In addition, it is noted that if the evolution of the Internet and Internet-enabled devices stays on course as per current projections, actual demand for domain name based services could reach 25-30% of the total number of Internet users and devices.

While not a chartered TLD, the naming convention described in the .i TLD application is intended to further the objectives of a TLD for use by individuals and Internet-enabled devices, and is not intended as a "general purpose TLD" per se. The distinction between "chartered" and "general" TLDs among the various applications appears to be drawn between those having a charter policing mechanism, and those not having one. One of the concepts sought to be proven in the .i model is targeting use of a TLD via a structured addressing convention that is more flexible than a strict numeric mapping, but channeled toward individual and device addressability. The pricing structure is intended to promote universal accessibility.

2. The above question does not specify the type of transaction for “post to confirmation of acceptance.” The registry primarily has two types of transactions. The first is DNS requests that need to be resolved. The second is SRS requests for reads or writes to the master domain name database. Since DNS requests do not get “posted”, it is understood that the question refers to SRS transactions.

The transaction time depends on several factors, most of which are beyond the control of the Registry. Some of the major factors are:

i. Processing power of client's PC that originates the transaction. The client is an existing or potential registrant.
ii. Speed and quality of the Internet connectivity between the client PC and the registrar web server.
iii. Load and processing power of the registrar's web server and SRS client server.
iv. Speed and quality of the Internet connectivity between the SRS client server (at the registrar) and the Registry SRS server.
v. Load and processing power of the Registry SRS server and Database server. Among the above, only factor (v) is under the registry’s control. Factor (iv) is partially under the registry's control and is minimized by having multiple 100mbps links to the Internet through Tier 1 providers. Factors (i), (ii) and (iii) are completely beyond the registry's influence. Therefore, in preparing this response, it has been assumed that the transaction time referenced in the question is the delay between an SRS request reaching the Registry SRS server and a confirmation of acceptance sent from the Registry SRS server.

As discussed in section D15.2.10 (Peak capacities) of the Registry Operator's Proposal, the performance of the Registry SRS server is limited by the performance of the database server containing all domain name records. The database being installed is Oracle 8i with Oracle Parallel Server (OPS) running on Sun Enterprise 6500 with 4 processors and using EMC Symmetrix for storage. This setup is capable of supporting 150 write transactions (in the form of an addition, modification or deletion of a domain name record) per second. Additionally, a dedicated read-only Oracle database capable of 500 reads per second will be used when a potential registrant checks for availability of a domain name. Even if the databases are operating at 10 percent capacity, the registry is capable of 15 write transactions and 50 read transactions a second, which translates into 1.3 million writes and 4.3 million reads a day, far exceeding even the highest estimates.

The response time of the database is a function of the server hardware -- the more powerful the hardware, the lower the response time. Based on the proposed hardware configuration, it is estimated that the response time of the database will be 15-20 milliseconds. Therefore, the average transaction time should average 20-30 milliseconds. As a worst-case scenario, the transaction time could reach 200-300 milliseconds as a result of a misconfiguration or a malfunction.

3. We are willing to contractually commit to the faster of (a) 300 milliseconds for transaction time, as defined in the previous question, or (b) the average response time for all similarly situated TLD registries.

For the purpose of this service level commitment, the transaction time can be measured by installing a SRS client server on the same local area network (LAN) as the Registry SRS server at the Registry and initiating a SRS request.

Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.