Questions to and Answers from Applicant for .biz, .ebiz, and .ecom

ICANN is in the process of reviewing iDomain'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. State in detail your position as it relates to possible legal claims by certain applicants and/or non-applicant third parties based on alleged trademark, patent or other violations of purported rights in the TLDs identified in your application.

3. If you receive a new TLD, state whether you will indemnify ICANN for claims arising from legal challenges regarding your right to operate the new TLD. If you will indemnify ICANN, identify and describe in detail the resources you propose to utilize for the indemnification.

4. Hypothetically, if you receive .ebiz as a new TLD instead of .biz, describe in detail the effect, if any, on the pro forma financial statements submitted with your application.

5. Hypothetically, if you receive .ecom as a new TLD instead of .biz, describe in detail the effect, if any, on the pro forma financial statements submitted with your application.

6. Identify and describe in detail your estimated SRS availability.

7. Identify and describe in detail the SRS service level to which you are willing to contractually commit.

8. Identify and describe in detail your estimated Whois service availability

9. Identify and describe in detail the Whois service level to which you are willing to contractually commit.

10. Identify and describe in detail the your average and worst case transaction times for the following:

16. Identify and describe in detail the Whois traffic volume to which you are willing to contractually commit.

iDomain Responses:

1. In developing our assumptions regarding registration volume in the .Biz TLD with respect to preparing our financial projections, we assumed that ICANN would award contracts for 5-12 new top level domains, consisting of 1 or 2 unrestricted TLDs and 4 to 10 restricted top level domains. Further, we assumed that, among the restricted TLDs, several could be characterized as appealing principally to commercial markets. We also took into account existing generic and country code TLDs in forming our assumptions. Our registration volume projections at the 50% confidence level reflect these assumptions.

We recognize that ICANN could award contracts for fewer than 5, or more than 12, new TLDs. Further, the mix of unrestricted and restricted TLDs, and the character of restricted TLDs, may differ from our assumptions. We believe that the range of potential registration volumes in the .Biz TLD reflected in our projections for the 10% and 90% confidence levels cover the reasonable range of possible registration volumes under foreseeable scenarios for TLD expansion.

Further, in light of the global Internet statistics presented in a workshop given by Andrew McLaughlin (ICANN Chief Policy Officer) at the Seoul ICANN Workshop (Seoul - 10 July 2000) - http://www.icann.org/presentations/seoul-ajm.ppt (Slide 2 of 33), (in conjunction with other relevant marketing studies), we believe that the figures that we project for the .Biz registry, in combination with the existing generic and country code top-level domains, as well as future TLDs referenced above, are reasonable.

