Registry Operator's Proposal

[INSTRUCTION: A Registry Operator's Proposal is to be submitted as part of every new TLD application. In case of applications for unsponsored TLDs, the registry operator will be the applicant and should prepare and submit the proposal as part of the application. In the case of applications for sponsored TLDs, the sponsoring organization (or, where the sponsoring organization has not yet been formed, organization(s) or person(s) proposing to form the sponsoring organization) will be the applicant. The sponsoring organization should select the proposed registry operator, have it prepare the Registry Operator's Proposal, and submit it as part of the application.

Please place the legend "CONFIDENTIAL" on any part of your description that you have listed in item F3.1 of your Statement of Requested Confidential Treatment of Materials Submitted.

The Registry Operator's Proposal should be separately bound (if more than one volume, please sequentially number them) and labeled: "Registry Operator's Proposal." and must cover all topics described below. This page, signed on behalf of the registry operator, should be included at the front of the Registry Operator's Proposal.]

I. GENERAL INFORMATION

D1. The first section of the Registry Operator's Proposal (after the signed copy of this page) should be a listing of the following information about the registry operator. Please key your responses to the designators (D1, D2, D3, etc.) below.

D2. The full legal name, principal address, telephone and fax numbers, and e-mail address of the registry operator.

D3. The addresses and telephone and fax numbers of all other business locations of the registry operator.

D4. The registry operator's type of business entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is organized.

D5. URL of registry operator's principal world wide web site.

D6. Dun & Bradstreet D-U-N-S Number (if any) of registry operator.

D7. Number of employees.

D8. Registry operator's total revenue (in US dollars) in the last-ended fiscal year.

D9. Full names and positions of (i) all directors, (ii) all officers, (iii) all relevant managers, and (iv) any persons or entities owning five percent or more of registry operator.

D10. Name, telephone and fax number, and e-mail address of person to contact for additional information regarding this proposal. If there are multiple people, please list all their names, telephone and fax numbers, and e-mail addresses and describe the areas as to which each should be contacted.

D11. The full legal name, principal address, telephone and fax numbers, e-mail address, and Dun & Bradstreet D-U-N-S Number (if any) of all subcontractors identified in item D15.3 below.

II. BUSINESS CAPABILITIES AND PLAN

D12. The second section of the Registry Operator's Proposal (after the "General Information" section) is a description of the registry operator's Business Capabilities and Plan. This section must include a comprehensive, professional-quality business plan that provides detailed, verified business and financial information about the registry operator. The topics listed below are representative of the type of subjects that will be covered in the Business Capabilities and Plan section of the Registry Operator's Proposal.
[INSTRUCTION: ICANN will extensively review and analyze this section of the Registry Operator's Proposal. The content, clarity, and professionalism of this section will be important factors in ICANN's evaluation of applications. We strongly recommend securing professional assistance from financial and management consultants to aid in the formulation of your business plan, in securing the necessary sources of financing, and in preparation of this section.]

D13. The Business Capabilities and Plan section should consist of at least the following:

D13.1. Detailed description of the registry operator's capabilities. This should describe general capabilities and activities. This description also offers the registry operator an opportunity to demonstrate the extent of its business and managerial expertise in activities relevant to the operation of the proposed registry. The following items should, at a bare minimum, be covered:

D13.1.1. Company information. Date of formation, legal status, primary location, size of staff, formal alliances, references, corporate or other structure, ownership structure.

D13.1.2. Current business operations. Core capabilities, services offered, products offered, duration of provision of services and products.

D13.1.3. Past business operations/entity history. History, date of formation, legal status/type of entity, initial services, duration of provision of services and products.

D13.1.4. Registry/database/Internet related experience and activities. Experience with database operation, Internet service provision.

D13.1.5. Mission. The registry operator's mission and how it relates to expansion into the registry operation field.

D13.1.6. Management. Qualifications and experience of financial and business officers and other relevant employees. Please address/include past experience, resumes, references, biographies.

D13.1.7. Staff/employees. Current staff size, demonstrated ability to expand employee base, hiring policy, employee training, space for additional staff.

D13.1.8. Commercial general liability insurance. Address/include amount of insurance policy, provider of policy, plans for obtaining additional insurance.

D13.2. Business plan for the proposed registry operations. This section should present a comprehensive business plan for the proposed registry operations. In addition to providing basic information concerning the viability of the proposed operations, this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the financial and operational aspects of the proposal. At a minimum, factors that should be addressed are:

D13.2.1. Services to be provided. A full description of the registry services to be provided.

D13.2.2. Revenue model. A full description of the revenue model, including rates to be charged for various services.

D13.2.3. Market. Market definition, size, demand, accessibility.

D13.2.4. Marketing plan. Advertising, publicity, promotion strategy, advertisement development strategy, relationship with advertising firm. Use of registrars and other marketing channels.

D13.2.5. Estimated demand for registry services in the new TLD. Projected total demand for registry services in the TLD, effect of projected registration fees, competition. Please provide estimates for at least 10%, 50%, and 90% confidence levels.

D13.2.6. Resources required to meet demand. Provide a detailed estimate of all resources (financial, technical, staff, physical plant, customer service, etc.) required to meet the estimated demands, using at least the 10%, 50%, and 90% confidence levels.

D13.2.7. Plans for acquiring necessary systems and facilities. Describe plans for acquiring all necessary systems and facilities for providing the proposed services at each estimated demand level. Provide details as to the scope, cost, and vendor for any significant planned outsourcing.

D13.2.8. Staff size/expansion capability. Plans for obtaining the necessary staff resources, capacity for expansion, hiring policy, employee training, space for additional staff, staffing levels needed for provision of expanded technical, support, escrow, and registry services.

D13.2.9. Availability of additional management personnel. How will management needs be filled?

D13.2.10. Term of registry agreement. State assumptions regarding the term of any registry agreement with ICANN or the sponsoring organization. Note that the .com/.net/.org registry agreement has a basic term of four years.

D13.2.11. Expected costs associated with the operation of the proposed registry. Please break down the total estimated operational costs by the sources of the costs for each estimated demand level. Be sure to consider the TLD's share of ICANN's cost recovery needs. (See <http://www.icann.org/financials/budget-fy00-01-06jun00.htm#IIIB>.)

D13.2.12. Expected revenue associated with the operation of the proposed registry. Please show how expected revenue is computed at each estimated demand level.

D13.2.13. Capital requirements. Quantify capital requirements in amount and timing and describe how the capital will be obtained. Specify in detail all sources of capital and the cost of that capital (interest, etc.). Evidence of firm commitment of projected capital needs will substantially increase the credibility of the registry operator's proposal.

D13.2.14. Business risks and opportunities. Describe upside and downside contingencies you have considered and discuss your plans for addressing them.

D13.2.15. Registry failure provisions. Please describe in detail your plans for dealing with the possibility of registry failure.

D13.3. Pro-forma financial projections. Please provide detailed pro-forma financial projections, consistent with your business plan, for the demand scenarios that you estimate under item D13.2.5. The pro-formas should show revenue and expense estimates broken down by detailed categories and should be broken down into periods no longer than quarterly.

D13.4. Supporting documentation. The following documentation should be provided in support of the Business Capabilities and Plan section:

D13.4.1. Registry operator's organizational documents. Documents of incorporation (or similar documents).

D13.4.2. References. A list of significant trade and credit references.

D13.4.3. Annual report. The registry operator's most recent annual financial report (or similar document). Audited financials are preferred.

D13.4.4. Proof of capital. Provide evidence of existing capital or firm commitments of capital. Demonstrated access to necessary capital will be carefully scrutinized.

D13.4.5. Proof of insurance. Please provide proof of the insurance described in item D13.1.8.

III. TECHNICAL CAPABILITIES AND PLAN

D14. The third section of the Registry Operator's Proposal is a description of the registry operator's Technical Capabilities and Plan. This section must include a comprehensive, professional-quality technical plan that provides a detailed description of the registry operator's current technical capabilities as well as a full description of the operator's proposed technical solution for establishing and operating all aspects of the registry. The technical plan will require detailed, specific information regarding the technical capabilities of the proposed registry. The topics listed below are representative of the type of subjects that will be covered in the Technical Capabilities and Plan section of the Registry Operator's Proposal.
[INSTRUCTION: ICANN will extensively review and analyze this section of the Registry Operator's Proposal. The content, clarity, and professionalism of this section will be important factors in ICANN's evaluation of applications. We strongly recommend that those who are planning to apply secure professional assistance from engineers and/or other technical consultants to aid in the formulation of the technical plan and the preparation of the Technical Capabilities and Plan section of the Registry Operator's Proposal.]

D15. The Technical Capabilities and Plan section should consist of at least the following:

D15.1. Detailed description of the registry operator's technical capabilities. This should provide a detailed description of the registry operator's technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce, and access to systems development tools. It should also describe the registry operator's significant past achievements. This description offers the registry operator an opportunity to demonstrate the extent of its technical expertise in activities relevant to the operation of the proposed registry.

D15.2. Technical plan for the proposed registry operations. This should present a comprehensive technical plan for the proposed registry operations. In addition to providing basic information concerning the operator's proposed technical solution (with appropriate diagrams), this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the technical requirements of registry operation. Factors that should be addressed in the technical plan include:

D15.2.1. General description of proposed facilities and systems. Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe in detail buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.

D15.2.2. Registry-registrar model and protocol. Please describe in detail.

D15.2.3. Database capabilities. Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

D15.2.4. Zone file generation. Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

D15.2.5. Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them.

D15.2.6. Billing and collection systems. Technical characteristics, system security, accessibility.

D15.2.7. Data escrow and backup. Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.

D15.2.8. Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.

D15.2.9. System security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.

D15.2.10. Peak capacities. Technical capability for handling a larger-than-projected demand for registration or load. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.

D15.2.11. System reliability. Define, analyze, and quantify quality of service.

D15.2.12. System outage prevention. Procedures for problem detection, redundancy of all systems, back up power supply, facility security, technical security, availability of back up software, operating system, and hardware, system monitoring, technical maintenance staff, server locations.

D15.2.13. System recovery procedures. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures, the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation, the availability of the hardware needed to restore and run the system, backup electrical power systems, the projected time for restoring the system, the procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.

D15.2.14. Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support, support services to be offered, time availability of support, and language-availability of support.

D15.3 Subcontractors. If you intend to subcontract any the following:

· all of the registry operation function;

· any portion of the registry function accounting for 10% or more of overall costs of the registry function; or

· any portion of any of the following parts of the registry function accounting for 25% or more of overall costs of the part: database operation, zone file generation, zone file distribution and publication, billing and collection, data escrow and backup, and Whois service

please (a) identify the subcontractor; (b) state the scope and terms of the subcontract; and (c) attach a comprehensive technical proposal from the subcontractor that describes its technical plans and capabilities in a manner similar to that of the Technical Capabilities and Plan section of the Registry Operator's Proposal. In addition, subcontractor proposals should include full information on the subcontractor's technical, financial, and management capabilities and resources.

By signing this Registry Operator's Proposal, the undersigned certifies (a) that he or she has authority to do so on behalf of the registry operator and, on his or her own behalf and on behalf of the registry operator, (b) that all information contained in this proposal, and all documents attached to this proposal, is true and accurate to the best of his/her/its knowledge and information. The undersigned and the registry operator understand that any material misstatement or misrepresentation will reflect negatively on any application of which this proposal is a part and may cause cancellation of any delegation of a top-level domain based on such an application.

Signature

Henry A. Lubsen, Jr.

Name (please print)

President

Title

iDomains, Inc.

Name of Applicant(s)

September 30, 2000

Date

I. General Information

D2. The full legal name, principal address, telephone and fax numbers, and e-mail address of the registry operator.

iDomains, Inc.

23 West 4^th Street

Bethlehem, Pennsylvania 18015

U.S.A.

610.317.9606 (voice)

610.317.9570 (fax)

info@idomains.com

D3. The addresses and telephone and fax numbers of all other business locations of the registry operator.

There is one additional business location of the registry operator, as follows:

824 8^th Avenue

Bethlehem, Pennsylvania 18018

U.S.A.

610.868.8000 (voice)

610.868.0701 (fax)

D4. The registry operator's type of business entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is organized.

iDomains, Inc. is a corporation formed under the laws of the Commonwealth of Pennsylvania, U.S.A.

D5. URL of registry operator's principal world wide web site.

The URL of iDomains, Inc. is www.idomains.com.

D6. Dun & Bradstreet D-U-N-S Number (if any) of registry operator.

iDomains, Inc. does not have a D-U-N-S Number.

D7. Number of employees.

iDomains, Inc. presently has 4 employees.

D8. Registry operator's total revenue (in US dollars) in the last-ended fiscal year.

iDomains, Inc. had no revenue for the last-ended fiscal year.

D9. Full names and positions of (i) all directors, (ii) all officers, (iii) all relevant managers, and (iv) any persons or entities owning five percent or more of registry operator.

The full names and positions of all officers, directors, managers and five percent shareholders are:

Directors: Henry A. Lubsen, Jr.

Kenyon T. Stubbs

Michael D. Palage

M. Scott Hemphill

Officers: Henry A. Lubsen, Jr., President

Steve Heflin, Vice President

Kenyon T. Stubbs, Vice President

M. Scott Hemphill, Vice President & General Counsel

Mangers: See the officers listed above.

Shareholders: Henry A. Lubsen, Jr. is the only owner of more than five percent of the stock of iDomains, Inc.

The person to contact for additional information regarding this proposal is:

Henry A. Lubsen, Jr.

610.317.9606 (voice)

610.317.9570 (fax)

hlubsen@domainbank.net

D11. The full legal name, principal address, telephone and fax numbers, e-mail address, and Dun & Bradstreet D-U-N-S Number (if any) of all subcontractors identified in item D15.3 below.

The contact information for the subcontractors identified in item D15.3 is as follows:

CORE Internet Council of Registrars
World Trade Center II
29 route de Pre-Bois
CH-1215 Geneva
Switzerland
Telephone +41 22 929 5744
Fax +41 22 929 5745

E-mail address: secretariat@corenic.org

II. Business Capabilities and Plan

D13. The Business Capabilities and Plan section should consist of at least the following:

D13.1.1. Company information. Date of formation, legal status, primary location, size of staff, formal alliances, references, corporate or other structure, ownership structure.

iDomains, Inc. was formed on May 19, 1998 under the laws of the Commonwealth of Pennsylvania. The company, headquartered in Bethlehem, Pennsylvania, U.S.A., is active and in good standing according to the records of the Pennsylvania Corporation Bureau. iDomains, Inc. is a sister corporation of Domain Bank, Inc., an ICANN-accredited registrar, in that both corporations are under common control. The sole shareholder of iDomains, Inc. is Henry A. Lubsen, Jr.

iDomains is committed to creating a truly global registry company. That commitment is evident in (i) our selection of a European-based global organization (CORE) to operate the back-end registry services for .BIZ and (ii) our formation of a Business Advisory Committee (detailed in Section E10 of the Description of TLD Policies) to provide direction in policy development and assist us in developing registry services that meet the needs of commercial interests on a global scale.

As further evidence of our efforts at global outreach, iDomains is committed to global participation in both ownership & management of the proposed TLD. To this end we have committed to seeking global equity partners for up to 25% of the ownership of iDomains by multiple qualified parties whose principal business is conducted outside of North America (with particular focus on the Pan-European and Pacific Rim geographic regions). We are diligently working towards meeting these goals, keeping in mind that it is essential that the selection of the parties be made in a deliberated, orderly manner. As an example, we have had preliminary discussions with a highly-qualified potential partner whose business is located in the city of Wuhan, (population 12,000,000) in the Peoples Republic of China. We have reserved a seat on the Board of Directors of iDomains to represent our global partners.

iDomains realizes the inherent conflict in ICANN authorizing an accredited registrar to register domain names in a registry where the majority owner of such registry is an affiliate of the registrar. We believe that such a conflict is irresolvable by use of “Chinese Walls” and similar intra-corporate divisions of staff and resources. The owners of Domain Bank are therefore prepared, if iDomains is awarded a registry contract pursuant to this application, to divest at least seventy-five percent (75%) of the equity ownership and management control of Domain Bank to one or more third parties.

The company has no employees other than the officers listed in paragraph D9 above. Domain Bank presently employees 15 persons (including the persons listed as officers under D9 above). It is our intent that certain employees of Domain Bank would migrate to iDomains upon contracting with ICANN to provide registry services. Further, iDomains would hire additional staff as required.

The Company has no formal alliances. Domain Bank, however, is a founding member of CORE, and CORE has agreed to provide the back-end registry services for the .BIZ registry.

See Section D13.4.2 for a list of references.

D13.1.2. Current business operations. Core capabilities, services offered, products offered, duration of provision of services and products.

iDomains, Inc. has not engaged in significant operations to date.  The Company was formed in 1998 for the purposes of  providing domain name registry services as opportunities to provide such services became available.

Domain Bank is a provider of Internet domain name registration services worldwide, offering a quick and user-friendly registration process, responsive and reliable customer support and ancillary products and services such as web forwarding, e-mail forwarding and new host creation services.

Domain Bank is a founding member of the Internet Council of Registrars (CORE), a Swiss association.  In April, 1999, CORE was selected by the United States Department of Commerce to act as one of the five test-bed registrars to introduce competition into the domain name registration business for domain names under the .com, .net and .org top-level domains.  In July 1999, Domain Bank began offering domain name registration services as a member of CORE.  In August, 1999, Domain Bank became accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), and was the first direct registrar to the .com, .net and .org registries other than the testbed registrars.  Since that time, the Company has operated as a direct ICANN Accredited Registrar.

D13.1.3. Past business operations/entity history. History, date of formation, legal status/type of entity, initial services, duration of provision of services and products.

iDomains, Inc was formed on May 19, 1998 as a Pennsylvania corporation. iDomains, as sister corporation of Domain Bank, Inc., was formed for the purpose of providing domain name registry services as opportunities to provide such services became available.

The initial services that iDomains proposes to provide are registry management services for a top level domain restricted to commercial uses. Specifically, iDomains (either directly, or through third party vendors as detailed in this proposal) plans to provide the following services for the .BIZ directory:

1. Domain Name Registry Services for second level domain names in the .BIZ top level domain;

2. Centralized Whois, adopting a “fat” registry model;

3. Subscription-based enhanced whois search capabilities, and bulk whois access incorporating spam prevention measures;

4. Third level domain registration keyed to geographically significant second level domains;

5. Business directory service that would permit searches to be performed on a variety of variables, including business name, category of business conducted, location, and management or other key personnel.

6. Domain name monitoring service whereby any time any data field in the registration record maintained by the registry is modified in any respect, a notice will be sent by e-mail to the registrant and the Administrative Contact for the domain name informing them of such change.

7. Service history reports that will show the chain of registrants for a particular domain name.

Further, iDomains plans on actively pursuing new services that could add value to the ability of registrants to conduct business efficiently, effectively and securely on the Internet, while providing the Internet community in general with adequate access to information concerning registrations. For instance, iDomains would support the development of a cross-registry whois service.

D13.1.4. Registry/database/Internet related experience and activities. Experience with database operation, Internet service provision.

iDomains, Inc. has not engaged in active registry or similar operations to date. However, Domain Bank, Inc., iDomains’ sister corporation, has extensive experience in these areas. Domain Bank is an ICANN-accredited registrar, and has operated as such since the test-bed period. As such, Domain Bank has extensive experience in building and maintaining a database of domain name registration information, including most information that we propose be kept at the registry for .BIZ. Naturally, as a domain name registrar, Domain Bank and its staff are involved in numerous aspects of operating an internet business, including maintaining and operating a commercial web site; processing payments online; designing and developing software; maintaining appropriate hardware, connectivity and other technical infrastructure; providing customer service via e-mail, fax and telephone; and planning and implementing a marketing plan for an online domain name business.

With respect to CORE, the proposed back-end subcontractor for the .BIZ registry, we note the following experience.

Experience with shared registry database management

Shared databases as used in a shared registry are a relatively recent development. Even prior to developing its own system, CORE has been able to build on the experience made by CORE members who worked with two major shared registries, DENIC (.de) and Nominet (e.g., .co.uk). Several members of CORE's SRS working group held supervisory board positions. Equally important were contributions from members who worked with a large number of different domain name registries.

CORE's current shared Registrar System is a variant of the second implementation of its SRS design. Both implementations of the CORE SRS have originally been developed as a full-fledged registry system.

Experience with .com/.net/.org shared registry

At the time of writing, the CORE SRS manages over 800,000 domains under the responsibility of 30 CORE members. The SRS team manages the central Whois server (whois.corenic.net), which is updated within minutes after domain or contact information is changed.

The CORE SRS version used for .com/.net/.org is based on the second implementation of the CORE SRS developed in 1999. The interconnection with the NSI Registry took place in the framework of the NSI shared registry testbed for which CORE was selected as a "testbed registrar" by ICANN. It is important to point out that technically, a shared registrar system to be kept in synchrony with a "dorsal-spine-only" shared registry is more complex than a standalone registry. Moreover, CORE's work on the NSI interconnection could only start in June 1999 as NSI had not previously published its RRP protocol and at that time required a non-disclosure agreement and a performance bond before supplying any information.

Additional plausibility-checking, automated archiving and verification tools are run by the SRS team and the CORE secretariat. These systems are updated and improved continuously.

Despite its generally decentralized organizations CORE relies on certain centralized verification mechanisms, such as those involved in domain holder changes. Experience with these mechanisms is key for CORE's proposals for distributed enforcement and verification mechanisms with a central audit electronic trail.

Internet-related experience and know-how available within membership

Most CORE members have a long-standing track record of internet related activities, either as Internet application developers, ISPs, Telecommunications companies, application hosting providers, hardware housing providers, ccTLD registries or specialized domain name registries.

D13.1.5. Mission. The registry operator's mission and how it relates to expansion into the registry operation field.

The mission of iDomains in operating a registry for .BIZ is to provide a portion of the domain name space to enhance the ability of registrants to transact commerce on the Internet within an environment of increased effectiveness, efficiency and security. Our goal is to restore the original vision of .com, a TLD for commercial use. By focusing on the business needs of registrants, we believe that we can couple reliable and efficient registry maintenance services with value added services designed to meet the needs of today’s rapidly growing electronic commerce markets.

D13.1.6. Management. Qualifications and experience of financial and business officers and other relevant employees. Please address/include past experience, resumes, references, biographies.

Henry A. Lubsen, Jr. – Director, Chief Executive Officer & President. Mr. Lubsen founded the Company in December, 1997. Mr. Lubsen is also the founder and President of Domain Bank, Inc., iDomains’ sister corporation. Since 1998, Mr. Lubsen has served as a member of the Executive Committee of the Internet Council of Registrars (CORE), a Swiss association. In his capacity of President and Chief Executive Officer of Domain Bank, Mr. Lubsen is involved on a full-time daily basis in dealing with domain registration issues and is the principal company contact with the NSI Registry.

Mr. Lubsen has over 35 years of business experience in various disciplines. In addition to Internet companies, he is currently the President of Altronics, Inc., an alarm and security system vendor, and of Allied Central Services, an alarm monitoring company. As such, he has extensive experience in the operation of 24/7 customer service departments, and the development and maintenance of high security, redundant databases and networks. The alarm company systems are periodically inspected by Underwriters Laboratory, the third party certification service. Further, Mr. Lubsen’s alarm and monitoring companies have provided him with a solid base of experience in recurring revenue businesses, and the accounting and related issues unique to such ventures.

In addition, Mr. Lubsen is engaged in the real estate development business in the Eastern Pennsylvania market. His real estate businesses realized revenue in the 10-15 million dollar range per year.

He is a 1965 graduate of Muhlenburg College, located in Allentown, Pennsylvania, with a B.A. degree in Psychology.

Kenyon T. Stubbs – Director & Vice President of Public Affairs.  Mr. Stubbs joined the Company in March, 2000 as Vice President of Public Affairs.  Prior to joining Domain Bank, Mr. Stubbs was associated with Domain Names International, Ltd.  (“DNI”).  Mr. Stubbs has been a member of the Executive Committee of CORE since 1998, serving as Chairman of ExCom since that time.

Mr. Stubbs is a graduate with distinction from San Diego State University (B.S. in Business, 1967) and is a Certified Public Accountant. He has over 35 years of extensive business management experience, including having owned his own business, and has been active in Internet strategy and consulting service business since 1993.

Prior to starting his own management consulting firm in 1974, he worked for KPMG Peat Marwick and Ernst & Young, specializing in accounting systems and operations management.

His consulting services have concentrated primarily on organizational structures, operations and marketing strategies. Clients have ranged from start-ups with sales of less than $500,000 to established companies with sales over in excess of $10 Billion.

Mr. Stubbs has consulted on Internet business development strategies since 1994. Clients have included Fortune Brands, Hoechst-Celanese and Wilson Sporting Goods Worldwide, as well as numerous small businesses. He has served as director of marketing and strategic business partnerships for an Internet services company, which was involved in web site design, development, and hosting.

He is a frequent participant and speaker at international forums on the Internet & Domain Name System. He has testified as an expert before the United States House Commerce Committee as well as the United States House Judiciary Committee on Internet development, Commerce and Intellectual Property as it relates to Internet Issues.

M. Scott Hemphill – Director, Vice President & General Counsel – Mr. Hemphill joined the company on January 1, 2000.  Prior to joining the Company, Mr. Hemphill was a shareholder in the Allentown, Pennsylvania law firm Fitzpatrick Lentz & Bubba, P.C., where he represented iDomains, Domain Bank and their affiliates in a wide range of matters.  Prior to that experience, Mr. Hemphill was associated with the Washington, D.C. law firm Shaw, Pittman, Potts & Trowbridge.  Mr.  Hemphill received his B.S. in Business from Wake Forest University in 1985 and his J.D. from the College of William and Mary in 1991.

Mr. Hemphill has extensive experience in dealing with Internet issues. He has counseled Domain Bank (and CORE while in private practice) on a wide variety of issues arising in the course of the domain name registration business. Such issues include, among others, drafting and enforcement of agreements with registrants, affiliates, vendors and partners; trademark and cybersquatting matters; Uniform Dispute Resolution Policy proceedings, corporate law and employment law. Mr. Hemphill currently participates on the ICANN Registrar’s Constituency task force that is developing a Code of Conduct for ICANN-accredited registrars.

Steve Heflin – Vice President.  Mr. Heflin is Vice President in charge of Affiliate Marketing.  Mr. Heflin has been with the Company since its inception.  Prior to joining Domain Bank, Mr. Heflin was a co-founder of Internet Tidal Wave, one of the first internet service providers in the Eastern Pennsylvania market.  Mr. Heflin has lectured extensively on Internet related issues.

Michael D. Palage – Director. Mr. Palage is a member of the Company’s Board of Directors. He is also Vice President and Chief Technology Officer of InfoNetworks, Inc., an international computer service and consulting company, located in Florida, providing high-end information services to the legal and business community. His primary focus is business development as well as software design and enhancement.

Mr. Palage presently serves as Secretariat of the ICANN DNSO Registrar Constituency. Further, he is Co-Chair of ICANN Working Group B, pursuant to which he was responsible for chairing and preparing the report evaluating the WIPO recommendation for safeguarding famous trademarks in connection with the Domain Name System.

Mr. Palage is a frequent speaker at Internet related conferences, the most recent being the ICANN orientation workshop in Yokohama, Japan (July, 2000) where he was a panelist for a discussion of "New Internet Top-Level Domains", and a KRNIC ICANN workshop in Seoul, Korea (July, 2000), where he was a guest speaker on the topic "Famous Trademarks and the Internet Domain Name System".

Mr. Palage received his B.S.E.E. from Drexel University in 1990, and his J.D. from Temple University School of Law in 1995.

D13.1.7. Staff/employees. Current staff size, demonstrated ability to expand employee base, hiring policy, employee training, space for additional staff.

iDomains staff currently consists of the four officers listed in Section D13.1.6 above, which comprise the core management of the Company. These individuals represent a significant pool of business experience comprising expertise in the areas of financial management, staffing, customer service, legal and administrative, operations, and technical staff supervision.

As stated above, Domain Bank presently has 15 employees. We anticipate that many of such personnel will migrate to iDomains upon award of the registry contract by ICANN. The Company would then hire as appropriate in order to meet the demands of the registry operation. The Company contemplates hiring a customer service staff adequate to handle the proposed registry anticipated global needs, including provision for multi-lingual support as demand requires. Further, we would immediately begin the process of recruiting a CTO for the registry operations. We would also begin to hire marketing staff promptly. Since the registry back-end would be operated by CORE, much of the technical staffing requirements would be filled by CORE.

The Company shares facilities with Domain Bank in a 6,000 square foot commercial office building in Bethlehem, Pennsylvania. The building is owned by Domain Bank. Presently, approximately half of the building is occupied, and the other half is available to house the increased operational demands of iDomains upon award of a registry contract. In addition, Domain Bank currently co-locates many of its servers with Fastnet Corporation, a local ISP.

The Company is an Equal Opportunity Employer, as defined under applicable United States laws and regulations.

With regard the proposed back-end subcontractor for the .BIZ registry, CORE plans to build up a team of 8 to 10 staff positions by the time registry operations start. Depending on the overall workload required, the initial staffing level may be higher.

D13.1.8. Commercial general liability insurance. Address/include amount of insurance policy, provider of policy, plans for obtaining additional insurance.

iDomains, Inc. is an additional insured under the commercial liability policy of Domain Bank, Inc., as described below:

Insurance Agency: Henry S. Lehr, Inc.

3893 Adler Place

PO Box 25001

Lehigh Valley PA 18001

Insured By: Fireman’s Insurance Company of Washington, D.C.

Coverage: Each Occurrence - $1,000,000

Fire Damage - $ 100,000

Med Exp - $ 10,000

Personal Inj - $1,000,000

General Aggregate - $2,000,000

Products-Comp/OP Agg - $2,000,000

iDomains will obtain such other insurance as may be required by ICANN, or as iDomains otherwise deems prudent.

D13.2.1. Services to be provided. A full description of the registry services to be provided.

Domain Name Registry Services

iDomains proposes to offer domain name registry services under the restricted top-level domain .BIZ. Registrations in .BIZ are proposed to be restricted to registrants that represent their intent to use the domain name only with respect to web sites that facilitate commerce on the internet. We believe that the original concept of the .com top level domain, that is, a TLD restricted to commercial uses, was well conceived. The idea that a portion of the domain name space be reserved for commercial uses would allow electronic commerce to be marketed more directly, and operated more efficiently and more securely. The core service provided by the Company will be the maintenance of the .BIZ registry database. The Company will provide the ability for ICANN-accredited registrars to register second-level domain names in the .BIZ registry on behalf of their respective customers.

In order for a registrant to be permitted to register in .BIZ, such registrant would be required to represent and warrant that the domain name will be used only in connection with a web site that offers goods or services in commerce. Further, as a indication of intent to use the domain name in commerce, the registrant will be required to submit a tax identification number, along with its corresponding country, as part of the registration process. This information will be displayed in the whois output as a reference for persons that desire to initiate a challenge of the registrant’s use of the domain as being not within the charter requirements.

Centralized Whois

The Company proposes to maintain a centralized whois service at the registry level. iDomains recognizes that under the current thin registry/decentralized whois system, in which registrars maintain customer contact information and provide whois services, the lack of uniformity in whois services has hampered the internet community’s ability to access reliable registrant data. Our registry will retain all registrant data, and will make such data available in a uniform format.

Further, the advantages to a centralized Whois service go beyond the uniform aspect. We propose to build functionality into the Whois service that will (i) minimize abusive uses of Whois data, (ii) enhance the ability of businesses to market their products and services, and (iii) enable the intellectual property community to adequately monitor the legitimate rights of trademark owners worldwide.

One of the problems with the current decentralized whois service is that some registrars may not take adequate measures to prevent data mining and harvesting of registrant information in such registrar’s database. As a result, registrant contact information can be mined and added to e-mail mailing lists, subjecting such registrants to “spam” and other unwanted solicitations. By centralizing whois data, and building effective data mining prevention into the whois software, we believe registrants will enjoy added protection against spammers.

Another proposed measure designed to protect registrants against abusive uses of whois data is to stratify access to whois searches. We would propose that access be provided in one of two manners:

i) Casual query: Such access will be provided to anyone for free, and will be limited to one domain name look-up search at a time. Such whois service will be accessed at the registrar’s web sites, via an interface available to any registrar active to the registry;

ii) Subscription-based access: Such access will be provided on a cost recovery basis under a license agreement that will prohibit abusive uses of the data obtained (e.g., developing commercial e-mail lists). Licensees would be permitted to search whois data by a number of variables, including character strings, registrant name and registrant address.

iii) Bulk Access: Bulk access to the whois database would be provided as follows. iDomains would make the database available to any ICANN accredited registrar for resale by such registrar to its customers. Any resale by such registrar would be subject to ICANN policies (e.g., the registrar could not charge more than $10,000 per year for the data). Further, the registrars would be required to obtain from the end user an agreement (in a form approved by iDomains) to use the information only for lawful purposes and in no event for purposes that would constitute abuse of the data, such as facilitating high volume commercial e-mail.

Fees collected by iDomains for provision of bulk whois service will be used to fund cooperative marketing projects designed to increase the .BIZ brand, and thus increase business for registrars, as well as the registry.

As further protection against abusive uses of the bulk whois data, All e-mail addresses displayed in the bulk whois will be replaced in the form of

CONTACT-HANDLE>@handles.registry.biz within the following guidelines:

E-mail received at <CONTACTHANDLE>@handles.registry.biz will be forwarded to the contact's real e-mail address. If the E-Mail address becomes invalid or bounces, the forwarding mechanism will be disabled and the contacts true e-mail address will be put into the bulk whois data.

This default mechanism for all registrations is designed to enable spam prevention; however, upon request of a registrant, such registrant may have their default changed to disabled. The true and correct contact's e-mail address will be disclosed to courts and police upon request.