2. iDomains takes seriously the rights of intellectual property owners. This commitment is evidenced by the report, dated Noveber 1, 2000, issued by the Intellectual Property Constituency (IPC) of the DNSO (http://ipc.songbird.com/Proposed_TLDs_chart_nov_00_1st_try.htm). In such report, the IPC awarded iDomains the highest ranking (tied with three other proposals) of the 44 TLD proposals. iDomains is confident, however, that no applicant or non-applicant third party could successfully prevail in any cause of action based upon violation of trademark, patent or other purported rights in the TLDs .biz, .ebiz or .ecom.

We believe that the letter from Louis Touton to John M. Cone, Esq., dated October 23, 2000, posted at http://www.icann.org/tlds/correspondence/biz.com-response-23oct00.htm, and the letter from Louis Touton to Anthony R. Kinney, Esq., dated October 23, 2000, posted at http://www.icann.org/tlds/correspondence/bz-response-23oct00.htm, accurately summarize the current state of the law on these issues.

iDomains would deem any action brought on such grounds "frivolous" and in addition to vigorously defending this action would seek immediate sanctions under the applicable national laws.

3. iDomains is prepared to indemnify ICANN, its board, officers and employees for claims arising from legal challenges regarding iDomains' right to operate the new TLD to the extent that such indemnity obligation is not inconsistent with the indemnification provision currently contained in the USC/ICANN Transition Agreement or any other indemnification provisions ICANN has entered into, or will enter into, with any other sponsoring organization or registry operator.

In furtherance of the contractual obligation of the company to indemnify ICANN as contemplated above, iDomains is prepared to secure insurance and/or indemnity bond vehicles in reasonable coverages and amounts. iDomains has made preliminary investigations into insurance products that may be available for such purposes.

4. iDomains' pro-forma financial statements are based on the operation of a registry for the TLD .biz. While no separate projections were prepared for .ebiz or .ecom, we believe that neither of these two alternatives would enjoy the same level of global success as would .biz., especially in the early years of operation. The phrase "biz" has long enjoyed recognition in many parts of the world as a generic abbreviation for the word "business". We believe that it would require a greater commitment of iDomains' resources, both in terms of personnel and marketing dollars, to develop market awareness for the .ebiz or .ecom TLD strings. The requirement to so commit such resources would obviously impact the flexibility of the company to allocate such resources to other, more targeted, marketing programs, and other aspects of its operations. Further, due to the need to engage in more up-front market awareness building, we believe that registration volume will be materially negatively impacted, especially in the early years of operation when cash flow is so important for developing the registry and the market.

Accordingly, it is the strong preference of iDomains to operate the registry for .biz, rather than the two alternative strings.

5. iDomains' pro-forma financial statements are based on the operation of a registry for the TLD .biz. While no separate projections were prepared for .ebiz or .ecom, we believe that neither of these two alternatives would enjoy the same level of global success as would .biz., especially in the early years of operation. The phrase "biz" has long enjoyed recognition in many parts of the world as a generic abbreviation for the word "business". We believe that it would require a greater commitment of iDomains' resources, both in terms of personnel and marketing dollars, to develop market awareness for the .ebiz or .ecom TLD strings. The requirement to so commit such resources would obviously impact the flexibility of the company to allocate such resources to other, more targeted, marketing programs, and other aspects of its operations. Further, due to the need to engage in more up-front market awareness building, we believe that registration volume will be materially negatively impacted, especially in the early years of operation when cash flow is so important for developing the registry and the market.

Accordingly, it is the strong preference of iDomains to operate the registry for .biz, rather than the two alternative strings.

6. Expected availability specification: The systems are deemed available as long as the expected response time specification (see response to question 5 below) is met.

CORE expects its systems SRS back-end to be available on a 24x7 basis at a rate of at least 99 percent except for previously announced maintenance. Under normal circumstances, planned maintenance should not exceed 8 hours for a given instance and normally account for less than 1 hour per week. Planned maintenance is announced by electronic mail at least two weekdays prior to its start.

7. We are willing to contractually commit to the availability specification stated in response to question #1 above.

8. As whois servers will be updated within 30 seconds after the back-end database, the whois servers are available for check queries. We expect to have multiple separate whois servers in operation on a 24x7 basis, each of which is expected to be fully available at a rate of at least 95 percent (for a cumulative availability of at least 99 percent) except for previously announced maintenance. Moreover, based on recent experience, complex whois queries (requesting potentially long lists of domains or contacts) will be throttled or handled on separate machines in order to ensure uninterrupted availability for standard whois requests.

9. We are willing to contractually commit to the availability specification stated in response to question #3 above. In addition, we will commit to single record results at sub-second response rates.

10. Expected response time specification: Based on the experience with its existing installation, CORE expects to achieve at least the following response-time features for the future registry SRS within the budget shown in the financial projections. (These figures are currently being met by CORE the existing SRS handling over 900,000 domains and having to deal with the additional complexity of mirroring data with the VGRS/NSI registry through the RRP protocol.)

For SRS back end update and inquire requests, CORE expects the average round-trip response time to remain at less than to 1 second for 95 percent of the requests measured over one calendar month. (Note: in the current CORE SRS, this includes an additional round trip between CORE and the VGRS registry through a single serialized link. As this would not be the case in the .biz registry, the response time would at least be cut in half. The system can accept multiple requests at the same time and relies on queuing mechanisms at various stages within the SRS. The response time is therefore strongly influenced by the read frequency of the SRS. The setting of these parameters is a matter of policy and not of performance. As CORE is an association of registrars, the setting of system parameters is decided by consensus amongst registrars using the system.

As far as check transactions are concerned, CORE currently updates its whois server within 30 seconds after the master database. The registry SRS is expected to have several whois servers updated in the same fashion. As a result, the SRS itself is not saddled with domain check requests and several whois servers are available for these transactions. For each machine, the response time should be below 1 second for 95 percent of single-domain whois queries.

As discussed under D15.2.3. of iDomains’ Registry Operator's Proposal, the CORE SRS performance measurements are not appropriate for comparison with RRP performance measurements because of the fundamental differences in architecture.

As described above, the CORE SRS is based on internal queues which are currently read once per second. This implies a parameter-controlled floor of the response time of currently .5 seconds. This parameter can of course be changed, although this has not been requested up to now. The read process picks up multiple requests, so that several transactions can be executed in the same one-second interval.

In case a transaction cannot be completed, it is queued until it can be executed. The "worst" transaction time is not artificially limited by way of a time-out parameter. However, experience with CORE's current hardware set-up shows times as remaining consistently below 1 second, including the additional serialized round trip between CORE and VGRS, a detour not needed when the SRS acts as a registry.

The worst case for a whois update is 24 hours.

11. We are willing to contractually commit to the specifications stated in response to question #5 above.

12. We expect to have multiple separate whois servers in operation on a 24x7 basis, each of which is expected to be fully available at a rate of at least 95 percent (for a cumulative availability of at least 99 percent) except for previously announced maintenance. Moreover, based on recent experience, complex whois queries (requesting potentially long lists of domains or contacts) will be throttled or handled on separate machines in order to ensure uninterrupted availability for standard whois requests.

13. As discussed under D15.2.3. of iDomains’ Registry Operator's Proposal, the CORE SRS does not support the current RRP definition.

14. As stated in Section E4. of the Description of TLD Policies submitted as part of our application, “All ICANN accredited registrars will be eligible to provide registrar services in the .BIZ registry. iDomains believes that the current competitive registrar model used in the .COM, .ORG and .NET registries has and will continue to provide healthy competition in the market place while providing registrants with a variety of creative services.”

15. Because the nature of the registry being proposed represents such a marked enhancement of the current system, we believe that it will be necessary to complete some initial testing of the new SRS before being able to quantify our contractual commitment in this regard with specificity.

16. Because the nature of the registry being proposed represents such a marked enhancement of the current system, we believe that it will be necessary to complete some initial testing of the new SRS before being able to quantify our contractual commitment in this regard with specificity.