Using the above policies will enable the registry to mitigate spam on the behalf of registrants. Should a mass mailing be sent to registrants within the .BIZ registry, the registry will be able to file appropriate legal action as the e-mail addresses could have only been mined from the registry whois. We believe that e-mail spam prevention and detection will become an industry standard as we will be able to show just how much the whois database is used as a source for spammer lists.

The .BIZ registry will make available to the Internet Community additional statistics, sample spam, and know spam origination sites. The .BIZ Registry will work with Industry anti-spam and UCE prevention leaders a such as RBL/Maps Project and other anti-spam organizations to encourage the responsible use of whois data.

We believe that improving the delivery of whois services to the Internet community will be an important “proof of concept” vehicle for the new TLD. Whois service will be delivered in a stable, reliable, secure system that will provide safeguards against data mining and abusive use of whois data.

Cross-Registry Database

In addition the Company is committed to full cooperation in the development and operation of a cross-registry whois database that would provide full search capabilities and access to all relevant information concerning domain name registrations regardless of the TLD in which the domain name is registered.

Third Level Domains

iDomains recognizes that businesses throughout the world perceive value in broadcasting their county of domicile in various manners, including the domain name that they do business under. For instance, businesses in South Korea or England may be more comfortable doing business online using a third-level domain under .co.kr or .co.uk, respectively, rather than .com. Given such desire for regional and national presence indicators in domain names, iDomains plans to develop a system of third level domains under .BIZ for use by registrants. Specifically, iDomains will reserve all of the two-letter strings as second level domains under .BIZ. Under such SLDs, third level domains will be registered to registrants as follows. Each registrant under .BIZ will receive a third level domain under the second level .BIZ name corresponding to the ISO 3166-1 country code of the registrant’s domicile. For instance, a registrant from Australia that registered ABC.BIZ would automatically be assigned the rights to ABC.AU.BIZ as well. Such service would be provided at no additional charge to the registrant. The registrant could also opt to register third level domains with their servicing registrar under any other two letter .BIZ SLDs for a specified fee. Such registrant would be under no obligation to register such additional third-level domains, and the registrants string will be protected against registrations by other parties in the third level as described above.

The purpose of providing the third level domains is to permit companies to instantly provide their customers with an indication of the nationality and location of the company. This system will provide great flexibility to registrants. If they wish to market on a global basis, they may choose to use only the second level domain name (e.g., ABC.BIZ). If the customer perceives value in marketing regionally, they may choose to use their third level domain (e.g., ABC.AU.BIZ). Further, a registrant could register several third level domains, representing different geographic regions, and market differently to different regions, even maintaining different web sites geared to such region.

Directory Service

As an additional value-added service to registrants, iDomains will create and maintain a directory based on search engine technology. The directory will serve as a business directory for registrants. Each registrant will be able to provide certain information about its products and services via the directory. The third level domain regime outlined above will enhance a directory user’s ability to perform country specific searches related to particular business lines. Searches could be performed on a variety of variables, including business name, category of business conducted, location, and management or other key personnel. The information will be browsable and searchable via web and LDAP based clients. The Business Registrants will have the option of registering in the directory and associating additional data elements such as URLs, business and marketing telephone, email and fax numbers.

Domain Monitoring Service

Domain name “hijacking” and other unauthorized changes of registrant information is a problem that has been escalating in recent months. In fact, earlier this year ICANN-accredited registrars held a summit in Reston, Virginia to discuss the problem with the United States Federal Bureau of Investigation and Department of Justice. We believe that the centralized registry database outlined above will alleviate the concern to some extent. However, since registrant data modifications will still be controlled by the registrars, we believe an added domain monitoring service will be of great value to registrants. Our concept is to provide a service whereby any time any data field in the registration record maintained by the registry is modified in any respect, a notice will be sent by e-mail to the registrant and the Administrative Contact for the domain name informing them of such change. This will provide an added level of protection in the event of an unauthorized record modification.

Service History Reports

We intend on developing a capacity to provide service history reports for domain names registered in the .BIZ registry. Such reports will show the chain of registrants for a particular domain name. We intend to provide this service on both an casual basis as well as via subscription to parties with legitimate rights of access.

D13.2.2. Revenue model. A full description of the revenue model, including rates to be charged for various services.

Our revenue model is based on the following assumptions:

Fees for services:

iDomains will charge a rate of US$5.45 per year of registration for each domain name registered in the registry. All registrations fees must be paid in advance by registrars. Upon the registration of names in the registry by a registrar, such registrar’s account with iDomains will be debited the appropriate amount.

iDomains anticipates charging reasonable fees for certain ancillary services described above, such as subscription based whois search access, third-level domains (other than the initial free domain name), domain monitoring services and service history reports. All such services would be available for sale to registrars, who would be authorized to resell the services to their customers.

Finally, bulk whois data would be available to the registrars for resale to their customers. iDomains plans on charging up to $5,000 per year for such bulk access. Fees collected by iDomains for provision of bulk whois service will be used to fund cooperative marketing projects designed to increase the .BIZ brand, and thus increase business for registrars, as well as the registry.

D13.2.3. Market. Market definition, size, demand, accessibility.

The remarkable growth of the Internet in recent years shows no signs of abating. According to Nua Internet Surveys, http://www.nua.ie/surveys/, “During the past year Internet access has grown significantly in all regions of the world, rising from 171 million people in March 1999 to 304 million in March 2000, an increase of 78 percent”.

According to a report prepared for the US Commerce Department E-Commerce Summit (6/23/2000) “Today there are in excess of 1 Billion pages on-line with over 3 million pages being added each day. Consumers today--wherever they are in the world--go online to shop, learn about different products and providers, search for jobs, manage their finances, obtain health information and scan their hometown newspapers.” While many of these activities are not captured by official output and productivity measures, a growing body of anecdotal evidence suggests that the Internet, with all of its benefits, is improving many people's lives.

E-Commerce and Internet Commerce Impact

US Market

The Internet is growing rapidly: by 2004, U.S. – Based business online consumer sales will grow to $184 billion, online business sales to $2.7 trillion

(Source; US Commerce Dept. www.ecommerce.gov)

“B2B e-commerce in the US alone is set to become a USD4.8 trillion market by 2004, up from USD1.2 trillion in 2000”, according to the latest report from the Boston Consulting Group. “By 2004, Internet purchasing in the b2b sector will represent 40 percent of total purchasing.”

According to US Census Bureau Reports “Retail US e-commerce businesses recorded $5.15 Billion in sales in the second quarter of Year 2000 which represents a 5.3% increase over the first quarter 2000.”

Europe

According to a recent NOP Research group survey (http://www.nop.co.uk/survey/survey_internet.htm) In the 4 weeks ended September 11, 2000, 3.3 million online shoppers in the UK shopped over the Internet 10.11 million times and made 18.2 million purchases.

The survey also found that most online shoppers used credit cards confidently. Credit and debit card details were submitted online by 90 percent of online shoppers.

In other European venues this ever-increasing trend continues as well. A Recent Jupiter Communications survey indicates that online revenues are expected to grow in Sweden from ECU0.6 billion (USD 0.511 billion) in 2000 to ECU 2.8 billion (USD2.38 billion) by 2005. The projected growth in Denmark will be from ECU0.2 billion (USD0.17 billion) to ECU1.4 billion (USD1.19 billion), and in Norway from ECU0.2 billion to ECU1.3 billion (USD1.12 billion). Excerpted from US Commerce Department Small Business 2000 report)

Other European communities are enjoying comparable success rates to those shown above.

Asia & The Pacific Rim

On the Pacific Rim, according to a recent Deloitte & Touche Pacific Rim Internet survey summary (www.deloitte.com.au): “The survey found that China had 16.9 million Internet users, behind Japan, with 27 million users, and ahead of South Korea with 15.3 million users and Australia, 7.3 million.

China was expected to double its number of users every six months, given that its present number constitutes only 1.3% of its total population of 1.275 billion people. Such a continued rate of growth could lead China to boasting the world’s biggest online population within 10 years.”

The nation ranks 12th among international domain registering countries. Registrations in the first 6 months of 2000 are up nearly 26% from the last 6 months of 1999.

The Deloitte survey estimated that total electronic commerce revenues in Asia for 1999 ranged between $6 billion and $8 billion, of which around 80% was in the business-to-business space,”

The same survey concluded that total revenues from electronic commerce in the region are expected to grow to between $250 billion to $300 billion by 2003, of which around 90% will be in business-to-business.”

According to NSI Statistics (www.dotcom.com/facts/asia_pacific.html):

Japan currently has 12 million active Internet users. The nation ranks 8th among international registering countries. Domain registrations in the first 6 months of 2000 are up nearly 115% from the last 6 months of 1999.

Korea currently has 1 million active Internet users. The nation ranks 5th among international registering countries. Domain registrations in the first 6 months of 2000 are up nearly 169% from the last 6 months of 1999.

India currently has ½ million active Internet users. The nation ranks 14th among international registering countries. Domain registrations in the first 6 months of 2000 are up nearly 54% from the last 6 months of 1999.

A recent study by NSI (www.dotcom.com/profiles/vmarket.html) indicates that “Every vertical business market has increased at least 100% from year to year. While large companies continue to invest in Web site development and enhancement, it’s the Small Office/Home Office and consumer market that are joining the Internet economy in the new century.” Total business registrations compromise well in excess of 70% of all domains registered on the current Generic TLD Space and as evidenced by the growth trends indicated above in both consumer-users and e-commerce activity this business-commercial use base should clearly continue to expand.

D13.2.4. Marketing plan. Advertising, publicity, promotion strategy, advertisement development strategy, relationship with advertising firm. Use of registrars and other marketing channels.

Stages

Increasing Consumer awareness

We anticipate a period of somewhere between 90 and 180 days from the time of ICANN contract announcement until commencement of the Sunrise Period. During that time period, we will concentrate on creating global potential consumer awareness for this new space. The principal channels we anticipate utilizing will be as follows:

1. Business Wire Services.

2. High-volume Internet portals (e.g., MSN, AOL, Yahoo, etc…)

3. Specific Business-oriented periodicals and newspapers, such as

a. Financial Times

b. Wall Street Journal - All global editions included

c. Forbes

d. Other regionally significant publications

e. Asian Wall Street Journal

f. Business Sections of all major Asian & European Newspapers

g. USA Today

h. New York Times

i. Los Angeles

4. We also intend to provide staff for interviews and promote same with all the relevant TV Business Channels such as:

a. CNN

b. MSNBC

c. CNN Europe

d. Sky Channel – Business

e. ZDTV

f. Asia Business channel

It is our intention to support this effort with a limited number of key “Announcement Preview Ads”

During this time period, we will initiate a strong channel development program targeted toward current ICANN-accredited registrars, ISPs and other potential facilitators of domain name registrations, along with a global recruitment program to encourage new potential channel partners to become ICANN-accredited, which will enable them to affiliate with our registry.

We intend to develop increased awareness in newly emerging high growth global areas during this time period, such as the Pacific Rim and Europe. To that end, we anticipate the establishment of fully staffed marketing and customer service offices in those areas of the world, which will be in place to support our PR & Advertising efforts. We will also consider establishing an office in South America if warranted.

We are currently interviewing marketing consultants and Advertising organizations to finalize and assist in implementing our marketing plan upon approval of our proposal by ICANN.

Sunrise Period

Prior to the commencement of the Sunrise Period, the Company will initiate an aggressive global marketing and informational program targeted toward existing holders of registered trademarks. The program will encourage registration during the Sunrise Period of exact match strings. Marketing channels to be used include professional periodicals and trade journals, intellectual property organization newsletters and a targeted opt-in e-mail campaign as well as direct snail mail. Organizations that we intend to work closely with include the AIPLA, INTA and other regional intellectual property oriented professional associations.

Public Introduction and on-going efforts

Midway thru the “Sunrise Period” we will commence initiate a global advertising program targeted initially at the 6-8 largest current generic TLD markets according to current marketing data (see:www.dotcom.com/facts/intmarket.html).

This program will be designed to create a “sense of urgency” to stimulate demand for the opportunity to “place your business in this new space”

Our primary focus will be thru normal business periodicals & newspapers and key Internet portals such as ISP’s, major content providers and search engines supported by opt-in e-mail as well as Highly-Targeted mass-media . This program will be consolidated with an intensive PR effort utilizing the synergy created by the attendant publicity of new global TLD expansion effort. We will also be concentrating on evaluating and development of a globalized target-market program, which we intend on focusing through our various global partnerships with, accredited registrars.

It is our belief that our “global” registrar partners have a strong sense for what will be the most effective methodology to stimulate registrations in this space from their local geographic regions. To that extent we will be forming a registrar promotion & advertising council from our affiliate base to work with our marketing staff and its supporting vendors to help us get the most optimal impact with our marketing dollars.

The use of co-operative advertising has been very effective in many industries and we feel that this methodology is ideally suited for a globalized business. The concept of providing funds on a cooperative effort works as a stimulus for the various registrars to “self promote” the registration services on a local business using methods which a much more “culturally efficient”. We have seen little of this type of marketing in the current generic TLD space and feel that this has been somewhat of a deterrent to broader global participation. This proposed program should help to provide a “proof of concept” in the area of “regionalized marketing” of TLD registrations.

Ongoing Efforts:

From our perspective we see a continual commitment to expand the awareness and potential uses of our proposed .BIZ string that parallels the developing technologies, which will enhance the utilization of the DNS. In many parts of the world the principle vehicle for communications development will be a blend of Internet and wireless. As technologies emerge (i.e. G3 etc) and more effective methods develop for bandwidth enhancement, a great justification for e-commerce development and small business utilization of the web will develop. We intend to provide a continuing message to the potential users and the future PR programs educate both the current as well as the potential registrants on how they can use our “space” to enhance their business and subsequently their own well being.

We have quantified our estimated demand for .BIZ registry services for (i) the Sunrise Period, (ii) the initial rollout period and (iii) the balance of the initial four year term. We have made projections at 10%, 50% and 90% confidence levels. See the detailed volume projections included as part of the financial projections provided under Section 13.3 below for our demand projections.

We believe that by maintaining registry fees well below the current benchmark of $6.00 per year, demand for .BIZ domain names should be robust. As our projections indicate, we anticipate that initial demand will be significant, due to several factors, including (i) the present demand in the registration market for new alternatives in the domain name space, (ii) the media exposure that new TLD offerings are likely to realize in the first round of new TLDs and (iii) the comprehensive marketing efforts that we have planned to promote the .BIZ brand.

We anticipate that growth rates in new registrations will slow after the first year of operation. This will be the likely result of the satisfaction of the market’s initial pent up demand for new product, along with likely increased competition in the name space as ICANN introduces new top level domains in the future.

iDomains

Financial

See the financial projections attached hereto as Exhibit A for a detailed analysis of the financial resources required to meet estimated demands at the 10%, 50% and 90% confidence levels.

As demonstrated on the balance sheet of iDomains at September 30, 2000, the Company has committed US$1,000,000 as an additional investment to the .BIZ registry project. As the financial projections attached hereto demonstrate, the Company is likely to require an additional capital infusion of approximately US$1,000,000 prior to the beginning of registry operations in order to fund the business plan. This is true regardless of the confidence level. iDomains is confident that such additional capital can be readily obtained within the required time frame from one or more of the following sources: (i) global investment partners (as stated above, iDomains is committed to bringing on non-North America based equity partners for up to 25% of the Company’s ownership), (ii) other private equity capital sources, such as strategic investors, (iii) funds generated by Domain Bank’s operations (subject to the divestiture option outlined in Section D13.1.1) and (iv) commercial bank financing.

Upon commencement of registrations in the registry, the Company should be self funding. The volume of registrations (i.e., the confidence level achieved) will play a large role in dictating the size of certain budget items. We will remain flexible enough in our business model, however, to facilitate the scalability necessary to succeed at different levels of registrations.

Technical

Most of the technical resources required to operate the registry will be provided by CORE in its role as back-end subcontractor. iDomains will expend significant capital, however, to appropriately staff and equip its own operations. The financial projections show significant capital outlays for people and equipment necessary to provide the ancillary services that iDomains plans to offer. We anticipate that our technical staff will include a Chief Technical Officer, an Operations & Engineering Manager, Senior Systems Administrative Manager, a Systems Administrator and three Customer Support staff.

Staff

The financial projections show detailed estimates of headcount requirements at the different confidence levels. The Company presently has personnel on staff (or on Domain Bank’s staff) to fill certain positions. In addition, upon award of the registry contract, we will immediately begin a global search to fill the other specified management and staff positions.

Physical Plant

The present Bethlehem, Pennsylvania facility should be adequate to house the required personnel at any of the confidence levels. In addition, iDomains will establish satellite offices in Europe and Asia (and possibly South America).

Customer Service

We anticipate a combined staff for our principal and regional offices that will include a Vice President of Policy and Registrar Relations, a Manager of Registrar Relations, a Customer Service Manager, a Senior Customer Service Representative, and four Customer Service Representatives. We feel confident that we will be able to scale up or down in this area, depending on the confidence level achieved.

CORE

Financial

Given the fact that CORE has an existing shared registry system and an ongoing registration operations through members the additional requirements for financial resources can be met through existing funds and equal contributions from new members.

Technical

CORE principal technical resource is its shared registration system (SRS) and the TLD servers. CORE's will obtain housing and connectivity from members at market prices based on flexible contracts reflecting actual usage. In this context, financial projections are pessimistic as they assume expenses for near-zero usage initially. The budget for software enhancements is provided in additional to staff costs.

The projected physical plant is composed of a main SRS installation located at a protected co-location site with high-end hardware and network installations. A back-up site is to be hosted by a CORE member as is currently the case. The connectivity available through CORE members is virtually unlimited.

The TLD servers will be distributed and based on a staggered implementation plan. Initially, bandwidth and capacity requirements are modest although the financial projections are based on a pessimistic evaluation of non-compressible costs.

Staff

CORE expects to have 10 staff working for registry activities in various managerial, technical and clerical capacities. This seems credible based on CORE's current operations (800,000 registrations) and the staffing levels of some ccTLD registries in CORE's membership.

iDomains

CORE will have the principal responsibility for acquiring necessary systems and facilities for providing the proposed services. iDomains will acquire systems and retain personnel necessary to operate certain ancillary systems according to the detail provided in the financial projections.

CORE

Starting with the second implementation of its SRS, CORE has successfully switched over to commodity type of hardware based running the Linux operating system. On the SRS, the back-end configuration involves a double processor CPU with a RAID mass storage and dual power supply. The front-end configuration is based on two separate machines, each of which can replace the other. The main SRS is hosted at a co-location site.

An identical configuration though possibly with lesser performance features is used as a test system.

TLD Name servers are based on leased or purchased type hosted at the main SRS site and initially on two, later 5 different locations world-wide. CORE will have full remote access to all TLD servers, housing is to be obtained from members or third parties at market prices.

Whois servers are based on lighter machines easy to duplicate. There will be several Whois servers so at the SRS location, later additional machines will be installed at remote locations. The concept of multiple Whois servers with incremental updating is key for the protection of SRS backend performance. Check queries from members and are directed to specialized Whois servers.

iDomains

iDomains, and its sister corporation Domain Bank, presently occupy a commercial office building (owned by Domain Bank) consisting of approximately 6,000 sq. ft. of usable space. Presently, only 3,000 square feet are occupied, and therefore, the remainder would be available to house increased staff required to operate the registry. The building has excellent connectivity and is in the process of being remodeled and technologically upgraded.

The affiliated companies have a staff comprised of 4 programmers, 2 network support personnel, 4 customer service representatives, 2 marketing staff and 5 executive and administrative personnel. It is anticipated that upon approval of our proposal, certain staff will migrate to the new registry division and we intend to hire the following additional personnel:

Chief Technical Officer – Responsible for supervision and management of the technical effort and all resources related to same. Oversees relationship with vendors (e.g., back-end providers), establishes and coordinates ongoing development of specifications and protocols and assures adherence to standards developed by protocol and technical authorities (e.g., IETF).

Chief Marketing Officer – Responsible for development and supervision of registry marketing efforts. Supervision and evaluation of regional marketing managers. Coordinates and evaluates overall marketing budget and supervises outside contractor relationships (e.g., marketing research and advertising agencies).

Regional marketing managers – initially, it is our intent to hire 3 regional marketing managers to cover Europe and Africa, Asia and the Pacific Rim and North and South America. The specific job descriptions will be developed in the near future.

For more detail on iDomains staffing plans, see Section D13.1.6 above and the financial projections attached hereto.

CORE

As explained under D13.1.7, CORE will rely on seconded staff as well as limited outsourcing of non-central tasks. As staffing requirement rise, the registry will attempt to draw on seconded staff from members working full or part time for the registry. Certain experts can work remotely.

The operational concept of CORE is based on automated tasks on registry level and delegation of value-added tasks to member. This automatically limits the degree to which the registry requires clerical staff and support.

CORE has a tradition of working with members for development work. One-time tasks such as specific software developments and documentation projects can be entrusted to experts from within the compensated at market rates. Many CORE members are specialized application developers who make available their systems to third parties.

D13.2.9. Availability of additional management personnel. How will management needs be filled?

iDomains

We believe that our contacts in the industry will aid in our search for key personnel. In addition, we will utilize the services of global executive search firms and personnel recruiting consultants to fill out our staff, both our U.S. office and our international field offices.

CORE

As explained under D13.1.7, CEO, CT O and other key positions are filled either by long.-term member seconded professionals or by newly hired personnel. A formal call to the membership will be issued as and when there is sufficient certainty as to the effective launch of the TLD(s). Given the diversity of CORE's membership, the association has access to a large pool of professionals.

We propose a total license term of eight years, comprised of the following: (i) an initial four year term and (ii) an additional four year renewal term that would be conditioned on the registry meeting certain benchmarks mutually agreed upon with ICANN. We trust that ICANN recognizes that it is essential to provide adequate incentives for continuing development to any new registry.

We anticipate that significant capital will be required to develop and implement a marketing plan sufficient to build demand for the registry’s services to a level required to ensure the success of the business.

Further, the explosive growth of the Internet over the past 5-7 years has been fueled by the development of new technologies and the ability to provide these technologies on a cost effective basis to an ever broadening spectrum of users. The Company anticipates that over the next 3-5 years, the pace of development will be even more accelerated, principally due to the demand created by the existing user pool (which is in excess of 50 times greater than the base period for previous growth). The development of new wireless technologies and enhanced bandwidth utilization further enhances the potential global opportunities for businesses of all sizes to effectively utilize the benefits of the proposed namespace. The Company anticipates a need for significant continuing expenditures over the next 3-5 years to facilitate our commitment to provide on a competitive, ongoing basis an even higher level of technologies, as well as customer service, commensurate with the expectations created by these new innovations.

It may not be practical to assume that significant expenditures that are anticipated to be incurred 3-4 years out can be recovered within a period of less than 36 to 48 months from incursion. Given the resources necessary to ensure that the registry can provide state of the art services to its customers on a long term basis, and remain competitive with other registries on a price basis, we believe that the 8 year term (with the second 4 years subject to our meeting predefined criteria) is the most practical, and will ultimately be the most beneficial to the user community.

The financial projections attached hereto as Exhibit A provide a detailed analysis of the total estimated operational costs by the sources of the costs for each estimated demand level. Below is a summary of such projections at the fifty percent confidence level:

Payments to Back-End Subcontractor: The first year’s estimated payments to CORE for the provision of back-end registry services totals $5,392,980, with a payment in month 12 equal to $787,500.

Systems Development and Support: Our projections show expenditures in the first year of approximately $66,000 to outfit our offices for increased staff.

Customer Service: We have budgeted approximately $446,585 for customer service staff during the first year, with expenses in month 12 expected to be $112,813.

Marketing and Sales: We estimate marketing and sales expenses of $3,057,420 for the first year of the license term, with expenses in month 12 of $507563,125. These amounts include line items for labor and advertising and promotion, including media, co-op advertising, production, research, agency fees, and public relations.

General and Administrative: We anticipate total G&A expenses of $2,434,660 for the first year of the license term, with expenses in month 12 equal to $311,102. Included under this category are labor, rent, telecommunications, material and supplies, travel and entertainment, seminars and conferences, insurance, facility maintenance, legal, financial and accounting, and other items.

With respect to ICANN’s cost recovery needs, iDomains offers the following:

(i) Registrar fees: iDomains would be willing to collect per name registrar fees as part of the registration process, and submit those fees directly to ICANN;

(ii) Registry fees: iDomains acknowledges that, upon award of a regsitry contract, it will have an obligation to contribute to ICANN’s cost recovery needs via a registry fee. Due to the uncertainty as to how many new TLDs will be approved, and the anticipated costs to ICANN resulting from such registry operations, we do not believe we can accurately estimate an appropriate fee for the .BIZ registry at this time. We have provided what we believe to be an adequate reserve as part of our cost per name to accommodate future registry fees due to ICANN.

D13.2.12. Expected revenue associated with the operation of the proposed registry. Please show how expected revenue is computed at each estimated demand level.

The financial projections attached hereto as Exhibit A provide a detailed analysis of the expected revenue for each estimated demand level. The revenue figures are for registration services only, including renewals, and do not include ancillary services (as pricing for such services will be determined closer to the commencement of operations). Revenue from such ancillary services is not expected to materially affect the overall projections set forth on Exhibit A.

Upon commencement of registrations in the registry, the Company should be self funding.

D13.2.14. Business risks and opportunities. Describe upside and downside contingencies you have considered and discuss your plans for addressing them.

iDomains recognizes that there are business risks associated with the introduction of a new top level domain, and has developed contingency plans to deal with such risks as follows.

Upside Contingencies. While iDomains has developed its .BIZ registration demand projections using methodologies and information that it deems reliable, it is difficult to predict with certainty actual demand for the product. It is possible that demand will meet (or exceed) our 10% confidence level. In such case, it is possible that iDomains’ customer service resources may be strained; however, we believe that we can quickly scale such resources to meet demand. We are confident that the registration system operated by CORE will be sufficiently scalable to efficiently process registrations at such increased demand levels. We also anticipate that iDomains’ present facilities and management resources are more than sufficient to meet such increased demand.

Downside Contingencies. It is also possible that demand for .BIZ domain names will reach only our 90% confidence level. In such event, we may need to eliminate head count in certain departments, notably customer service. We are confident that such reduced volume would not affect the viability of iDomains or the .BIZ registry, however, as the cost structure of iDomains can absorb such reduced demand levels according to our projections.

D13.2.15. Registry failure provisions. Please describe in detail your plans for dealing with the possibility of registry failure.

iDomains

The Company will maintain a comprehensive record archiving system including systematic off-site back-ups and data escrow developed under ICANN approved standards, with respect to any services it provides directly. For example, domain history records will be archived off-site. In the event of a potential registry business failure, these records would be immediately available to ICANN-designated parties.

CORE

CORE's plans for the registry failure scenario are involve a series of safety nets related to integrity, availability and confidentiality of registration data.

(a) Contractual stipulations at all levels allow for the replacement of the registry in case of failure but place the same obligations towards domain holders and third parties on the successor organization.

(b) Contracts with infrastructure operators (housing, connectivity providers) contain the obligation to maintain service in case of registry failure for at least 6 months or until a replacing organization can be found. This applies in particular to the TLD server housing providers.

(c) The registry data is backed up and stored at an independent escrow services provider on a daily basis. ICANN or an independent auditor of its choice is enabled to verify the data escrow at any time.

(d) A back-up system is run at a neutral CORE member's site and maintained up-to-date using data synchronization tools.

(e) The regulations of the association allow members to assess themselves contributions to be made available for contingencies. Coming from members, the can be made available directly to interim service providers if need be. The amount provided per member can be computed on a "per domain maintained" basis.

(f) The registry operator keeps adequate reserves per domain. CORE is ready to work with ICANN on the concept of a financial escrow arrangement whereby a reserve covering at least 6 months of operation in an emergency is put in escrow with and independent financial institution.

Attached as Exhibit A to this proposal are detailed pro-forma financial projections.

D13.4. Supporting documentation. The following documentation should be provided in support of the Business Capabilities and Plan section:

D13.4.1. Registry operator's organizational documents. Documents of incorporation (or similar documents).

Attached as Exhibits B and C, respectively, to this proposal are copies of (i) the Articles of Incorporation and (ii) the Bylaws of iDomains, Inc.

D13.4.2. References. A list of significant trade and credit references.

As stated above, iDomains has not engaged in significant operations to date. The references below are for Domain Bank, Inc., iDomains’ sister corporation.

Company Contact Person Telephone

VeriSign Global Julie Nichols 703.742.0400

Registry Services

505 Huntmar Park Drive

Herndon, VA 20170

First Union National Bank Peter Gray 610.821.2287

702 Hamilton Mall

Allentown, PA 18101

Fastnet Corporation David Van Allen 610.266.6700

3864 Courtney St.

Suite 130

Bethlehem, PA 18017

IBS Interactive, Inc. John Paolin 973.285.2600

2 Ridgedale Ave.

Cedar Knolls, NJ 07927

D13.4.3. Annual report. The registry operator's most recent annual financial report (or similar document). Audited financials are preferred.

Attached as Exhibit D to this proposal is a copy of a Balance Sheet, dated September 30, 2000, and an income statement for the nine month period ended September 30, 2000 for iDomains, Inc. As stated above, iDomains has not engaged in significant activity to date.

Attached as Exhibit E to this proposal is a copy of a Balance Sheet, dated June 30, 2000, and an Income Statement for the six month period ended June 30, 2000, for Domain Bank, Inc., iDomains’ sister corporation. As Domain Bank did not engage in substantial operations until the second half of 1999, the financial statements for the period ended June 30, 2000 are the first meaningful statements available for the company.

D13.4.4. Proof of capital. Provide evidence of existing capital or firm commitments of capital. Demonstrated access to necessary capital will be carefully scrutinized.

As shown on the balance sheet of iDomains, dated September 30, 2000, the Company has $1,000,000 USD in cash on hand as an initial financial commitment to this project.

As demonstrated by our financial projections, we believe that the Company has sufficient resources to successfully launch the .BIZ registry. By contacting with CORE to operate a substantial portion of our technical back-end, we can optimize our recourses. Further, cash flow generated during the initial rollout will be more than adequate to fund our marketing plan in the early months of the registry’s operation.

We anticipate that it may become necessary to raise additional liquid capital prior to (or after) commencement of operations. We have had substantial discussions with financial institutions and private capital sources that have indicated a willingness to assist us in meeting any such requirements on a timely basis.

D13.4.5. Proof of insurance. Please provide proof of the insurance described in item D13.1.8.

Attached as Exhibit F to this proposal is an ACORD Certificate of Liability Insurance evidencing the coverage’s described in Item D13.1.8.

III. TECHNICAL CAPABILITIES AND PLAN

Given that the majority of the technical function of the Registry will be provided by CORE, iDomains’ back-end services provider, the bulk of the information in the “Technical Capabilities and Plan” section relates to CORE and its technical resources.

D15. The Technical Capabilities and Plan section should consist of at least the following:

iDomains

The officers of iDomains have extensive experience in the DNS and related technical and policy issues. Domain Bank, Inc., iDomains’ sister corporation, has extensive experience in TLD domain name registrations and related activities. Domain Bank is an ICANN-accredited registrar, and has operated as such since the test-bed period. As such, Domain Bank has extensive experience in building and maintaining a database of domain name registration information, including most information that we propose be kept at the registry for .BIZ. Naturally, as a domain name registrar, Domain Bank and its staff are involved in numerous aspects of operating an internet business, including maintaining and operating a commercial web site; processing payments online; designing and developing software; maintaining appropriate hardware, connectivity and other technical infrastructure; providing customer service via e-mail, fax and telephone; and planning and implementing a marketing plan for an online domain name business.

CORE

Technical workforce

CORE has track record of successful developments in collaborative mode, personnel from various members working together. CORE Registrar SRS operation and maintenance and secretariat have been outsourced to two separate member companies.

It is important to point out that participating members also have extensive experience in shared systems from their own developments. Many member operate shared registration system concepts on their own facilities in order to collaborate with channel partners.

While distributed organizational concept will be maintained to the extent of which projects are posted for member participation , the CORE Registry is directly responsible for the operation of the main SRS site and the Secretariat. The CEO, the CTO and key technical experts are registry staff. Other technical staff members are expected to be seconded part-time or full-time from members. Some experts and consultants employed part-time will be able to work from remote locations.

Systems development tools

CORE’s SRS development concept is based on readily available systems development tool, many of which are in open source. CORE does not rely on proprietary development tools.

Outsourcing

The management of replicable resources such as additional Whois servers and TLD servers are outsourced to members with appropriate resources. In all cases, the ability for CORE Registry to log into the server using secure protocols such as SSH is maintained.

Significant past achievements

Significant past achievements with the framework of CORE itself are discussed under D13.1.4. CORE’s existing CORE SRS is used for over 800,000 domains handled under the responsibility of CORE members who compete against one another.

The existing system demonstrates the ability of CORE’s members to work together (working groups, task forces) despite geographical distances and across diverse types of members companies.

Concepts

Facilities and systems are discussed under D13.2.7 where type of hardware and software is mentioned. CORE has obtained pro forma quote from its member COLT telecom for housing of the main SRS system and connectivity. It is expected that the main Whois server and the primary TLD server will also be hosted and that location. The quote currently provided refers to hosting in Geneva, Switzerland, but alternative options will be analyzed and discussed within CORE’s membership. COLT and other CORE members with major infrastructure operations have facilities in a large number of European cities. Hosting includes secure power supply, surveillance. The Geneva hosting site in walking distance from the offices where most CORE staff currently are located.

All key systems have fully redundant disk and power supply properties. A backup system can replace the production system where they are located.

Thanks to the use of incremental Whois server updates, the load on the main system is limited to actual domain update transactions. Check queries typically account for over 95 percent of transaction load; this load can thus spread over a range of machine and locations.

Summary of system components

Main SRS site

The main SRS system is composed of a back-end machine holding the data and a front-end processor used to handle transaction with the member registrars and as a proxy firewall to insulate the backend. The entire complex is installed behind a packet filtering firewall. The front-end system communicates with the back-end system over a separate network interface in a separate network. The back-end system is linked to separate back-up units. CORE currently uses Informix as a database system. The capacity of the current database and hardware design scales has been tested with several million registrations; current production usage stands at over 800,000 domains.

Backup SRS site

The backup site has an identical configuration possibly with lower performance and availability features. The backup site is feed continuously with data and designed to be able to take over in an emergency within 24 hours.

Whois sites

Several Whois sites are operated on the main SRS site and on other locations (see above). Specialized low-payload queries are available for checking purposes.

TLD Server sites

TLD servers are run on at least 3, later 5 locations. The main SRS location is expected to be a TLD server location as well. A given location may host more than one TLD server. Capacity is adjusted based on the number of registration. This implies that the TLD server concept will be revised as the number of registrations grows.

It is important to point out that the key requirement for TLD servers is access to expert knowledge in managing them. The multiple TLD servers CORE has access in this context to the experience of CORE member with large zone files such as DENIC with over 3,000,000 domain in the .de zone. The members of the DENIC team participate in the Shared Secondary System project led by CENTR.

Current ICANN Root servers operate with a sustained throughput of about 2 Mega Bits per Second (Mb/sec.) of DNS traffic. CORE TLD servers will be deployed with at least a 2 Mb/sec sustained bandwidth available with a burstable bandwidth initially up to 10 Mb/sec. Understand that the largest Burst sustained for over one minute on a ICANN Root server to date is 12 Mb/sec.

CORE TLD Servers will follow specifications outlined in RFC2010.

CORE will make statistics on availability and performance available to ICANN for periodic review.

Secretariat site

The secretariat manages a sizeable intranet specialized email and tracking tools. Experience with .com, .net and .com registrations has shown that secretariat costs ca be kept low thanks to specialized systems developed to increase productivity with interfaces to the main SRS system. The secretariat system is comparable to the SRS client systems run by members. The secretariat tools are developed on a continuous basis by the secretariat and member participating in related projects.

Test SRS site

A test SRS site is available to members on an ongoing basis for testing purposes. The technical concept of the test sites is identical to that of the production system but it is not necessarily loaded with the same data.

D15.2.2. Registry-registrar model and protocol. Please describe in detail.

Registry-registrar model

The registry- registrar model is described in Section E4 of the “Description of TLDPolicies”.

Shared Registry Protocol

The version of the SRS Protocol CORE plans to use for the registry is described in the document “CORE SRS Protocol Specification 1.1”, attached hereto as Exhibit G.

The CORE SRS protocol is based on PGP-signed messages exchanged between the SRS and the member registrar. The member registrar can use a stateless interaction client kit (SRSIO), which CORE provides in source code for Unix. SRSIO transparently handles a socket connection to the SRS and as well as the signing and the signature verification on the member registrar side. An API into the CORE Messaging system is under development.

An alternative transport method is email, the use of which must be specifically authorized for a given PGP signature. Email-based submissions are practical for occasional participants such as approval officers in charge of a given area.

Discussion of CORE SRS protocol choice, protocol convergence

The CORE SRS protocol has been developed by CORE members and continues to be further enhanced. CORE member have no religious preference for a given protocol, but would like to ensure that protocol convergence be a matter of consensus building with diverse inputs.

The current version of RRP protocol has not been retained because it requires higher transaction capacity of the central system only and works with a registry that does not manage contact and domain registrant information. Although RRP now available as an RFC, it is felt that it was developed without consensus building in a secretive environment.

CORE is ready to participate in constructive standards work, which can involve concepts developed by other existing registries, in particular ccTLD registries. Core supports calls for convergence of shared registry protocols but feels that this deserves to be a technical process and that the registrar constituency is a political, not a technical forum. CORE looks forward to participating in developing IETF standards for the robust Registry Registrar Protocols that can cover all types of TLD management systems.

CORE SRS History

The CORE shared registry model and philosophy date back to designs established in 1997 which in turn were partly inspired by established shared registries such as Denic (.de) and Nominet (.co.uk). An intermediary specification was published in the context of the IETF shared registry protocol BOF (CORE-DB) in 1998.

The SRS design process has always been multilateral and was formalized within CORE’s membership in the SRS working group. The SRS protocol has been the focus of extensive consensus-building process involving dozens of competitors who were able to agree on a common approach.

The first implementation of the CORE SRS was developed based on a call for proposals and contract assigned to Emergent Corporation in November 1997. The system was tested extensively by many CORE registrars during 1998. Members' feedback regarding the first implementation was the basis for the second implementation initiated in January 1999.

CORE is currently using the second implementation of the protocol, developed for CORE by CSL GmbH of Duesseldorf, Germany. The code was rewritten from the start and significant platform changes were made. The current system has been designed with Linux as target platform but can run on other Unix version as well. This version was adapted to become a registrar system. The current CORE Registrar system has been running for over one year assisting many organizations participate in the sail and maintenance of nearly one million domains. CORE was a critical participant in the ICANN sponsored Testbed phase. CORE has played a constructive role in the Testbed phase with overcoming technical issues during the initial phase of implementing a Shared Registry in accordance with NSI/DoC and ICANN.

Back End Database Concept

Philosophy

The database concept has been developed with the following requirements in mind:

· Simplicity - the underlying database structure must be easy to understand.

· Unencumbered portability - the database does not depend on proprietary technology and be ported from a given "commodity" type of database system to another.

· Clear documentation of responsibilities - the registry database must show who is in charge of what.

Summary Database Schema

The database schema described here covers the tables used to store permanent data, i.e. the current domain, name host, holder and contact information, as well as the respective historic information. Additional tables not described here are used for processing and verification purposes and depend on the specific implementation of the SRS protocol.

Domain table

Used to hold information on the domain itself along with pointers to related tables. Key data elements are the domain name, the registrar in charge of administering the domain, the record creation and last modification date, the domain status (active, lock, hold) and the expiration date of the domain, as well as pointers to the associated contact record for admin contact, technical contact, zone contact, agent for contact and maintenance service provider (maintainer). The purpose of the maintainer pointer is to document the assignment of handling responsibility to resellers or registry members.

Holder table (Registrant)

For each domain there is a domain holder record. The holder data is kept on a separate table because the domain may change while the holder data is not modified; as a result, the holder record last modification date is only affected if indeed there were change to the holder record. (For instance, the change of a name host would affect the domain record, but it would not affect the holder record). The holder table has the same structure as the contact table, but contrary to the latter stands in a strict one-to-one relationship with the domain table. The holder of a given domain is the Registrant.

Contacts table

The contact table is separate from domain table because a given contact can be associated with many domains. For instance, a technical contact is often an employee or role of a service provider and therefore present in a large number of domain registrations. This is also true for personal domains where an “agent for contact” is specified who may be a different from the domain holder. The contacts are linked to the domain records based on the respective role or quality of the contact. A given contact may be liked to many domains in several qualities at the same time.

Name server or hosts table

A given domain name can be linked to several name server host records. The link between a domain and a name host is based on the name host record identifier, so that it is possible to change the name or the IP number of all domains attached to the same name host record.

There will not be any GLUE generated for hosts not under a SLD with in the zone as specified in RFC2181.

Historic data tables

Historic tables for all the above maintain earlier states of the respective records.

Size, throughput, scalability

The SRS has been tested with the current configuration at sustained rates of one database update transaction per second involving multiple tables. The system has a built-in queuing mechanism in all internal stages where bottlenecks can appear. As a result, the system can take accept burst load of up to 5 transactions per second in its input queue and process them as capacity becomes available.

It is important to note in this context that the CORE Registry is a "full" or "thick" registry where the contact and registrant data is maintained with the domain and name server data. This feature eliminates the problems associated with Registrar to maintaining a separate Whois data in fracture under widely diverging standards. The advantage to the Registrar, ICANN and the public is that there will not separate Whois Escrow implications for registrars participating with the CORE Registry. Should a CORE Registrar become insolvent there is no need to reconstitute the registrants data as all the data elements are contained in a single registry.

Protocol specificities and the concept of a “thick” registry skew comparative transactional capacity statistics. Transactions in the sense of the CORE SRS and the NSI RRP 1.1.0 are not comparable. The CORE system is designed to handle all data whereas the RRP currently only handles domain name strings and name servers. Current RRP volume statistics are inflated by orders of magnitude through the inclusion of check transactions, which go directly on the RRP interface. (A check transaction a request to verify if a domain is available.) CORE's uses Whois servers (which can easily be multiplied) for these verifications. Even if the Whois server is 30 or 60 seconds behind the back end database, this does not materially increase the likelihood of collisions. Experience shows that the number or requests on the CORE SRS is rather in the same order of magnitude as the number of domains and contacts registered. By contrast, current RRP statistics show for a single day a number of transactions higher than the total number of domain s registered since inception.

The current database concept is expected scale as for tens of million domain records. Additional tuning may be required as the database moves into new orders of magnitude. Since the CORE SRS is based on queuing and distributed computing based on inexpensive Intel hardware, additional equipment can be added to create clustered highly robust path to additional system resources should the need arise. As the TLDs grow in size, additional equipment can be installed to manage the load and availability requirements of increased TLD growth or additional Sponsoring Organizations.

Procedures for object creation, modification and deletion

All database records are created, modified and deleted through request issued and signed by members. Each request contains a template. Usually a given request us used to create, modify or delete a single record.

The details are described in the SRS protocol Specification 1.1 (attached)

Registrar Transfer Procedures

See Registration Policy Description and SRS Protocol Specification 1.1.

Grace Periods

Where applicable, similar grace period concepts are used as currently in the case of the .com, .net and org, except that, within the constraints of ICANN policies and prescriptions by an outside Sponsoring Organization, members can decide how they want them implemented and can obtain a change in policy. In particular, the issue of large-scale credit card fraud has been raised. In these cases, the registry will define a policy for investigation and refund if a certain amount is involved in a single case.

Change notification mechanism

Change notification mechanisms are based on the principle that key contact data is in the registry and that in some cases the registry can enhance security and confidence by sending automatic messages in case of changes or other sensitive transactions. This process does not relieve the members of their obligations to manage the interactions with customers.

Reporting capabilities

Statistical and data dump processes run automatically at regular intervals (daily, weekly, monthly). The reporting times are based on UTC and do not change with daylight savings time.

Given their backgrounds, member registrars are in a good position to analyse their own data. To facilitate checking, the registry makes data dump files available to the members can ensure that their systems are in synchrony.

The registry provides statistical data on an equal treatment basis. The members decide jointly what data they wish to be made available to all members and to the public.

If there is an outside sponsoring organization, it has access to detailed statistical data.

The Following reports can be generated by the registry.

· Registration Reports, new domains, name servers, contacts.

· Registrar Account Reports include information on account balances, money transfers, accounting and financial auditing for Sponsoring Organizations.

· Domain, Host, and IP Address reports for each registrar. This report describes all objects owned by each registrar within the backend system.

· Query reports for Whois servers, including what hosts submitted how many queries. Notifications of server availability, query rate and location of query origin.

· Name Server statistics. Nam Server Query Rate (queries per second) Bandwidth utilization.

· Server accounting statistics, system load resource utilization.

· Backup and Dump reports. Date/Time of backup, records in each table or database.

· Security notifications and System Denial of Service detection logs.

D15.2.4. Zone file generation. Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

Frequency

CORE’s plans are to use 12-hourly batch zone file generation in the initial phase. Depending on the progress made in co-operation with other registries for incremental zone file handling, CORE may switch over to this method after a period of extensive testing.

Verification

The zone file is checked for consistency and size. Each zone file is ensured to be within a tolerance for size and correctness, beginning SOA and ending markers. A MD5 hash is generated for each zone and distributed along with the zone to the TLD Server by a secure automated process. Each TLD Server checks the transmitted file against the MD5 hash to ensure the file was transmitted correctly. Operators are notified if a transfer is not completed successfully.

Interface, User authentication

Registry Operator can access all TLD servers using a secure protocol. TLD operator can access server as well, but each machine is configured for unmanned operation. TLD Servers will follow the specifications for Operational Criteria for Root Name Servers defined in RFC2010.

Back-up

TLD server operators keep old files for 7 days plus one file per week for an extended period.

D15.2.5. Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them.

Transfer after verification

Name servers will be located at major peering points throughout the Internet. Servers will be located on secure premises.

Name Servers will run the BIND name server as it is widely available in source and runs on many platforms. This is the most actively developed name server software.

Name Servers will have UDP checksums when generating and sending UDP datagrams.

All Name Servers will be dedicated hosts, not having any other dedicated function such as SMTP, NNTP, etc. All logins other than the console will be over encrypted channel such as SSH.

System clocks will be synchronized via the current version of NTP with authentication. At least 2 NTP peers will be used.

The Name Server will be located in a locked secure data center with restricted access. The power supply will be redundant, Network connectivity will be redundant and System power will be available via UPS.

Network administrators will make them selves aware of CERT advisories and the server will undergo periodical security audits. All name servers will use a C2 secure operating system with system auditing enabled.

Zone transfer access control will be configured so that outbound zone transfers are only permitted to destinations on the servers local network and to networks defined by the operators for debugging purposes.

The AXFR protocol will be used to in preference to FTP for zone file distribution. The NOTIFY and IXFR capabilities will be enabled on all Name Servers.

Recursion will be disabled for queries.

Interface, User authentication

Registry Operator can access all TLD servers using a secure protocol. TLD operator can access server as well, but each machine is configured for unmanned operation

Implicit Back-up

TLD servers automatically maintain old zone files for at least 7 days.

D15.2.6. Billing and collection systems. Technical characteristics, system security, accessibility.

Registrar prepayment mechanism

The .BIZ Registry will operate with a prepayment system analogous to the current cash prepayment mechanism used for .com, .net and .org. Registrars wire the funds to the registry bank account based on their expected registration volumes.

Each Registrar must maintain an account in good standing. Each Account within the back end system is debited once for each domain/year registered. A delete within the specified grace period will credit the registrars account for the number of domain years related to the registration.

A management interface is provided to iDomains by CORE for managing accounts within the backend registry database. This interface is implemented over a secure interface and is implement using the CORE SRS protocol.

All Registrars may inspect their account in real time by issuing protocol level requests or via a Secure Web interface provided by iDomains or CORE.

As and when credits are used for registrations or other charged-for transactions, the SRS automatically calculates the remaining balance of the RCU account. Conversely, deletions within grace period or the refunds causes the member RCU account to be credited. All transactions are logged.

Monthly statements and cross-verification

At the end of the month, the secretariat enters the global SRS-generated changes to the RCU account into the separate accounting system. All other transactions (bank account entries) are recorded immediately. Members receive a statement indicating their start and ending balances as well as debit and credit summaries.

The RCU balance and the balance of the Registry accounting system are cross-verified per month end. To increase transparency, all figures are based on UTC (GMT) time.

Standard backup procedures

The main SRS is backed up daily on tapes kept for various durations. Once month, a tape is generated for long-term (10 year or more) conservation. As and when feasible, this mechanism will be ported to DVD or similar other high-density long-term media. These backups contain the history tables showing earlier states of modified records. Additional protocol-level audit trail log files are also kept.

The standard backup data is stored on an Rsync server where it can be accessed a encrypted SSH link. This can be used by the secretariat to crate additional backup copies.

Real-time remote logging messages

In order to cover the transactions that could be missed between two daily backup procedures, the main SRS site sends log messages to a local repository and to the back-up site. This mechanism is similar to that use to update whois servers.

Data Escrow

The Registry Whois will be escrowed with an ICANN accredited Escrow company using the XML format specified by the ICANN Escrow committee. CORE has obtained a pro-forma offer from Adhersis, a French data storage provider. The Frequency of Escrow will be one per week. The Registry will also make available, to ICANN, additional statistics about registrations so that the escrowed files can be checked for integrity.

Real-time remote logging on back-up srs site

A second Slave database is maintained off-site for realtime backup and archival purposes.

Daily backup within master site

The master database creates backups on tape. The tapes are stored in a Data-Safe style fireproof vault off site.

D15.2.8. Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.

As is the already the case on the CORE system, the whois service is updated at most 30 seconds after the SRS backend. This is achieved through messages send by the SRS backend via the front-end proxy to the whois server (see D13.2.7 and D15.2.1)

For registry operations, CORE Registry will use at least three Whois servers, one of which is co-located with the main SRS site, the other two are operated by two major hosting providers who are also CORE members.

The Whois database is implemented on a distributed database system. The service is updated continually as new registrations come in. The hardware is separated from the main registry network by a firewall.

The load on the whois servers is distributed across several systems by the use of a NAT and Firewall and Load Balancing system. The servers are located in a secure facility and adhere to operating system requirements much like those for Name Servers.

The whois service has a limiting device so that denial of service attacks and data mining operations can be defeated.

The whois database can be extended for Sponsoring Organizations which could allow searching on additional fields such as VAT/EIN or registration number. The Whois system will be compliant with current ICANN policies and procedures.

D15.2.9. System security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.

Security experts and audit

CORE will work on a regular basis with internal and external security specialists so as to ensure the system design remains in line with growing needs and newly discovered security issues in operating systems or other standard software components. The experts regularly review the SRS architecture.

Physical security

The physical access to the main site is protected through the housing services provider and camera surveillance. The systems are located in a closed rack with secure power supply and high-speed connectivity. (See pro forma quote from CORE member COLT Telecom.). Only CORE personnel have access to the closed rack.

Technical security

As discussed under D15.2.1, the SRS backend is protected through the front-end functioning as a proxy firewall, as well as a packet filtering firewall installed between the upstream connection and the entire system. The packet filtering firewall rejects all connections not specifically allowed. The front-end acts as a proxy firewall and, at the same time, takes communications-related processing load off the back-end.

Remote login into the back-end is limited to times when this feature has been activated temporarily by physical on-site intervention. It is achieved through proxied secure sessions via the front-end machine. The cryptographic keys used for such access are specific to the expert enabled to access the system.

Data integrity

The change history audit trail enables verification if changes to the database were performed through the SRS engine itself, or if data was tampered with. The verification of the data integrity can be performed on the backup site.

Confidentiality

Bulk data transfers toward the outside can be executed over secure links or in encrypted form, as the specific transaction may require. The SRS does not store any financial information such as credit card numbers. The SRS protocol technically allows for the use of PGP encryption in incoming data. The degree to which encryption is used in incoming transactions depends on the on the degree of confidentiality.

Availability

The front-end machine are can be duplicated to achieve increased performance and redundancy. The back-end has high availability and redundancy features in line with its role. The different stages of the registration process and other tasks are interconnected by queues. Failure of one component or process does not generally cause any harm, but can slow down the overall performance.

Physical environment.

All server hosts will be located in a secure space such as a locked computer room or a data canter with restricted access. The power supplies are redundant, using batteries, generators or other means to protect against utility power failures. Network connectivity is redundant, so that a single wide area line failure cannot completely isolate the equipment from the rest of the network.

Network security

The system and network administrators will educate themselves about potential threats, and stay current on CERT bulletins regarding network break-ins. The system staff will periodically audit the server host's activity logs and be able to detect attempted break-ins during and after the fact.

Benchmark reference data

As discussed under D15.2.3, the system has been designed for sustained load of one complex update transaction per second. Check queries are directed to separate whois servers where load can easily be spread over several machines. Any comparison with current data shown in the context of .com, .net and .org must take into account that NSI shows check queries as part of the SRS load although it can be handled via separate servers, and that the NSI registry whois service lags 24 hours behind the database. Check queries can easily represent 99% of all transactional volume.

Moreover, CORE’s organizational model allows it to use incentive-disincentive based load management to ensure considerate and economical use of central resources by members.

To maintain high performance of Whois servers, CORE plans to use restrictions affecting repetitive queries from the same source. Volume users of the CORE whois (e.g. whois portals) need to be identified and specifically authorized. Portals exceeding a certain volume will have to indicate their requestor IP number for each query.

D15.2.11. System reliability. Define, analyze, and quantify quality of service.

Availability targets

The target availability parameters are set in consideration of relative cost and volume and nature of service provided. Whenever possible, multiple redundant resources are used.

SRS Site

The SRS itself is not for direct use by the public. Member registrars need to be able to determine the amount of money they are willing to spend for the level of availability in time (95%, 99% or 99.9%). Members’ own systems should be designed to accommodate minor outages or slow response times.

Whois servers

The CORE registry will operate with multiple whois servers updated within seconds. While in isolated cases a given domain may be affected by synchronization problems and not show in the whois, the overall whois service can achieve almost uninterrupted availability (barring concerted, large-scale denial-of-service attacks and unexpected surges in demand). If a given whois server is down, users can normally go on another machine. Whois gateway machines run by members can perform the switch automatically if need be. See D15.2.8.

TLD servers

As there will be at least five TLD servers, zero downtime can be achieved as far as the TLD name service is concerned. While high-availability machines are used, the prime quality effort made for an individual server is data integrity and consistency. The measures to protect the integrity are discussed under D15.2.4. and D15.2.5.

See D15.2.1 and subsequent paragraphs.

Recovery procedures on the main site

In case of failure of a redundant system component (e.g. an individual RAID Disk), the system may made unavailable for the time needed to replace the component even if technically it could continue to operate. System managers may decide to create separate back-ups to capture to exact state of the machine before proceeding. The duration of this type of interruption would not exceed two hours.

In case of failure of a non-redundant components (e.g. a RAID controller), the recovery from backup systems and continuous logs may take up to 8 hours. The main SRS team runs regular fire drills in recovering data from the backup systems to a test system.

Backup SRS site

The SRS backup site is designed to be able to take over of operation at the latest in case the main SRS is affected. Although data is transferred continuously to SRS backup site, a decision to switch will not be taken lightly. The main priority for the SRS site management is to eliminate all and any risk of sending wrong data to the TLD servers. This objective takes precedence over mere issues of comfort, such as the ability to register a new domain immediately or change a name server for the next TLD zone file distribution.

While the technical switch over to the backup site can be performed within hours, the decision to switch will only be taken with at least a day advance notice.

Support to users

Support to users is performed by registrars who compete with respect to service level and price. The CORE Registry Secretariat will redirect inquiries to the respective maintaining member if inquiries are received by email or by telephone. The CORE Registry web site is used to offer neutral information such as member lists and frequently asked questions.

The agreements signed by registrars define their minimum support responsibilities towards customers.

Support to members

The SRS team and the Secretariat support members via email, telephone and via SRS transactions. The Secretariat can interact with members in English, French, German and Spanish; other languages may be added in the future.

D15.3 Subcontractors. If you intend to subcontract any the following:

· all of the registry operation function;

· any portion of the registry function accounting for 10% or more of overall costs of the registry function; or

(a) iDomains proposes to contract with the Internet Council of Registrars (CORE) to provide back-end registry services for the .BIZ registry.

(b) As proposed, CORE would provide the following services described in Section 13.2.1 above: (i) Domain Name Registry Services, (ii) Centralized Whois, and (iii) Third Level Domain Registry Services. Further, in the event that a cross-registry whois service is developed, it is anticipated that CORE will be responsible for its operation with respect to the .BIZ registry.

iDomains plans to operate directly, or outsource, the Directory Service, Domain Monitoring Service and Service History Report Service described in Section 13.2.1.

CORE and iDomains have entered into a Memorandum of Understanding regarding the terms of the subcontract. A copy of the MOU is attached hereto as Exhibit H.

(c) Certain sub-paragraphs of Sections D7, D13 and D15 above include much information on the technical capabilities of CORE. Attached hereto as Exhibit I to this proposal is further information on the technical, financial and management capabilities of CORE. Such information has been excerpted from a Registry Operator’s Proposal prepared by CORE for a separate TLD registry application.

Signature

Henry A. Lubsen, Jr.

Name (please print)

President

Title

iDomains, Inc.

Name of Applicant(s)

September 30, 2000

Date