Registry Operator's Proposal

PRIOR TO REVIEWING THE DESCRIPTION OF TLD POLICIES OR THIS REGISTRY OPERATOR'S PROPOSAL, PLEASE REFER TO THE EXECUTIVE SUMMARY ATTACHED TO THE DESCRIPTION OF TLD POLICIES AS APPENDIX A .

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.

          Afilias, LLC
          c/o Rita A. Rodin, Esq.
          Skadden, Arps, Slate, Meagher & Flom LLP
          Four Times Square
          New York, NY 1003
          Phone: (212) 735-3000
          Fax: (212) 735-2000
          E-Mail: rrodin@skadden.com

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

None, at present.

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

          Afilias, LLC ("Afilias" or the "Company") is a limited liability company organized under the Delaware Limited Liability Company Act, as amended from time to time, in the United States of America.

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

http://www.afilias.com

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

           Afilias does not have a Dun & Bradstreet D-U-N-S number.

D7.   Number of employees.

           Afilias currently has a thirteen member Board of Managers, and no other employees.

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

           Afilias was formed on Monday, September 25, 2000; so it had no revenue during 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.

           Afilias currently has no officers. Each member of Afilias owns approximately 5.25% of the membership interests of Afilias. Please see Schedule A to the Afilias, LLC Operating Agreement ("Operating Agreement").

          1^st Domain.net, a division of G+D International LLC
          Corporate Domains, Inc.
          Domain Bank, Inc.
          DomainInfo AB
          DomainPeople, Inc.
          Domain Registration Services
          Enter-Price Multimedia AG (EPAG)
          Internet Council of Registrars (CORE)
          interQ, Inc.
          NameSecure.com
          Netnames International Ltd.
          Network Solutions, Inc. Registrar Operations
          Polar Software Ltd d/b/a Signdomains.com
          Procurement Services International (Japan), Inc.
          Register.com
          Schlund + Partner AG
          SiteName
          Speednames, Inc.
          Tucows, Inc.

           The interim senior management team of Afilias consists of a thirteen-member Board of Managers. The present Managers elected by the members of Afilias are:

• Tom Barrett, CEO, NetNames International
• Mickey Beyer Clausen, Co-Founder and Vice President, Business Development, Speednames
• Bob Connelly, President, PSI Japan
• Jeff Field, Chairman and Founder, NameSecure
• Moshe Fogel, Vice President of Marketing and Business Development, SiteName
• Phillipp Grabensee, Outside Legal Counsel, EPAG
• Kent Jordan, Vice President and General Counsel, Corporate Domains (CSC)
• Govinda Frauke Leopold, CEO, G+D International, LLC/1st Domain.net
• Richard Lindsay, Director and General Manager, Systems Division, InterQ, Inc.
• Eric Schaetzlein, Co-Founder and Senior Manager, Schlund & Partner AG
• Joseph Kibur, CEO, DomainPeople, Inc.
• Kenyon Stubbs, Chairman of the Executive Committee, CORE; Vice President Domain Bank; Chairman of the ICANN Names Council
• John Wong, President, Domain Registration Services

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.

          All inquiries regarding this proposal should be addressed to:

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.

          Afilias has signed a binding term sheet with Tucows, Inc. ("Tucows") pursuant to which Tucows will provide back-end registry services for Afilias.

          Tucows' information is as follows:

          Tucows, Inc.
          535 Fifth Avenue, 17^th Floor
          New York, NY 10017
          Telephone: 416-535-0123
          Toll Free: (800) 371-6992
          International Toll Free: IAC (800) 371-6992
          Facsimile: 416-531-2516
          E-mail:ross@tucows.com
          D-U-N-S Number: None.

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.

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.

          Formed on September 25, 2000 as a Delaware limited liability company owned by a consortium of nineteen (19) leading ICANN-accredited Internet domain name registrars ("Member Registrars"), Afilias was founded to operate an unsponsored, unrestricted generic Top Level Domain ("gTLD") registry. Appendix A provides brief descriptions of founding Member Registrars. Afilias is considering locating its headquarters in Europe, and will make a final decision upon approval of this application by ICANN.

          Afilias' staff currently consists of a thirteen-person Board of Managers (the "Board") comprised of senior-level executives from the Member Registrars and elected by the Member Registrars. Four three-member Board committees will be formed comprising members of the Board, including an Executive Committee, an Audit Committee, a Nominating Committee and a Compensation Committee. Upon securing approval by ICANN to operate the gTLD, Afilias will hire executive and administrative staff of approximately 25 people over the first four months of operation.

          Afilias has executed a term sheet with Tucows wherein a joint venture between Tucows and Q9 Registration Services will serve as the technology provider to Afilias ("Technology Provider" or "TP") and provide the technical infrastructure and database management of the TLD registry for at least the first two years of operations.

          In addition to working with the TP, Afilias intends to utilize the technical expertise of its Member Registrars to transition the registry operations and develop its own technical infrastructure required to operate and manage the TLD registry starting in the third year of operations. Qualified representatives from Afilias will be selected to form a Technical Review Committee, which will provide guidance both during the development of the registry and on an ongoing basis. Section D15.1 provides short descriptions of the initial members of the Technical Review Committee.

          As discussed in greater detail in the Operating Agreement, each Member Registrar currently owns approximately 5.25% of Afilias, and no Member Registrar will be allowed to own more than 11% of Afilias either as a result of any acquisition or potential consolidation among Member Registrars or otherwise. Afilias will issue two classes of membership interests. Class A membership interests will be issued to the founding Member Registrars.

          To promote competition among registrars and incentivize non-member registrars to promote the new TLD, Afilias will also issue Class B membership to other ICANN-accredited registrars or other entities electing to take ownership positions in Afilias, in accordance with the Operating Agreement. Class B membership interests will represent a maximum of 60% of Afilias on a fully-diluted basis.

          Because Afilias was only recently formed, it has no references or formal alliances. However, trade references for the individual Member Registrars are available upon request.

          Because Afilias was formed on September 25, 2000, it currently offers no products or services. The capabilities of the individual Member Registrars are described in Section D13.1.4 and in Appendix A.

          Afilias was formed on September 25, 2000 as a limited liability company organized under the Delaware Limited Liability Company Act, as amended from time to time, in the United States of America.

          Because Afilias was formed on September 25, 2000, it has no real operational history and currently offers no services or products. The services and products offered by the individual Member Registrars are described in Section D.13.1.4 and in Appendix A.

          While Afilias is a newly formed entity and has no operating history, it is uniquely positioned to build on the core capabilities, technical expertise, operating experience, and extensive market penetration of its Member Registrars. In the aggregate, Afilias' Member Registrars registered over 10 million domain names in their last fiscal year, and represent approximately 80% of all active domain name registrations (DNR) transacted over the last 10 years. In addition to their strong position in the DNR market for the .com, .net, and .org top level domains, the Member Registrars collectively offer a wide range of related Internet services, including country-code DNR, country-code registry operations, Web hosting, ISP services, Web page design, unified messaging, and account management services. Appendix A provides additional information regarding the services provided by each of the founding Member Registrars.

          While five companies were chosen to participate in the shared-registry-system test-bed, only three actually participated, two of which are Member Registrars of Afilias.

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

          Afilias' mission is to expand the Internet as a global resource that fosters communication, commerce and community by introducing, marketing, and managing a new global domain name to Internet users around the world. Through the introduction of a new unrestricted top-level domain name, Afilias will endeavor to transform the Internet into a truly global marketplace. Afilias will leverage the expertise and experience of its Member Registrars to operate a more efficient registry service in markets that are currently underserved by the existing registry service. Afilias is committed to enhancing the DNS while maintaining the stability of the Internet.

          As previously noted, Afilias' interim senior management team consists of a thirteen-member Board comprised of senior management executives from the Member Registrars. The Managers have been elected to the Board for terms ranging from one to three years and will elect a chairman to preside over the Board. The list of Managers on the Board and their respective terms is provided below. Resumes for each Managers are provided in Appendix B:

Three-Year Term Members

• Kent Jordan, Vice President and General Counsel, Corporate Domains Inc.

• Richard Lindsay, Director and General Manager, Systems Division, interQ, Inc.

• John Wong, President, Domain Registration Services.

• Bob Connelly, President, Procurement Services International (Japan), Inc.

Two-Year Term Members

• Mickey Beyer Clausen, Co-Founder and Vice President, Business Development, Speednames

• Eric Schaetzlein, Co-Founder and Senior Manager, Schlund & Partner AG.

• Tom Barrett, CEO, Netnames International Ltd.

• Jeff Field, Chairman and Founder, NameSecure.com, Inc.

• Moshe Fogel, Vice President of Marketing and Business Development, SiteName

One-Year Term Members

• Joseph Kibur, CEO, DomainPeople, Inc.

• Phillipp Grabensee, Outside Legal Counsel, Enter-Price Multimedia AG.

• Kenyon Stubbs, Chairman of the Executive Committee, Internet Council of Registrars; Vice President, Domain Bank, Inc.; Chairman of the ICANN Names Council

• Govinda Leopold, CEO, 1st Domain.net, a division of G&D International, LLC.

          The Board will elect the following four board committees that will set the direction of Afilias on an ongoing basis.

Executive Committee

          The three-person Executive Committee shall be chiefly responsible for supervising the executive officers of Afilias and liasoning with them to provide Board input on management issues. Members of the Executive Committee will be elected by the Board upon approval from ICANN to operate the new TLD.

Audit Committee

          The three-person Audit Committee will be responsible for recommending the independent public accountants as auditors for Afilias, reviewing the audit and management analysis performed by the independent public accountants, managing the internal accounting controls, and developing the audit planning process. Members of the Audit Committee will be elected by the Board to operate the new gTLD.

Nominating Committee

          The three-person Nominating Committee will be responsible for reviewing and recommending candidates to the Board for Board vacancies, recommending criteria for Managers' tenure and nomination criteria. Members of the Nominating Committee will be elected by the Board upon approval from ICANN to operate the new gTLD.

Compensation Committee

          The three-person Compensation Committee will be responsible for reviewing and recommending salary levels, increases, and benefit programs for officers and employees of Afilias. Members of the Compensation Committee will be elected by the Board.

          Upon approval from ICANN to operate the new gTLD, Afilias will recruit, either through its own efforts or through a retained executive search firm, a senior management and administrative team for Afilias. Key executive-level positions will include the following:

President

          Responsible for coordinating the efforts of the other executives, the Board and Executive Committee, implementing the overall vision and mission of Afilias and interfacing with ICANN on significant policy issues.

Chief Financial Officer

          Responsible for managing the financial viability of Afilias and managing revenue recognition related to the billing and collection of registration fees from its registrar customer base. The Chief Financial Officer will manage a 2-person staff, including a Staff Accountant and an Accounts Operations Manager responsible for billing.

Chief Operating Officer/Chief Technical Officer

          Responsible for managing the technical operations of Afilias. The Chief Technology Officer will manage the relationships with Afilias' technology vendors and sub-contractors, liaison with Afilias' Technology Review Committee, manage the transition of the registry operations from Tucows to Afilias during the second year of operations, and recruit the necessary technical staff to operate the registry on an ongoing basis.

Chief Marketing Officer

          Responsible for implementing Afilias' marketing plan as outlined in Section 13.2.4 and developing ongoing marketing, branding, and public relations initiatives. The Chief Marketing Officer will also be responsible for transitioning Afilias' marketing function from outsourced professional service providers to an internal staff within Afilias, as required.

Vice President, Policy and Registrar Relations

          Responsible for ensuring high-quality customer support for Afilias' registrar customers and for refining and developing additional policy in conjunction with ICANN relating to services provided to such registrar customers. Afilias expects this role to be critical during the Sunrise Period described in Section E15 of the Description of TLD Policies, during which time domain name registrations must be vetted against trademark registrations. This person will also serve as an ombudsman, assisting in dispute resolutions as set forth in Section E15 of the Description of gTLD Policies.

          Additional administrative staff positions required to operate Afilias may include a Human Resources/Office Manager and a General Counsel. Proposed salaries associated with each executive, administration, and staff position identified above can be found in the Headcount Worksheet within Appendix C.

          As of the date of the application, Afilias will consist of its Board of Managers, with no additional executive or administrative staff. Afilias will benefit from the collective experience of its participating Member Registrars to transfer the expertise required to build its staff within six months of approval of the application by ICANN, enabling Afilias to set a target date to begin offering its services in Q3 2000. High-growth Member Registrars, including Tucows, Register.com, Inc. and Network Solutions, Inc. have proven capabilities for scaling their staff to meet the needs at peak level demands, and Afilias will benefit from the transfer of knowledge from its Member Registrars to successfully build its staff as demand levels require.

          In addition to its elected Board, Afilias has retained a variety of professional service providers to assist in its development and in the preparation of this proposal to ICANN. Specifically, Afilias has retained Skadden, Arps, Slate, Meagher & Flom, LLP as its outside legal counsel to advise it during its formation and to coordinate the efforts of Member Registrars in preparing this proposal for ICANN. Afilias has also retained Hill and Knowlton to assist it in developing an international public relations campaign. As a subsidiary of WPP, Hill and Knowlton also brings the expertise of Blanc & Otus, and the advertising and marketing expertise of OgilvyOne. Finally, Afilias has retained KPMG to provide business planning advisory services relating to the development of its business plan.

          Afilias has partnered with Frank Crystal & Co., Inc. to obtain commercial general liability insurance coverage with an aggregate liability limit of $2,000,000. Afilias will also obtain additional insurance as deemed appropriate by management that will provide additional protection to Afilias for risks inherent in its operations, including potential liability for intellectual property infringement and for negligent acts, errors or omissions that may arise out of the processing of electronic data for others and for related computer services. Afilias is committed to ensuring that appropriate policies are secured at all times and will consult with ICANN on an ongoing basis regarding appropriate levels of coverage.

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

          As a registry operator, Afilias will provide the following services and support to its registrar customers:

1)       Registration Services

a)       Domain Name Registration

          Afilias' core service will focus on registering domain names submitted by its ICANN-accredited registrar customers to its TLD registry. Afilias will register the domain names submitted by registrars as a general policy for a term ranging from two to ten years, as selected by registrar customers. Afilias will implement a five-day grace period to cancel a registration, which will trigger a refund to the registrar.

b)       Domain Name Renewal

          After two years of operation, Afilias will provide domain name renewal services whereby registrars may renew domain names with the registry on behalf of their registrant customers for an additional term, which can range in length from one to ten years in yearly increments. In addition, as further described in Section E10 of the Description of TLD Policies, Afilias will automatically renew registrations by one year when domain registrations expire. Renewals, however, may be canceled by registrars for a refund of the renewal fee within 45 days of the renewal.

c)       Registrar Transfer

          When a registrant transfers a registration from one registrar to another, Afilias will automatically extend the term of the registration for an additional year.

d)       Whois Lookup

          Afilias will operate a registry-level Whois service to allow third parties to conduct searches on domain names to determine their availability and ownership.

e)       Registrar Billing/Status Reports

          Afilias will provide customized billing and registration activity reports to registrar customers to provide continuous communication regarding account status and requests for minimum account deposits.

2)       TLD Marketing

          Through its appointed marketing partners, Afilias will market and brand the new TLD worldwide. Through these marketing efforts, Afilias acts to fulfill ICANN's mission to enhance the functionality and usability of the Internet on a global basis. These marketing efforts are intended to create enhanced global awareness of the Internet, its growth, and its evolution from a saturated dot-com brand to a resource with broad appeal that transcends cultural boundaries.

          The overarching strategy for Afilias is to create a brand that brings the Internet and domain name registration to individuals and businesses everywhere. In addition to investing in the brand by advertising it in a range of markets worldwide, Afilias is uniquely positioned to utilize its Member Registrars to market the TLD to their registrant customers, triggering a viral, cost-effective marketing campaign.

3)       Rebate Program

          Afilias will institute a rebate program during each year of operation. Through this rebate program, "active registrars" (defined as those ICANN-accredited registrars that have registered domain names in the new TLD) will be eligible to receive a rebate based on the amount of domain names registered in the registry. Afilias will allocate 25% of cash on hand (less allocations for operating expenses) to distribute among these active registrars. This amount will be distributed to the registrars in proportion to the number of registrations registered by that registrar during the relevant period.

          Afilias will derive revenue chiefly through domain name registration and domain name renewal fees.

Domain Name Registration Fees

          Afilias will charge US$5.75 for each domain name registration per year. Registrars will be required to register each domain name for a minimum of two years and a maximum of ten years in one-year increments. As such, registrars will be billed US$11.50 for each two-year initial registration. Afilias will collect registration fees for the total term at the time of registration.

Domain Name Renewal Fees

          Similarly, for registration renewals, Afilias will charge registrars $5.75 for each renewal year. If a registrant wishes to renew a registration, the renewal must be for a term of between one and ten years. These revenues will begin during the third year of operations when the first round of two-year registrations become due for renewal. Afilias will collect renewal fees for the total renewal term at the onset of the renewal term.

          Afilias has chosen a flat annual registration and renewal fee revenue structure for two primary reasons. First, registrars have become accustomed to the annual-fee pricing structure developed by Verisign Global Registry Services in its relationships with ICANN-accredited registrars. Second, Afilias believes that Internet-based commerce is currently not well-suited for discrete micro-payments based on specific transactions performed by the registry.

Market Definition

          The market is defined as the total worldwide number of registered domain names. In terms of unrestricted TLDs, 69% are registered in the US.

Web Address Volume to Date - Domestic vs. International

*Source: NSI (dotcom.com)
universe of .com, .net, .org sites

Current Registrant Profile

          According to recent statistics*, 80% of domain names have been registered by businesses and 20% by consumers. Of businesses, 67% employ 1-4 people. This suggests three distinct groups:

• 20% Web-savvy consumers
• 54% Web-savvy small businesses owners (1 to 4 employees)
• 26% Web-savvy decision makers (IT professionals, webmasters) at mid- to large-sized businesses

Registrant Motivation

          Understanding why people register domain names will help tailor Afilias' key messages to meet the needs of the various customer segments.

• Consumers

          This group of registrants primarily registers domain names for the purpose of setting up personal or non-business homepages.

• Small Businesses

          Typically, a small business will register a new domain name when launching a new business, product, or service to communicate the new offering.

• Mid- to Large-Size Businesses

          These companies generally register new domain names to publicize new products and services, to protect trademarks, and to increase brand awareness. This group of registrants frequently register similarly spelled domain names to protect their brand assets.

Market Size

          There is not a direct correlation between the number of Internet users and the number of domain names registered in any given market. However, countries with high penetration rates typically have high registration rates. The following sections demonstrate this premise.

Internet Users

          The following chart indicates the number of Internet users and penetration rates in several major markets. Users are defined as adults over 18 who have accessed the Internet within the past 30 days.

source: Angus Reid "Faces of the Web" study, Jan. 2000

          Some markets, such as China, which have large populations, do not necessarily have high penetration rates, but do have a high number of Internet users when compared to markets, such as Australia, where the population is relatively small.

Current Worldwide Registrations

          The following chart indicates the total number of domain names, including .com, .net, .org, and all ccTLDs, registered worldwide.

source: Center for Next Generation Internet

Accessibility

          While certain developing markets are believed to represent tremendous growth potential, restrictive government policies as well as an inadequate infrastructure offer limited growth potential in the near future. For example, there are 1.09 million domain names registered in Australia, which has an online population of 8 million, while in China, there are 71,000 registered domain names, despite a total population of 8.1 million Internet users. In Latin America, two countries account for a total 80% of all registered domains in the region.

Market Demand

          Even though growth rates in other countries and regions are higher than in the US, the absolute number of new Internet users in the US is still increasing, due to sophistication of the market and the large potential base of users. The same holds true for the growth of domain name registrations. In all likelihood, the US will continue to represent the largest market in terms of future registrations.

          The following chart indicates the projected number of Internet users in major markets over the next three years.

Ogilvy Interactive Analytics department, based on Angus Reid '99 data

The total number of domain names registered in 1999 was 43,225,000. By the end of 2000, this number will increase to 57,222,000. Growth is expected to decline thereafter, despite reports that countries such as China, India, and Indonesia will experience an Internet boom.

          The following chart indicates projected growth of domain name registrations in major markets over the next three years:

Ogilvy Interactive Analytics department, based on CNGI '99 data

          The above chart does not take into consideration the number of domain name holders who will effectively re-register their existing .com, .net or .org in a new TLD to protect their brands. This will increase the number of new registrations each year, although an exact figure cannot be calculated due to the unprecedented introduction of a new gTLD.

Technical Opportunity

          In addition to the global demand for domain name registration in a new unrestricted TLD, Afilias believes that a substantial business opportunity exists from the enhanced registry functionality that Afilias' registry will offer, which surpasses the functionality of the incumbent gTLD registry. More specifically, unlike the incumbent gTLD registry, Afilias' registry model will provide a shared, near real-time Whois service, whereby registrants can search one database rather than searching every registrar's Whois database to determine whether a particular domain is already registered.

          Furthermore, the new registry architecture will automate several functions that are currently performed manually. These include the ability to track, in real-time, status updates of customer registrars, custom reports for registrars, near real-time zone file updates, and over the medium term, real-time updates of the DNS zone files. By automating these processes, registrars can expect meaningful operational cost savings. As such, Afilias, through its technological solutions, will provide indirect business opportunities to its customer registrars through lower operational costs.

Competition

          Afilias faces competition from several potential competitors as an operator of a new gTLD. Afilias' competitors may include:

Afilias will compete against the operators of the existing gTLD and ccTLD strings that enjoy a first-mover advantage, and that in some cases, have substantial financial resources to launch a counter-marketing campaign against the new gTLD.

A variety of other organizations may be submitting proposals to serve as a registry operator for a gTLD. These may include other domain name registrars who are not Member Registrars of Afilias, Internet access providers and Internet service providers.

Competitive Advantage

          Afilias' strongest competitive advantage is its unique ownership structure that combines the collective expertise of its Member Registrars. Additionally, given that Afilias' owners also serve as Afilias' customers, they will continually look for ways to improve the functionality and services offered through the registry. Furthermore, Afilias' ownership structure provides a built-in distribution mechanism to market the new gTLD.

          An additional competitive advantage includes the policies set by Afilias, which Afilias believes will enhance competition among registrars and eventually other TLD registries as other TLDs are released by ICANN. Afilias will provide incentives to non-member registrars in two ways to embrace the new gTLD. First, Afilias will provide qualified ICANN-accredited registrars the opportunity to take an equity position in Afilias. Second, Afilias will implement an annual rebate program open to any ICANN-accredited registrar that registers a domain name in the new gTLD.

          Afilias' goal during the release of the new gTLD is to provide a very successful proof of concept for releasing new TLDs into the market. By marketing the gTLD successfully and by implementing a scalable yet reliable and high-quality registry, Afilias hopes to illustrate to ICANN the very strong demand for new TLDs overall. This, in turn, should prompt ICANN to release additional generic and restricted TLDs, thereby fostering enhanced competition among TLD registries.

          Afilias has appointed OgilvyOne Worldwide and Hill and Knowlton Public Relations to develop a comprehensive global marketing plan. The agencies were chosen because of their expertise in launching and building brands on a worldwide scale through their respective networks. Both agencies are owned by the WPP Group, the world's largest agency network. As sister companies, the agencies will work together to create and execute a seamless marketing campaign. A confidential, detailed description of the Marketing Plan is provided in Appendix D.

          The anticipated demand for domain name registrations in a new unrestricted TLD issued by ICANN (as defined by the number of new domain name registrations) is represented quantitatively in Table 1. These estimates consider several factors, including the following:

• A conservative approach to demand given the experimental "proof of concept" launch of a new TLD registry;
• Demand forecasts that consider Member Registrars' forecasts for growth as well as market research identifying the current and forecasted registration demand; and
• Demand forecasts based on viable response rates to the marketing plan devised in Section 13.2.4 and Appendix D.

* Afilias will not accept registrations for 30 days after the Sunrise Period to ensure that all properly submitted Sunrise Period registration requests are properly processed.
Note: Figures presented in the financial model may vary slightly depending on the proposed launch of the registry.

          Significant assumptions underlying these projections at the 10%, 50% and 90% confidence levels include the following:

1)   1^st Choice String Awarded

          These projections assume that Afilias' top TLD string, .web, is awarded. Afilias' market research illustrates that .web is the most attractive string to consumers, therefore providing evidence for strong potential demand.

2)   Domain Name Registration Base Rate - [CONFIDENTIAL]

          Afilias believes that after the first six months of registry operations when trademark owners and early adopters have registered their domain names in the new TLD, demand will drop to a base level, from which incremental growth will occur. Afilias forecasts "base-rate" registrations for the first month of the Start-Up Period (as defined in Section E12 of the Description of TLD Policies) at the three confidence levels to be the following:

3)   Registration Growth Rates - [CONFIDENTIAL]

          Afilias believes that growth in demand for domain name registrations in the new TLD will slow with time. Furthermore, in constructing the demand forecasts for registrations, different growth rates have been utilized starting after the initial Start-Up Period, as depicted below:

     Months 14-18          3% monthly growth

     Months 19-30          1% monthly growth

     Months 31-60          0% monthly growth

     Months 14-18          4.5% monthly growth

     Months 19-30          1.5% monthly growth

     Months 31-60          0.5% monthly growth

     Months 14-18          6% monthly growth

     Months 19-30          2% monthly growth

     Months 31-60          1% monthly growth

Market Factors Impacting Demand

          While it is virtually impossible to forecast with precision domain name registration demand, particularly beyond a three-year period, Afilias believes the following market conditions and internal capabilities will impact demand for its registry services.

Competition

          VeriSign Global Registry Services, the registry operator division of Network Solutions, Inc., benefits from its dominant position as the exclusive registry for the .com, .net, and .org gTLDs. Beyond the introduction of repurposed ccTLDs (e.g., .tv, .cc, .to), Afilias represents the first wave of competition to the incumbent gTLD registry operator. After awarding Afilias approval to operate the registry for the new gTLD, ICANN may quickly authorize other gTLDs that may compete with Afilias' chosen gTLD. Increased competition from companies operating unrestricted TLDs may have a significant negative impact on the anticipated demand for Afilias' gTLD, saturating the market with gTLDs and, if introduced soon after Afilias' gTLD, reducing the initial adoption of Afilias' gTLD and its long-term growth potential.

          Afilias may also face competition from more niche or restricted TLDs that provide domain names with more descriptive information than an unrestricted TLD could offer. For instance, if, following industry trends, more businesses than individuals register domain names (80% versus 20%, respectively, according to www.dotcom.com), newly-released business-related restricted TLDs may compete with Afilias' chosen gTLD, thereby siphoning away some of Afilias' expected demand. If these competitive market conditions prevail, Afilias can expect demand levels described at the 90% confidence level or below.

          Conversely, if ICANN chooses not to issue additional TLDs in the near future, demand for Afilias' registry services should remain strong. In this scenario, Afilias can expect demand levels represented at the 50% or 10% confidence levels.

New Technologies

          The emergence of new technologies may also have a significant impact on the demand for Afilias' registry services. In particular, new domain name directory technologies and software may be introduced that eliminate the need to register each domain name individually, significantly reducing the forecasted demand for domain name registrations. The imminent introduction of these new technologies may result in demand levels described at the 90% confidence levels.

Marketing Effectiveness

          Another key component impacting the demand for the new gTLD is Afilias' effectiveness in marketing the new gTLD. Afilias' TLD is positioned to have global appeal, and as such, it must be marketed to the various growth regions effectively. Afilias must quickly create brand awareness among both existing registrants (to extend their existing brands to the new gTLD) and to potential registrants, who are yet to register a domain in either a ccTLD or a gTLD. Afilias believes that it will be able to cost-effectively encourage registrants to re-register their domain name in the new TLD through its built-in Member Registrar distribution mechanism. Effectively establishing and communicating Afilias' brand on a worldwide basis should build demand levels forecasted at the 50% or 10% confidence levels.

Pricing/Fees on Demand

          Afilias intends to price the registration fees at a rate that is less than the current industry standard fee of $6 per registration for domain names on the .com, .net, and .org gTLDs. Afilias cannot guarantee that its customer registrars will pass this reduced price to their registrant customers, thus it is unlikely that pricing will have a significant effect on demand.

Anticipated Demand Phases

          To manage demand for domain name registrations in the new gTLD most effectively, Afilias anticipates three distinct "demand" phases for registration, the first two of which are set by policies implemented by Afilias.

    (1)  Sunrise Period

          As described in Section E15 of the Description of TLD Policies, Afilias will implement a Sunrise Period to permit owners of subsisting trademark or service mark registrations having national effect and that are issued prior to October 2, 2000 to be eligible to register their trademark or service mark as a domain name, using ASCII characters only. Registrants must certify to the registrar that they are eligible to register a domain name during this period. All domain name registrations obtained during the Sunrise Period will be for a minimum term of five years, to be payed by the registrant in advance.

          Afilias anticipates that parties may dispute registrations that are granted during this period. Accordingly, Afilias will invoke a 90-day dispute period immediately following the end of the Sunrise Period to provide third parties with the opportunity to contest registrations obtained during the Sunrise Period.

          Additionally, the evaluation period will provide Afilias with the opportunity to examine the operation of the registry and round robin systems and make any necessary modifications to the system prior to the opening of the TLD to the general Internet community. [THE FOLLOWING SENTENCE IS CONFIDENTIAL] Afilias estimates, with a 50% confidence level, that during the two-month period, a total of 700,000 trademarked domain names will be registered.

    (2) Start-Up Period

           Afilias anticipates a significant rush for domain name registrations during the Start-Up Period, which will commence immediately following the aforementioned examination period. During the Start-Up Period, anyone may apply for a domain name registration, and may seek an initial registration term of a minimum of two years and a maximum of ten years, in one-year increments. Afilias estimates that the Start-up Period will last three months. [THE FOLLOWING SENTENCE IS CONFIDENTIAL] Afilias forecasts, with a 50% confidence level, that over 1.875 million domains will be registered during the Start-Up Period.

     (3) Steady-State Growth Period

          After the first six months of registration, Afilias assumes that registration demand will drop to a base level, [REMAINDER OF THIS PARAGRAPH IS CONFIDENTIAL] from which, at the 50% confidence level, it will grow 4.5% on a monthly basis for the first six months of the steady-state growth period. Afilias anticipates with a 50% confidence level that the growth rate will slow to 1.5% starting the sixth month of the steady-state period, and will level off at a 1% growth rate 12 months thereafter. Afilias anticipates with a 50% confidence level the base-rate of registration to total 300,000 during the first month of the Steady-State Growth Period.

          One of Afilias' greatest strengths is its ability to leverage its Registrar Members and partners to provide the necessary financial, human capital, and technical resources to meet the anticipated demand described at all three confidence levels. A review of these resources is provided below, and a time line describing the acquisition of major resources and other major events during the initial development of Afilias is provided in Figure 2. Table 3 provides estimates of the major resources required as well as the major costs associated with operating Afilias over a five year period at each confidence level.

Financial

          [FIRST PARAGRAPH IS CONFIDENTIAL]

          Afilias is currently self-funded and anticipates financing any immediate cash requirements through additional capital calls and, if necessary, through debt financing. Afilias anticipates requiring approximately $5,000,000 in additional capital in the 50% confidence level scenario. Afilias will secure the necessary capital to build Afilias upon ICANN approval through a variety of strategies. Afilias has already collected US$1.34 million in financing primarily from its Members. Upon commitment from ICANN to operate the new gTLD, Afilias will require its Member Registrars to contribute additional capital to Afilias to secure office space, hire its executive and administrative staff, and execute the initial phases of its marketing plan, which may total approximately $3.45 million. If necessary, Afilias will secure debt financing from a reputable commercial bank to cover the balance of any other additional capital required.

          By the third year of operations, Afilias will consider transferring the registry operations from Tucows to its in-house technology staff. Afilias will rely on existing cash to finance the hiring of the additional staff required to manage and operate the registry and the leasing of required equipment to build the registry at the 50% and 10% demand forecast confidence levels. If demand for domain name registrations only reaches those registrations forecasted at the 90% level, Afilias will in all likelihood not bring the technical capabilities in-house, and instead will continue to outsource this function.

Technical

          As stipulated in the Term Sheet between Tucows and Afilias, Tucows will provide the appropriate hardware, software, systems and technical staffing required to meet registration demand at the 10%, 50% and 90% confidence levels. During this period, Afilias' technical requirements will be limited to its five-person technical staff, described in more detail below.

          During the second year of operations, Afilias may begin transitioning the registry operations from Tucows to its own facilities, and thus may require additional technical staffing resources. It may also require non-staff-related technical resources, including leasing the appropriate equipment required to operate the registry, such as database servers, front-end servers, switches, routers, software, processors, and storage devices. Additional technical resources required during the phase are described in more detail in Section D13.2.7.

Staffing

          Staffing required to implement this business plan are described in the following categories.

Technical

          Afilias will initially require a four-person technical staff, including an Operations and Engineering Manager, a Senior Systems Administrator, a Systems Administrator, and a Chief Technology Officer who will manage the technical staff. The technical staff will share one assistant.

          To successfully integrate all technical capabilities in-house by the third-year of operations, Afilias will hire additional technical staff to design and build the infrastructure during the third quarter of the second year of operations. These staff requirements and their projected hire dates include the following, at the 50% confidence level:

          To meet registration demand and the cumulative growth of new registrars, Afilias will hire an additional 10 technical support staff personnel in both the fourth and fifth years of operations, as necessary, at the 50% confidence level.

Marketing Staff

          The Chief Marketing Officer will initially be responsible for a two-person marketing staff initially, including a Marketing Manager and a Public Relations Manager. The Chief Marketing Officer will share an assistant with both managers. Two Sales Managers may be hired, the first in year 1, the second in year 2, to provide regional marketing and sales assistance in the United States and Pacific Rim, respectively. Afilias does not intend to employ a significant marketing staff given its intention to employ outside consultants for marketing, advertising, and public relations services.

Billing Customer Support

          In addition to the technical customer support staff discussed in more detail in the Technical Staff section, Afilias will also hire a billing customer support staff, which will include a Registrar Relations Manager, a Customer Service Manager, a Senior Customer Service Representative and three Customer Service Representatives to manage all billing-related customer support issues. Unlike the technical customer service staff, which will operate on a 24/7/365 basis, the billing customer support team will operate on a single 8-hour shift per day/5-days a week basis. In addition to customer support staff housed in the headquarters location, Afilias may, if circumstances warrant, locate additional customer support staff, namely a Customer Service Manager, in satellite offices in the United States and the Pacific Rim.

Registry Technical Infrastructure

          As stipulated in the Term Sheet between Tucows and Afilias, Tucows will be responsible for acquiring the necessary systems and facilities required to operate the technical infrastructure of the registry for at least the first two years of operation. As discussed in previous sections, Afilias will consider building its own registry during the second half of the second year of operations, and thus, may need to acquire the necessary systems and facilities to (1) ensure a smooth transition between Tucows and Afilias and (2) meet the forecasted demand for registration services on an ongoing basis.

          A brief outline of the necessary systems and facilities required to build and manage the registry on an ongoing basis include the following at the 50% confidence level.

Server Space

• A maximum of six remote, geographically-distributed, co-located data centers for propagation of the Whois database and zone file updates with a recognized hosting company (e.g., Exodus Communications, Global Crossing)
• Each datacenter will require a maximum of five racks of server space.
• A centralized Network Operating Center (NOC) with 20 racks of server space.

Equipment and Software

• 6 Sun E6500 Servers
• 2 EMC Storage Devices
• 40 x 86 Dual 1 Ghz Servers
• 32 Sun E450 Quad Processor Servers
• 16 Cisco 7200 Routers
• 16 Foundry BI 8000 Switches
• 6 Oracle Enterprise (Cluster) software packages
• 1 package of registry operator software from Tucows

          A more detailed description of the required systems and technical facilities required to successfully transition the registry operations from Tucows to Afilias can be found in the attached Technical Operating Plan.

Billing System

          Afilias will develop a billing reporting system to be managed by Afilias' Accounts Receivable Manager to monitor all billings to customer registrars. Afilias' administrative customer support staff will be responsible for interfacing with customer registrars regarding any billing questions.

Office Space

          Other facilities required by Afilias include office space and equipment for the executive and administrative staff. Afilias will secure an 8,000 square foot office space at its headquarters location. These headquarters will house its initial staff which will approximate 25 people, and will require office furniture, including desks, chairs, conference tables, a telephone system, computers, fax machines, copiers, and a corporate intranet system. Quantities and the costs associated with these items are provided in more detail in the "Costs" section of Appendix C.

          Afilias has been structured to operate without an initial significant human capital investment by partnering with Tucows to staff and manage the technical infrastructure required to operate the registry during the first two years of operations. Tucows will be responsible for providing additional technical staff necessary to meet increased demand for registrations. Afilias will expand its staff in other functions as necessary, but foresees little expansion required for non-technical functional areas. Staffing levels required to operate Afilias and manage the registry and meet customer demands in the Sunrise, and Start-Up Periods of operations are described in Section D13.2.6.

Office Expansion

          In addition to the headquarters location, Afilias will consider opening a 1200 square-foot satellite office on the east coast of the United States that will house the Customer Service Manager, Marketing Manager, and an assistant, and provide additional office space for traveling officers of Afilias. Should Afilias choose to operate the registry on its own, it will significantly expand this office space to house the technical team required to operate the registry starting the third year of operations.

          During the first half of the second year of operations, Afilias intends to open a second satellite office in the Pacific Rim to provide tailored customer service and sales support to Asian and Pacific Rim customers. This satellite office will consist of a 1200 square-foot facility that will house a Sales Manager, Customer Service Manager, and an assistant, and provide additional office space for traveling officers of Afilias.

Training Initiatives

          Afilias will recruit executives with proven industry experience to fulfill its executive-level positions, thereby requiring little formal training initiatives for the executive team. Two staffing functions, however, where Afilias foresees the need for formal training are customer service and technical operations.

Customer Service

          Selected members of the Board of Managers, in conjunction with the Chief Technology Officer, Vice President of Policy and Registrar Relations, and the Human Resources Administrator will develop a targeted customer service training program for Afilias' billing customer service team to ensure that consistently high levels of customer service are provided during all three projected demand phases for registry services. Furthermore, this training program will institutionalize proper protocols for managing all potential service requests from registrar customers.

Technical Staff

          The Chief Technology officer, in conjunction with the Human Resources Administrator and a representative from Tucows will implement an annual week-long training program for Afilias' junior technical staff that will provide an introduction and updates to the major technical issues relating to the operations of Afilias Registry.

Hiring Policy

          Afilias aims to select employees with the best job-related qualifications. Specific components of Afilias' hiring policy include the following:

Compliance

          Employees will be selected without regard to race, color, religion, sex, national origin, marital status or handicap subject to job requirements and regulations. Furthermore, Afilias will comply with all applicable national and regional employment laws.

Sourcing and Recruitment

          Afilias will retain an executive search firm to conduct a worldwide search for its senior management team members. Afilias will select a search firm with strong experience and industry contacts in the Internet industry and a strong international presence. To the extent possible, Afilias will also leverage the resources and industry relationships of its Member Registrars to identify potential candidates for the executive and administrative staff of Afilias.

          For junior staff, and in particular, junior technical staff requirements which may arise beginning in the second half of the second year of operations, Afilias will place advertisements in classified pages of national newspapers and/or business magazines and on high-reach job sites on the Internet. The senior-level executives in each functional area will be responsible for drafting and releasing advertisements and managing the recruitment process for these junior-level positions.

          Wherever possible, job openings will be filled through internal sourcing primarily through a job-posting system, which will provide employees with the information they need to nominate themselves for open positions. All eligible candidates will be given consideration, but the system will not guarantee an interview, selection or promotion.

Selection Process

          Afilias will follow the direction provided by the executive search firm for the initial stages of the hiring process. Afilias expects a standard selection process to require approximately three months.

          Afilias and the executive search firm will adhere to best practices regarding interview topic information. More specifically interviewers will be restricted from discuss the following information:

• Age, race, color, creed, national origin, citizenship, and religion
• Sex, sexual preference or orientation
• Marital status or number/ages of children, childcare arrangements, pregnancy, and/or plans to have children
• Physical or mental disability
• Status as a special disabled veteran or veteran of the Vietnam era
• Height or weight
• Health
• Credit rating, financial data
• Any other legally protected information

Retention

          Afilias will provide its full-time employees with a comprehensive health and benefits package and will implement a performance-based bonus program for its employees to retain high-performing employees and provide incentives for them.

          As discussed previously, Afilias has structured its operations to provide sufficient human capital investments at both the staff and executive levels, regardless of its anticipated growth. As such, Afilias anticipates little need for additional management personnel on an ongoing basis. To the extent necessary, Afilias will leverage its Member Registrars to identify additional management personnel and/or will retain an executive recruitment firm to supplement any unanticipated managerial candidates on an ongoing basis.

          Afilias proposes a registry operator term of eight years in duration, substantially longer than ICANN's contract terms with the current STLD registry operator. Reasons for negotiating a longer term include the following:

          (1)   As the operator for the first newly issued gTLD, Afilias bears significant risk in developing a company to operate the new gTLD registry. Afilias' overall projections have been conservatively stated as a "proof of concept" registry operator given the uncertainty relating the future release of additional TLDs. With these conservative projections, a meaningful return on investment to its constituent owners for this endeavor may only occur over an extended time horizon.

          (2)   As the operator for the new TLD, Afilias will expend significant resources to build and maintain the registry to develop effective customer acquisition and service systems, whose value increases with time, particularly in the face of additional competition. By building these systems and then facing the potential of losing the right to operate the registry, Afilias may be faced with significant sunk costs and a frustrated end-consumer base who are forced to adhere to policies of another registry operator. These customers, in turn, may be less likely to register for a domain name under any future new issued TLDs, impacting the entire market for domain name registration.

          Afilias will establish performance and service level targets from which to evaluate its performance and report to ICANN on an annual basis. At the onset of the final year of its registry operator term, Afilias will evaluate its long-term performance as a registry operator and hopes to negotiate a renewal with ICANN.

          Table 2 and the detailed Profit and Loss statements provided in Appendix C identify the major costs associated with Afilias' operations for five years at the 90%, 50% and 10% confidence levels. What follows is a summary of these costs during the first year of operations at the 50% confidence level.

          Operational Costs

                    Tucows Fees

          [SECOND AND FOURTH SENTENCES ARE CONFIDENTIAL]

          Costs associated with custom-building, managing, and operating the registry will initially be recognized as fees paid to the outsourced technology partner on a per registration basis. More specifically, for every domain name registered, Afilias will pay $2.95 to Tucows. These fees will be paid to Tucows on a monthly basis as new domain names are entered into the registry. Costs associated with the provision of fees to Tucows are expected to total U.S. $2,049,981 at the 50% confidence level of demand during the first year of operations.

                    Technical Operations

          Initial technical operations costs include labor and equipment associated with developing, maintaining, and managing the registry systems. Afilias will initially hire a three-person Systems Development and Support Staff that will be managed by the Chief Technology Officer. [FOLLOWING SENTENCE IS CONFIDENTIAL] Costs associated with Systems Development and Support will total $565,833 at the 50% confidence level of demand in the first year of operations.

                    Billing Customer Service

          These costs include labor associated with providing billing-related customer service to registrar customers. Labor associated with this function include a Customer Service Manager, a Senior Customer Service Representative, three Customer Service Representatives, and an Administrative Assistant in the headquarters location and an additional Customer Service Manager in the United States Satellite office. This staff will be managed by the Vice President of Policy and Registrar Relations. [FOLLOWING SENTENCE IS CONFIDENTIAL] Customer Services costs will total $459,813 at the 50% confidence level of demand in the first year of operations.

                    Marketing and Sales

          Costs associated with Afilias' marketing and sales efforts will include labor costs associated with hiring a Chief Marketing Officer, a Marketing Manager, a Public Relations Manager and a group Administrative Assistant in the headquarters location and an additional Sales Manager in the United States Satellite office. Afilias will launch a worldwide integrated marketing and public relations campaign managed by Afilias' retained advertising and public relations consultancies. [THE REMAINING PORTION OF THIS PARAGRAPH IS CONFIDENTIAL]. Afilias' marketing and public relations costs are anticipated to reach $22,936,771 at the 50% confidence level of demand during the first year of operations. This advertising budget includes $6 million that is allocated for a co-operative advertising campaign with Afilias' Member Registrars, whereby the Member Registrars could contribute $2 for every $1 contributed by Afilias. Therefore, in this co-operative advertising program, Afilias expects Member Registrars to contribute a maximum of $12 million in additional advertising funds.

                    Research and Development

          Afilias will be actively involved in the development of new registry service offerings that facilitate the growth of domain name registrations. Afilias will capitalize on the industry expertise of its Technical Review Committee and the ongoing efforts of its technology development staff to continuously improve the functionality of the registry operator. [THE FOLLOWING TWO SENTENCES ARE CONFIDENTIAL] Costs associated with research and development of these offerings will total $39,955 during the first year of operation. These costs, however, are anticipated to expand substantially in the second year of operations to $660,814, at the 50% confidence level of demand.

                    General and Administrative

          General and Administrative ("G&A") costs comprise all the overhead costs associated with the operations of Afilias. G&A labor costs include salaries and benefits for the CEO, Executive Assistant to the CEO, the CFO and accounting staff, the Office Manager/Human Resources Manager and Assistant, and the General Counsel and Assistant. Other non-labor G&A cost categories include rent, telecommunications, office supplies, staff travel and entertainment, seminars and conferences, corporate insurance, facility maintenance, outside legal counsel, financial and accounting services, executive search services, trademark review, and Web site hosting and connectivity. [THE FOLLOWING SENTENCE IS CONFIDENTIAL] G&A costs will total US$3,555,366 at the 50% confidence level of demand during the first year of operations, assuming a 50% confidence level of demand.

ICANN Cost-Recovery Fees

[THIS PARAGRAPH IS CONFIDENTIAL]

          In addition to registration and renewal fees for each domain name registered or renewed, Afilias will charge its registrars an additional US$0.20 service fee that will be distributed directly to ICANN to serve as cost-recovery for ICANN in overseeing registrar and registry activities. As with the registration and renewal fees, the cost recovery fee will apply for each year of registration or renewal. ICANN cost-recovery fees are anticipated to total $515,000 in the first year of operation and $1.53 million in the second year of operations assuming a 50% confidence level of demand.

          Revenues associated with the various services provided by the Company are illustrated in more detail in the Detailed Profit and Loss Statement provided in Appendix C, which shows revenue at the 10%, 50% and 90% demand levels. Notes provided with these forecasts provide additional information regarding the calculation of these revenues. Please refer to Table 3 for overall revenue estimates at all three confidence levels over a five-year period.

Domain Name Registrations

          [THE FIRST SENTENCE IS CONFIDENTIAL] Afilias expects revenues stemming from domain name registrations to total $3,917,188 on an accrual basis during the first year of operations at the 50% confidence level, which assumes that registration services do not commence until the seventh month of operations. Revenue represents the product of Afilias' annual registration fee, term of registration, and the number of registrations anticipated during a given period.

                    Domain Name Registration Renewals

          Beginning in the third year of operations, Afilias expects to begin collecting domain name registration renewal revenues. Renewals will be priced the same as initial registrations and will be offered in 1 to 10 year terms in annual increments. Renewal revenues are calculated as the product of (1) the number of registered domain names under Afilias' registry; (2) the percentage of existing domain names renewed at a given period, (3) the renewal fee charged by Afilias, and (4) the term of the renewal. [THE FOLLOWING SENTENCE IS CONFIDENTIAL] Revenues associated with renewals are expected to total $1,150,000 during the third year of operations on an accrual basis, at the 50% confidence level.

                    Domain Name Transfers

          When registrants request to transfer a registration to another registrar, Afilias will charge the receiving registrar a one-year registration fee. [THE FOLLOWING SENTENCE IS CONFIDENTIAL] Afilias estimates that 2% of new registrations in any given period will include transfers between registrars, accounting for an additional US$78,344 in revenue during the first year of operations at the 50% confidence level.

          [SECOND AND THIRD SENTENCES ARE CONFIDENTIAL] Afilias has structured its operations to enable Afilias to fund its capital needs through a series of capital calls to its Member Registrars, and if necessary, debt financing. Afilias' Member Registrars have already committed a total of approximately $1.34 million to Afilias, which is being used to finance the initial start-up of Afilias. As stated in the Operating Agreement, upon being awarded the bid by ICANN to operate the TLD registry, Afilias Member Registrars, in the aggregate, will be called upon to commit an additional $3.45 million in funding to Afilias. In addition to this second capital call, Afilias will secure, if necessary, a loan from a commercial lending bank chosen upon approval from ICANN to operate the registry.

          Afilias believes that no additional investment capital necessarily will be required to operate Afilias beyond these initial capital calls and debt financing. However, Afilias has reserved Class B Units for other, non-member registrars and other potential strategic investors to take equity positions in Afilias. Afilias will request additional capital calls among its Member Registrars and possibly, other strategic outside investors, who would obtain ownership in Class B Units, if required.

          Afilias anticipates that it will finance the integration of any technical infrastructure during the second and third years of operations through available cash collected in registry fees during the first two years of operation. Afilias anticipates no liquidity event (e.g., sale or IPO) for Afilias in the foreseeable future.

Opportunities

          By marketing and operating a new gTLD, Afilias has the opportunity to play an integral role in creating a new market space within the Internet that is no longer defined by the .com. By offering the Web extension and by marketing it effectively, individuals and businesses on a worldwide basis will have a new opportunity to create a valuable presence on the Internet. Because of this opportunity, the demand for the extension may exceed those projections described in this business plan. Afilias is building a flexible organizational structure that will scale to meet demand exceeding forecasts provided at the 10% confidence level. Afilias is dedicated to providing the highest level of quality customer service and staffing required to meet registration demand at forecasts at all confidence levels, and will dedicate additional staff as required to meet any demand that exceeds the 10% confidence level.

          Afilias will also build a registry which meets the needs of its registrar customers and addresses the inadequacies of existing registry services. Furthermore, Afilias and Tucows will ensure that its technical infrastructure will scale to meet and exceed demand levels at the 10% confidence level during the first two years of operations.

          If Afilias assumes control of the registry operations in year 3, it will build an open architecture technological solution that provides flexibility to meet peak demand by leasing the required equipment and facilities as needed from established, reputable hosting and equipment vendors, who are positioned to provide the necessary capacity.

Risks

          While the opportunity exists to augment the utility and awareness of the Internet on a global basis, several risks exist that may prevent the full realization of this opportunity, including the following:

          Imprecise Demand Forecasts

          It is not possible to forecast with precision the demand for a new unrestricted TLD since this is the first time such a new TLD is being offered. Afilias has tried to mitigate this risk by conducting a thorough analysis of prevailing market trends and by coupling this analysis with its own online and offline primary market research endeavors.

          Competition/Marketing Efforts

          A key ingredient to the success of Afilias and the new TLD is how effectively the new TLD is marketed. Afilias must build awareness among existing and potential registrants and provide a compelling case for choosing its TLD over the incumbents. To mitigate this risk, Afilias can draw on the expertise of outside consultants to develop and implement Afilias' public relations and marketing strategy. Afilias and its marketing services partners have built flexibility into their marketing strategy to refine its marketing efforts as necessary in the event that initial campaigns have little impact (i.e., lower than expected registrations during the Sunrise and Start-up Periods).

          Technical Failure

          Afilias registry infrastructure and systems must operate at a high level of reliability. Long periods of registry outage, during which time domain names cannot be registered, will have a significant, negative impact on the adoption of the new TLD. To mitigate the impact of this risk, Afilias has negotiated the lease and potential purchase of a proven registry system and will enhance it to provide multiple redundancies to minimize any risk of technical failure. A more detailed discussion of the procedures and policies that will be implemented to reduce the risk of a registry technical failure is provided in the attached Technical Plan and the Policies adopted by Tucows. These policies are described in section D13.2.15.

          Afilias defines registry failure at two levels: (1) operational/financial failure; and (2) technical failure. In either type of failure, Afilias will turn to ICANN for interim and transitional support.

          Operational/Financial Failure

          If Afilias can no longer support its business efforts with the required capital, Afilias will announce to ICANN no fewer than 90 days in advance, the dissolution of Afilias, and make plans to transfer to ICANN all necessary data files, billing records, and systems required to run the registry on an interim basis. As such, ICANN would assume full responsibility of the registry. The Company's financial projections suggest that financial failure is highly unlikely given the strong cash flows provided by its core revenue streams.

          Technical Failure

          Technical failure is defined as failure to provide services relating to the operation of Afilias registry on an ongoing basis. During at least the first two years of operations, Tucows will have the sole responsibility for implementing the appropriate redundancies and policies in the event of technical failure. Tucows has outlined several policies in the event of technical failure, including the following:

• Standard Escalation and Response. A process which outlines precise escalation procedures that are to be followed in the event of emergencies. This process will ensure that affected parties are notified as soon as possible and that work is initiated to solve the problem in a timely manner.
  
  
• Catastrophic System Failure and Response. Outlines exact steps which should be followed in the event of a serious system failure including movement of processing to secondary systems or locations and the circumstances under which this level of response is required.
  
  
• Emergency Response Unit Deployment. A process description which outlines exact steps and methodologies that will be followed to deploy a response unit to the affected system.
  
  
• Full cooperation and coordination with the Company's partners and other affected parties to ensure any problems are resolved quickly and effectively.

          Afilias will implement similar policies if it assumes control of the registry operations in year 3. If Tucows or Afilias can no longer operate the registry, Afilias will make provisions to deliver to ICANN or its designee all of the software source code required to operate the registry, thereby creating a transfer of operations from Afilias to ICANN or its designee.

          Please refer to the three versions of the comprehensive financial model provided as an Excel-based workbook in Appendix D, which detail the costs, revenues, P & L statement, Cashflow Statement, and Balance Sheets for the Company at the 90%, 50% and 10% confidence levels.

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.

Please refer to documents attached as Appendix E.

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.

Executive Summary

          The basis for formulating the new registry operating systems and procedures comes from the firsthand experience the member registrars have with the NSI model. Thus much of this document assumes knowledge of the NSI Registry-Registrar model, and the associated protocols and issues. Afilias' philosophy was to start with what most registrars already know, and to (i) improve upon the systems and procedures, and (ii) address issues that have come up in the past year of operations.

          In assessing how to approach the technical requirements, Afilias' members established a Technical Task Force, which was charged with addressing operational requirements and a methodology to meet those requirements. The Task Force considered three alternative approaches to meeting the technical and operational requirements:

          1. Build the registry systems by utilizing custom software vendors, purchasing equipment and contracting for network connectivity.

          2. Outsource the entire operation to an experienced partner and pay on a per registration or per transaction basis.

          3. Some combination of the first two, by outsourcing parts of the system, while attempting to maintain control and oversight of other parts.

          Afilias' Technical Task Force weighed these three options seriously, and initially were convinced that to outsource the entire operation to a trusted neutral third-party subcontractor would provide a great deal of stability and bring a wealth of technical resources to the operations. Discussions with suitable partners ensued, and the technical discussions largely confirmed the task force's initial analysis.

          Upon further development of Afilias' long-term technical requirements, however, the task force decided to enter a short-term contract with a sub-contractor to provide many of the back end solutions to its immediate requirements, but concluded that the long-term end goal should be to be able to build and maintain its own registry.

          The Afilias Technical Task Force has concluded that working with Tucows, as the subcontractor providing much of the operations, is the best course of action. Afilias and Tucows executed an agreement with a two year term, in order to provide Afilias with the short-term option of building its own infrastructure based on the technological solution that Tucows has developed. By the time the contract with Tucows expires, Afilias expects that there will already be an established protocol that governs standard communications between registry and registrar.

          The following points detail significant improvements Afilias and its technology subcontractor system will bring to the Internet community, in particular over the current NSI RRP.

          1.  Afilias will provide a turn-key system for registrars rather than just a bare-bones toolkit. Advantages of a turn-key system include:

• optimized performance between registrars and registry
• fastest possible time to market
• increases competition as there is no barrier to entry
• additional revenue can be generated from software sales and maintenance upgrade/support
• ensures policies are correctly implemented

          2.   The Afilias RRP will be improved over the NSI RRP. Key technical leaders from Afilias and Tucows will form an IETF working group to develop a standard for all Registries. A standard RRP will allows a registrar the ability to support new registries without the need to develop a module to support yet another RRP, thereby increasing competition. An increase in registrars will also benefit the registries by creating new sales channels.

          3.   Afilias plans to use an event driven model for operations performed via the RRP. Events that are generated will cause near real-time updates of Whois and TLD zone files. This is in contrast to the current model of bulk update of Whois and TLD zone file that occur with delays of up to 12 hours.

          4.   Public information that is available via Whois will also be available via RRP. This is in contrast to the current NSI system where a registrar needs to check both Whois and RRP depending on the information desired.

          5.   Registrar status is added to the RRP. The registry can place a registrar on HOLD if it is non-compliant. A registrar on HOLD status will not be able to add domains. Existing domains can be modified or transferred, however, so that the registrant still has the ability to manage domains registered with a registrar on HOLD status.

          6.   The Afilias Registry will offer near real-time zone file updates, and real-time updates of DNS zone files is a target over the medium term.

          7.  The Afilias Registry will examine the use of DNSSEC and similar technologies to prevent falsified zone information. This will be a future development dependent on the implementation of DNSSEC on BIND.

          8.  All RRP events will be passed to the billing system via an agreed-upon API. The determination of which events will be billed is dependent on the business policies of the registry. In addition to reporting on standard registrar billables such as registrations, renewals and transfers, data will be kept to report on registrar's usage of other functions, such as Whois queries, RRP queries and data element changes.

          9.   Whois output will include domain status, including if it is in transfer status, on administrative hold, or other.

          10.   Whois will support a new lookup key for each registrar (either full name or registrar ID/short name), and will include contact information for the registrar (administrative, customer support, billing, transfer support)

          11.   Future versions of the Afilias Whois system will support new lookup key for Registrar List. This will generate a list of all accredited registrars.

          12.   Afilias Whois will support XML for machine parsibility in future generations.

          13.   Updates of Whois data will occur on a 5 minute cycle, in the future, the goal is full Real-time updates of Whois data.

          14.   The system will provide bulk data access to an up-to-date list of all registered domain names. This is in contrast to NSI Registry's TLD Zone File access, which may have domains excluded if the domain is in REGISTRY-HOLD or REGISTRAR-HOLD status.

          15.  Access to RRP will require that the combination of Username/Password, SSL Certificates and IP Address Filters be satisfied for a particular registrar. This is in contrast to the current system where each check is independent.

          16.   Each registrar will be able to provide the registry with a list of individuals who may contact the registry. Each of these individuals will have his or her own pass phrase. This is in contrast to the current system where there is a single pass phrase for each registrar.

          17.   PGP will be used between the registrar contact and the registry. If PGP is not used, the registry will contact the individual by phone to verify the pass phrase. In the current NSI system, there is no requirement to use PGP.

          18.   SLA downtime levels are lower than NSI Registry's current values. Target is availability at a 99.9% level.

          19.   Target is to have geographic diversity to meet requirements of regional diversification and scalability.

D15.1.   Detailed description of the registry operator's technical capabilities.

          Afilias brings together the capabilities of 19 ICANN accredited registrars that have 40 years of accumulated experience. Each of those registrars have developed or worked with the current NSI Registry RRP system, and many of the members have experienced the process of building registrar services in a rapid ramp-up period. These capabilities and experiences form the basis for the policies and system requirements that will build the direct operations of the registry.

          Currently Afilias does not employ technical staff; however, the operations plan calls for the establishment of a technical team consisting of the Chief Technology Officer and three senior engineers immediately following announcement of intentions to begin negotiations with ICANN. Further, Afilias has already begun initial searches for the Chief Technology Officer position.

          During the application process, Afilias has relied upon a Technical Task Force, consisting of technically experienced leaders from the member registrars. This Technical Task Force will become the core of the Technical Review Committee, which will focus efforts on working with the selected sub-contractors and Afilias technical staff during the post award period. The members of the Technical Review Committee, with their resumes, are presented below:

Richard A. S. Lindsay
interQ Inc.
13 years experience

          Richard is a member of interQ's Board of Directors and is responsible for all of interQ's day-to-day operations. For the past 5 years, Richard has been managing the development and deployment of a variety of Internet-based services, ranging from ISP networks, to virtual hosting, to domain name registration services. Richard represents interQ at many Internet organizations including ICANN, and the DNSO, and was an initial member of the Names Council representing the Registrar Constituency. Richard also spent 6 years as a Naval Intelligence Officer.

          Richard has a Bachelor of Arts degree from Tufts University in Medford, MA, and an MBA from the International University of Japan.

Eric R. Schaetzlein
Schlund+Partner AG
7 years experience

          Eric is a co-founder of Schlund+Partner, and now serves as Senior Manager Domain Services. He was responsible for automating the DeNIC ccTLD registration process, and developed a system that, in its current version, has registered more than 3 million .de domain names. Eric designed and implemented Schlund+Partner's domain registration and DNS system, which has currently registered over 1 million domain names.

          Eric holds a bachelor's degree in Computer Science from the University of Karlsruhe, Germany.

Peter Eisenhauer
Schlund+Partner AG
6 years experience

          Peter is a Senior Software Engineer and has been designing and developing software in the field of domain registrations. With several years of experiences in software design and development and high skills in object-oriented design and analysis as well as a deep understanding of internet protocol and standards, he has been instrumental in building the Schlund registrar system for com/net/org Domains. He also has experience in UNIX system administration (Sun Ultra Enterprise 450).

          Peter has a master's degree in Computer Science from the University of Karlsruhe, Germany.

Peter Chow
interQ Inc.
8 years experience

          Peter is a senior systems engineer with a broad background of experience in developing, deploying and administering a wide variety of Internet-based services. His background is as a Network Engineer, with 3 years Telco experience and 5 years experience building Internet Service Provider networks. Since that time Peter has served as developer, as systems administrator, and as the overall technical lead for interQ's System Division. Peter was also involved on all phases of the development and implementation of interQ's gTLD Registrar system.

          Peter holds a Bachelor of Science in Electrical Engineering from Simon Fraser University in Vancouver, British Columbia, Canada.

John Wong
Domain Registration Services
18 years experience

          John is a founder and President of Domain Registration Services and has over 18 years experience in areas of product development, project management, technical development, marketing, proposal development, and administration. He has extensive experience in all aspects of Internet, client/server, networking, and related technologies. John's technical proficiencies include: Java, client-server, SQL, Unix, DNS/BIND, TCP/IP networking, Cisco IOS, Registry Registrar Protocol (RRP), and others. Product development experience in various client-server applications using Oracle 7 & 8, hands-on experience with Oracle Internet Commerce Server, Web Application Server, Jdeveloper Suite, cross platform systems integration (Unix, NetWare, NT), internetworking, data communications, ISO-9001 and configuration management (CM), design and implementation of robust registry database system, and connection pool to NSI Registry servers using RRP and clustered Unix technology.

          John holds both master of science and bachelor of science degrees from the University of Pennsylvania.

Chris Kruk
DomainPeople
15 years experience

          This Committee will coordinate with Afilias technical employees, and will ensure that the requirements described in this section of the proposal, which have been given to sub-contractors as a basic Request for Proposal (RFP), will be stringently met.

          Tucows will provide extensive technical capabilities for both system operation and system development, as described below.

Operational Capabilities

1.    Personnel

          The Tucows Operations team consists of Unix and NT System Administrators, WAN/LAN Network Administrators, Network Operator/Help Desk Personnel, Oracle DBA, and Application Layer Operators. Key staff are as follows:

David Sutton
Director, Operations

          David has 16 years of experience in technology management, implementation and support. David is a graduate of Electronics Engineering Technology from Sheridan College. After working for four years in a technology support role for Sheridan College, David managed the Operations team for Cancom where he built Canada first VSAT satellite 2-way data network. After 9 year with Cancom, David moved to Alias|Wavefront (an SGI company) for three years to lead Alias worldwide IT department. In March 2000, David joined Tucows to oversee the Operations team.

David Antognini
Senior Systems Administrator/Network Architect
10 years experience

Rob Naccarato
Senior Systems Administrator/Systems Architect
8 years experience

Denis Achibane
Oracle DBA/Senior Systems Administrator
15 years experience

Fred Dorre
Production Application Operator
2 years experience

Yuri Pismerov
Systems Administrator (Unix)
8 years experience

Adrian Daminato
Systems Administrator (Unix/NT)
5 years experience

Kevin Rueckert
Systems Administrator (Unix/NT)
5 years experience

Evan Robinson
Network Operator/Help Desk
1 year experience

2.  Tools

          The Operations Team utilizes such tools as HP Openview (Network Node Manager), and Firehunter to proactively manage the production Tucows environment.

          The members of the team are on call 24/7/365, with a five-person rotation providing after-hours support and monitoring.

Development Capabilities

1.    Personnel

          Tucows development consists of a highly skilled mix of Perl, Java and enterprise developers. The Perl developers focus on content and portions of the client side embedded/distributed components. The enterprise and Java developers focus on those components that execute inside of the transactional framework. Key staff are as follows:

Eugene Vasile
Director, Development

          Eugene has 11 years of experience in the IT industry. He has directed and managed an IT services company providing turn-key solutions for the retail industry. He has been involved with Real-time client/server application development for the brokerage industry using Unix, TCP/IP, C++, multi-threaded programming, and various full-text hierarchical and relational databases. In addition he has managed Multi-tier Web-based application development and integration of enterprise risk management solutions using Java, CORBA, C++ and Unix.

Greg Wier
Senior Perl developer and content architect
8 years experience

Bruce Miner
Chief Architect
20 years experience

Steve Knipe
Architect
11 years experience

Charles He
Senior Developer
10 years experience

Frank Thompson
Senior Developer
6 years experience

Janusz Sienkiewicz
Senior Developer
5 years experience

2.   Tools

          Key software development tools available include JDK1.2.2 and Together (Control Centre Edition).

Technical Achievements

          As noted earlier in this document, Tucows has developed the OpenSRS service, which allows its worldwide channel to easily and profitably register, manage, and modify domain names.

          This service uses a distributed architecture which achieves the goals of scalability, reliability, and extensibility.

          The large knowledge base accumulated during the development and deployment of this project will prove invaluable in supporting and maintaining the registry solution proposed.

Significant Past Accomplishments

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:

          The following subsections will describe in detail the technical plan for registry operations. These operations are based on the policies as described in sections E2 through E15 of the Description of TLD Policies. In general the operations are based upon the collective experience of registrar operations in the .com, .net, and .org TLD space. The attempt was to establish technically feasible solutions (thus assuring operational stability), while at the same time providing improvements to the current system (thus offering an innovative alternative to the existing Registry-Registrar model).

          Afilias and its partner subcontractor Tucows will improve the reliability of the domain name registration process as a whole, based on the consortium members' own experience with the current system. The effects will be to increase public confidence, introduce competition, raise standards for all registries, and expand consumer choice. Ultimately, this will be an effective proof of concept for the introduction of top-level domains in the future.

          Afilias will provide a seamless, responsive, and reliable domain name registration service. Currently, registrars' services are hampered by monthly registry outages of up to multiple hours per month. Afilias will implement much stricter Service Level Agreements ("SLAs") in order to minimize acceptable scheduled and unscheduled down time due to maintenance and to offer higher levels of responsiveness. More importantly, SLA down time excesses are unlikely as Afilias and its subcontractor Tucows, will provide for redundancy of mechanisms to prevent outages. Second, Afilias will provide near real time updates to critical services, such as Whois and zone file generation for registrar transactions such as registration or deletion of domain names.

          Afilias will also provide more transparency for both registrars and the public at large, while at the same time protecting privacy interests. For example, the centralized registry Whois database will inform the user about the status of the domain name. At the same time, the registry Whois will provide a technical solution to allow a registrant to opt out of having certain personal information displayed on Whois. This option will allow Afilias to comply with the various privacy laws and standards around the world.

          Afilias will be operated and architected as a truly global registry. A consortium of registrars from around the world will own and operate it. It will be governed by policies drafted to accommodate worldwide laws and standards. It will provide a geographically distributed network that can respond equitably to a registrar, no matter where it is located.

          Initially, Afilias will rely almost entirely upon its sub-contractor Tucows for technical infrastructure during the initial 2 years of operations. Thus section D.15.3 of the Technical Capabilities section will describe the Tucows plan in detail. All critical areas of the registry operations will be outsourced, with the exception of the billing function, which will be carried out by registry staff.

          Following the completion of the first 2 years of the contract term, Afilias reserves the right to purchase an unlimited license to the software, and all applicable components. According to current plans, Afilias plans to exercise the option to purchase the software, and build out operations internally. The scale of operations will replicate the Tucows system, with the goal of extending services and operations. The business plan includes an estimate of costs associated with the build out.

          The long-term plan from year 3 to year 5 is to build out international operations, to provide for geographic distribution the functionality of the registry. The scope and scale of the build out will depend upon the regional demand for services, and degree of penetration into the global market. In the long term, Afilias plans to be a technology leader on the domain name registration front.

          The capabilities of both Afilias and its technology partner, Tucows, are described in more detail in further sections of the proposal, but are highlighted in this section.

          As previously described, Afilias brings together the capabilities of 19 ICANN accredited registrars that have 40 years of accumulated experience. Each of those registrars have experience with the current NSI Registry. These capabilities and experiences form the basis for the policies and system requirements that will build the direct operations of the registry.

          While Afilias does not employ technical staff at this time, the operations plan calls for the establishment of a technical team consisting of the Chief Technology Officer and three senior engineers immediately following announcement of intentions to begin negotiations with ICANN. Further, Afilias has already begun initial searches for the Chief Technology Officer position.

          During the application process, Afilias has relied upon a Technical Task Force, consisting of technically experienced leaders from the member registrars. The members of the Technical Task force are listed and their backgrounds described in Section D15.1. This Technical Task Force will remain operational, and will focus efforts on working with the selected sub-contractors during the post award period. This team will coordinate with Afilias technical employees, and will ensure that the requirements described in this section of the proposal, which have been given to Tucows as a basic Request for Proposal (RFP), will be stringently met.

          Tucows currently co-locates all of its servers with Exodus Communications. Exodus was recently declared by the US White House as a "National Infrastructure Asset."

          Afilias plans to locate systems in the following Exodus Locations around the world:

The specific systems are described in Section D15.2.8.

          All Exodus locations are high security buildings. Security guards are on duty 24/7, and enforce a sign in process where anyone entering facility must be on the approved list. Visitors must show legal photo ID to be granted access to each facility. Once inside the facility, people must use a card key and palm scanner to gain access to the data center. The Tucows cages are locked within the data center, and must be unlocked by security. The entire facility is monitored by video surveillance. Multiple air conditioning units are configured in a fully redundant array. Multiple UPS power units with battery backup provide clean and reliable electrical power. Multiple diesel generators are available for extended power outages, in a fully redundant array. Kevlar lined walls for protection against explosion from the outside.

          Each server is connected via Gigabit Ethernet to the Exodus core, where it has multiple OC-48 connections to the backbone/Internet.

          Tucows has a strong existing relationship with Exodus, housing over 100 carrier class servers at Exodus facilities. These servers are remotely managed by Tucows Operations from the Tucows office at 96 Mowat Ave., Toronto, Ontario, Canada.

          Tucows primary technology vendors are Dell for Intel based servers, and Sun for SPARC based servers. All servers are carrier class servers with multiple processors, minimum of 2G memory, redundant hot swappable power supplies (fed from separate UPS breakers), hardware RAID arrays with hot swappable disk drives. Servers are rack optimized, and have field swappable modular components for ease of service.

          Availability of hardware components exceeds 99.8%, and mean time between failures is in the thousands of hours. Due to the nature of the architecture, the systems can continue to function even if an entire server were to suffer catastrophic failure.

          Regarding capacity, Tucows has ensured that all applications and their infrastructures are highly scalable, allowing for easy increases in processing/transaction capacity.

          Tucows utilizes load balancers to assist in scalability as well as to prevent service outages. Due to the nature of load balancing, in many cases it is possible to also perform upgrades on servers without the customer being impacted. Currently, Tucows has relationships with Radware, Resonate, and F5 for load balancing solutions that are external to the application layer load balancing.

          Systems are protected with Cisco PIX firewalls, and Cisco routers are used throughout the system.

          Tucows maintains on-site inventories of spare components which may fail, specifically: disk drives, CPU , power supplies, network cables, memory modules (DIMMs).

          Tucows takes a best of breed approach regarding operating systems environments. Specifically, a combination of Solaris, NT, and Linux, with emphasis on Solaris for high availability applications such as the back end database servers.

          Intellectual property security is addressed in many ways. From an access perspective, Tucows has firewall and packet filtering enabled on all routers.

          These systems have intrusion detection that will alert Tucows Operations staff should there be an attempted intrusion. All servers have strictly managed root/super user access with passwords that are chosen to be difficult to break (e.g. no proper words are used). These passwords are changed regularly, a minimum of once a month, or sooner if required.

          Interoperability of the systems is based on a common naming service. All components of the system must register themselves with the common naming service. This service has full and total knowledge of all subsystems, allowing and facilitating the interoperability of all parts of the system.

          The registry model consists of several layers and associated services. The layers are: protocol layer, session layer, and database layer. These are described below, in conjunction with Diagram 1 (Registry Operations Logical Model). The logical model illustrates what the registry will look like at each individual registry facility (these are explained in more detail later in this document). Included in the discussion is a description of the hardware that will be used to implement the solution.

          The protocol layer is the interface to external registry requests. It is designed to accommodate any number of Registry-Registrar protocols and translate them to a common action request format, which the registry can then perform.

          Currently the protocol layer supports RRP (NSI), RRPx (extended RRP for centralized Whois), and asynchronous protocols (for example, the .UK asynchronous email model). Additional protocol handlers can be added as needed, and easily integrated into the system.

          Multiple instances of each protocol handler are supported. For example, RRP1 and RRP2 in the diagram both support the RRP (NSI) protocol. Two instances are illustrated, however; in reality, any number of handlers can be activated. A load balancer supports the delegation of registry requests between multiple handlers. This provides high performance, and high availability.

          Each protocol handlers will run on a Sun E250 with dual CPU, 2G of RAM, 2x36 GB mirrored hard drives, running the Solaris operating system.

          The session layer handles sessions (communication) between the protocol layer and the database layer, thereby facilitating a registry request. It accomplishes this via session managers (Session Mgr1, and Session Mgr2 in the diagram).

          Multiple instances of the session manager are supported. In the diagram, two session managers are illustrated, however; in reality, any number of managers can be activated. A load balancer selects the appropriate manager to handle the session. This provides high performance, and high availability.

          Each session manager will run on a Sun E450 with quad CPU, 2G of RAM, 2x36 GB mirrored hard drives, running the Solaris operating system.

          The database layer handles the rules and manages the data that is necessary to support the registry model. The database layer is composed of services that handle the various registry objects, such as domains, nameservers, and registrants.

          Multiple instances of each services are supported. For example, Domain1 and Domain2 in the diagram both support domain registry objects. Although, two service instances are illustrated in the diagram, in reality, any number of services can be activated. A load balancer supports the delegation of requests between multiple service handlers. This provides high performance, and high availability.

          The database layer also contains the database store itself. This consists of two database systems with data replicated between them on a continuous basis. If one database fails, the other is able to take over registry operations immediately. By supporting multiple database stores, the registry system offers high performance and high availability.

          All load balancing will be performed by Radware Multi-LAN.

          Each registry object service will run on a Sun E450 with quad CPU, 2G of RAM, 2x36 GB mirrored hard drives, running the Solaris operating system.

          The databases will each run on a Sun E10000 with 16 CPU, 8G of RAM, 8x72 GB RAID hard drives, running the Solaris operating system and a Oracle database.

          The operational registry model supports services such as DNS servers and Whois servers. Each of these services is load balanced for high performance and high availability. These are explained separately later in this document.

          Equipment within the registry model is connected with dual homed 100Mbit connections. A separate network is used for backups.

          The fundamental building block of the Tucows registry model is the OpenXRS registry. This system implements all functional requirements necessary to implement a TLD registry. It does so in a scalable and fault-tolerant way by providing a replicated database that can be put into service automatically if the primary database fails.

          The architecture of the OpenXRS system is best illustrated by Diagram 2 (Open XRS Architecture):

Diagram 2

          Each component in the OpenXRS system (Domains, Registrars, Nameservers), runs on a Sun E450, each with 2 CPU, Solaris operating system, and 2 GB of RAM, and 2 x 36GB mirror drives.

          The OpenXRS registry uses two Oracle databases, a primary and a secondary, which are continuously replicated. Each Oracle database runs on a Sun E10000, with 16 CPU, Solaris operating system, 8 GB of RAM, and 8 x 72 GB RAID drives.

          Connections between hardware in the OpenXRS registry is made with dual homed 100Mbit connections. A separate network is used for backups.

          In order to provide a more robust and scalable model, the registry is operated in a number of locations. Registries are aired up so that they mirror each other data. This allows for fail-over and fault tolerance in the case of one of the pairs becoming inaccessible.

          In Diagram 3 (Open XRS Mirroring) which illustrates this principle, location A and location B acts as mirrors of each other. If either location becomes unavailable, the system automatically switches over to the other member of the pair.

Diagram 3

                    Registry facilities will be operated in two geographic locations, allowing for redundancy and fault tolerance. The primary registry facility will be operated in Toronto, Ontario, Canada. The secondary registry facility will be operated in Seattle, Washington, USA.

          The primary registry facility will be a live facility, meaning that it will be the normal full-time registry. The secondary registry facility will be a standby facility, meaning that it will only be activated because of operational concerns about the primary facility.

          The secondary facility will remain continuously synchronized with the primary facility using the mirroring mechanism described earlier.

          Exodus will host the physical servers and systems for both the primary and secondary locations. They will be connected to the Internet using OC48 connections. The primary and secondary facilities will be connected using a OC48 connection.

          The preceding section on Registry Operations explains the logical model and architecture that will be in place at each location.

          Diagram 4 (Registry Facility Interconnection) illustrates the registry facilities and how they are interconnected.

Diagram 4

                    Tucows will operate DNS facilities to resolve names entered in the registries. The DNS facilities will be located in a number of geographic locations. Each DNS facility will consist of a load balancer (Radware) and several DNS servers to handle the requests. This architecture is illustrated in Diagram 5 (DNS Architecture):

Diagram 5

                   The DNS architecture uses a Radware load balancer to direct DNS requests to one of several DNS servers. The load balancer provides improved performance and fault tolerance. Each individual DNS server runs on a Sun E450, each with 4 CPU , Solaris operating system, 2 GB of RAM, and 2 x 36 GB mirrored drives. DNS facilities will be operated in many geographic locations. This provides improved local response time to users in those areas. Exodus will host the physical servers and systems. They will be connected to the Internet using OC48 connections.

          The following geographic areas will be used:

          Toronto, Ontario, Canada;
          Seattle, Washington, USA;
          Silicon Valley, California, USA;
          Chicago, Illinois, USA;
          Boston, Massachusetts, USA;
          Hamburg, Germany
          London, United Kingdom
          Tokyo, Japan

Diagram 6 illustrates these locations.

Diagram 6

                    The centralized Whois facility will be operated in Toronto, Ontario, Canada. Exodus will host the physical servers and systems. They will be connected to the Internet using OC48 connections. Diagram 7 illustrates this architecture:

Diagram 7

                    The centralized Whois service architecture uses a Radware load balancer to direct Whois requests to one of two Whois servers. The load balancer provides improved performance and fault tolerance. Each individual Whois server runs on a Sun E10000, with 16 CPU, Solaris operating system, 8 GB of RAM, and 8 x 72 GB RAID drives.

          The centralized Whois service uses two Oracle database, a primary and a secondary, which are continuously replicated. Each Oracle database runs on a Sun E10000, with 16 CPUs, Solaris operating system, 8 GB of RAM, and 8 x 72GB RAID drives.

          Connections between the Whois server and the database are made with Fiber channel.

          The Afilias model will be a "thick" registry model, where all the registrant data is maintained on a central registry database. Registrars are effectively authoritative for the data elements, as agents of the domain name registrant. The registrars are responsible to maintain accuracy of the data of SLD holders who have registered domains through their system. The data itself is held at the registry, but is accessible only from the registrar who is authoritative for that data.

          Diagram 8 shows the overall flow of data from registrant to registrar to registry. In this hierarchical model, while registrars maintain registrant information in the Registry DB, they are in fact the only party authorized to make changes to the data.

                    Registrar access to the registry database will be via a New Generation Registry-Registrar Protocol. The goal would be to have a universally applicable protocol that would allow registrars to operate with multiple registries. To achieve this goal, Afilias member registrar technical staff in concert with the core team of Afilias engineers and the Tucows team will aggressively participate in the Internet Engineering Task Force (IETF) in order to promote the development of a standard protocol. This effort would likely involve current registry operators, and technical leaders from other operational registries as well. Overall, Afilias believes the current draft gRRP submitted to the IETF is a first step in the process of standardization of the protocol.

          Primary registry functions, such as generation of the zone files and Whois data will also be database oriented (meaning triggered from a central data source) and based off the registry database.

Data Management

          Diagram 9 shows the relationship between the registry and registrars, and how access to the various functional relationships occurs. All access to the database is via the RFP. All related database elements are driven from the central registry DB.

Diagram 9

           In determining the operational relationship between the registry and registrars, and protocol model, the Technical Task Force examined whether or not significant changes should be recommended. The advantages for using a protocol that matched closely the NSI RRP, was that most registrars would be able to use the system with little or no development required. However, that would leave unresolved the problems that currently exist in the Registry-Registrar model.

          The Afilias Technical Task Force determined, with input from the Policy Task Force, that a significant review of the current NSI model was called for. The development of a different policy presents some challenges, in particular the issue of creating multiple standards. However, the current published RFP on the NSI RRP is purely informational, and does not include specific open sourced code (for all portions of the system). Further, from the IETF published RFP it would appear that there is a strong movement on the NSI team to considerably increase the functionality of the RRP, in particular based on the Hollenbeck gRRP draft. The recommendation therefore was to coordinate with this effort and submit any protocols developed by Afilias and Tucows to open standards bodies, in particular the RRP working group of the IETF.

          In addition, a review of the overall architecture was called for, in order to develop an event driven system, that would provide for significant functional improvements leading to real time DNS and Whois updates. This would offer a significant improvement over NSI's current model which is not event driven, and appears to update a database which then gets dumped out in batch for DNS and Whois. A generic protocol would use the gRRP proposal as a very general description of entities and operations on those entities, as well as definition of terms.

          Further, standardization across RRP, Whois and other database functions would be accomplished, thus eliminating confusion. Currently, domains on hold status would not show up in the zone files or Whois, but only via RRP command. Additional datafields, such as time stamps and domain status would further eliminate confusion regarding a domain status. Also, enhanced RRP commands, such as the ability to query the status of a domain, and the ability to obtain details regarding a registrar provide additional functionality.

          Afilias proposes that the registry should have the ability to put registrars on "hold" status. This would be an interim step between full accreditation and de-accreditation, and would allow such registrars to continue to service their current customers, but not allow them to register new customers until their hold status is released.

          The benefit of this process would be to provide ICANN with a new mechanism for disciplining violations by registrars. The current system is too black and white, forcing ICANN to go to full de-accreditation or take no repercussions. This prevents ICANN from having meaningful disciplinary procedures in most cases. Such a mechanism would also increase public trust in the DNS.

          The decision to put a registrar on hold, however, should not be left solely to the registry, because there would be significant legal and business risks associated with such decisions. Instead, the task force recommends allocating such responsibility to a trusted 3rd party, analogous to the UDRP (perhaps even some of the same arbitration companies could perform both functions). Until such a mechanism is established there would be no "hold" policy per se, but the technical capability should be built from the outset.

          The Tucows model supports two registry-registrar models and protocols, the NSI RRP protocol, and an XML based Registry-Registrar Protocol. Both of these protocols are supported simultaneously, so that either method can be used to access the registry.

          The proposed solution, fully supports the NSI Registry-Registrar Protocol (RRP) specification as defined in RFC 2832. This specification can be used to handle new gTLDs. The only addition to the protocol that needs to be addressed, is functionality for the extended (centralized) Whois service. This functionality will be added with full input from registrars as appropriate. This "enhanced" RRP protocol is referred to in the "Registry Operation - Logical Model" as "RRPx" (described earlier in this document).

          Since the system supports the RRP protocol in full, it can be used immediately by any registrar who is currently using RRP to access the NSI registry. The use of the RRP protocol will allow registrars to maximize their existing investment in this protocol and ensure a quick adoption path for the new gTLDs.

          In addition to full support of the RRP protocol specification, the proposed solution also supports an XML protocol. This protocol is based on the RRP specification, and extends it in the following ways:

          a) To provide the additional information required by the extended Whois service.

          b) The protocol has been modified to utilize an XML based information model allowing for the future extensibility of both the protocol and model.

          c) The protocol has been extended to allow the aggregation of transactions into large units of work. This allows more work to be done with a single transaction than is currently possible with existing protocols. This leads to greater efficiency and higher performance of the system.

          The model supports the following registry transactions:

add           The add function (OXRSadd) is used to add resources such as domains, nameservers and registrants to the registry.

verify       The verify function (OXRSverify) is used to verify the existence of a particular domain.

delete       The delete function (OXRSdelete) is used to delete a particular domain, nameserver or registrant.

version     The version function (OXRSversion) is used to determine the version of a particular registry executing.

update      The update function (OXRSupdate) is used to update information about a particular domain, nameserver or registrant.

renew       The renew function (OXRSrenew) is used to delete a particular domain, nameserver or registrant.

          See Appendix F for specific details and examples on the XML Registry-Registrar Protocol.

          As illustrated in Diagram 10, the database systems are based on a high availability model with a robust and distributed transaction architecture. The distributed architecture allows for a very large throughput and data capacity.

                    The database uses industry standard methods to facilitate and normalize the development, deployment and assembling of high performance application components. These methods are leveraged to provide a robust and scalable architecture.

          The result is a system that is transactional, database-oriented, multi-user, secured, and portable. It is platform and operating system independent. In addition, since the database components are distributed, this allows for redundancy and fail-over capabilities.

          The database will handle 230 transactions per second, with sustained levels of 250 transactions per second, and peak levels of 286 transactions per second. Since the database will be highly scalable, additional capacity and support for higher throughput can be added as required.

          The database will support all registry actions that are defined in the registry-registrar model and protocol. This includes creation, editing, deletion, change notifications, and registrar transfer procedures. In addition any grace period requirements will be built into the database manager business logic.

          Since the system and database architecture uses components to encapsulate business rules, it can be quickly and efficiently leveraged to provide any level of detailed reporting that is required.

          The OpenXRS registry uses two Oracle databases, a primary and a secondary, which are continuously replicated. Each Oracle database runs on a Sun E10000, with 16 CPU , Solaris operating system, 8 GB of RAM, and 8 x 72 GB RAID drives.

          All changes by registrars will be made through the RRP into the registry database. If there is more than one TLD supported by the registry, there will be a separate zone file created for each TLD, using the registry database as authoritative source.

          Real-time zone file updates using advanced DNS technologies (e.g. Dynamic Updates, RFC 2136) and an incremental registry database system is recommended as a future improvement.

          The generation schedules will be publicly documented.

          The generation of zone files is automatically handled by the system, and is based on a timed mechanism that refreshes the zone with modifications every five minutes. These modifications reflect any updates, additions or deletions made by the registrars, that have committed to the database. As such, any incomplete unit of work is not reflected in the zone refresh.

          Zone files are distributed to DNS nameservers using industry accepted methods, and are done so in a secure manner, using data encryption and secure channels.

          Zone file backups are performed as part of the backup of the system in general.

          Zone files will exist on highly secured servers physically hosted at Exodus locations.

Distribution

          The zone files will be loaded into nameservers using a secure connection. The nameservers must be running software that is fully compliant to the RFCs 1034/1035 and successors. DNS server software shall be at least as capable as the latest stable version of BIND [http://www.isc.org/products/BIND].

          The goal should be to have updates to the zone file (or allowing the SLD to be available on the Internet) as close to real time as possible. Further the system should be as redundant as possible as necessary. While this may not be the only way to achieve this, Afilias recommends that the registry should provide one (redundant) master and at least a number of 5 colocated slave nameservers. The colocations should be located in geographically different regions, and directly connected to backbones, preferably at the local internet exchanges (e.g. DE-CIX in Frankfurt, DE).

          All nameservers should be under direct control of the registry. They must be designed for extreme robustness, availability and performance.

          The usage of secure DNS technologies (DNSSEC, RFC 2541) should be considered for future improvements.

Publication

          New versions of the zone files will only be published after successfully applying consistency and integrity checks on them. In order to prevent failures of major impact (corrupted zone files on the master nameserver), consistency checks should be done:

• after generation and before installing the new zones on the master
  
  
• the transfer of the zone files to the master nameserver will be verified by checksums.
  
  
• installing the new zone should be refused if it is significantly smaller than the last installed zone. Manual intervention should then be required. (This problem may arise if the zone file generation breaks, e.g. after the letter "e," or because of disk space or database errors.)
  
  
• regularly that all slave nameservers have the same serial number as the master

          Tucows DNS facilities will be operated in diverse geographic locations. This provides improved local response time to users in those areas. Exodus will host the physical servers and systems. They will be connected to the Internet using OC48 connections. Tucows will operate DNS facilities to resolve names entered in the registries. The DNS facilities will be located in a number of geographic locations. Each DNS facility will consist of a load balancer (Radware) and several DNS servers to handle the requests.

          The following geographic areas will be used: Toronto, Ontario, Canada; Seattle, Washington, USA; Silicon Valley, California, USA; Chicago, Illinois, USA; Boston, Massachusetts, USA; Hamburg, Germany; London, United Kingdom; Tokyo, Japan.

          The generation of zone files is automatically handled by the system, and is based on a timed mechanism that refreshes the zone with modifications every five minutes. These modifications reflect any updates, additions or deletions made by the registrars, that have committed to the database. As such, any incomplete unit of work is not reflected in the zone refresh.

          Zone files are distributed to DNS nameservers using industry accepted methods, and are done so in a secure manner, using data encryption and secure channels.

          The DNS architecture uses a Radware load balancer to direct DNS requests to one of several DNS servers. The load balancer provides improved performance and fault tolerance. Each individual DNS server runs on a Sun E450, each with 4 CPU , Solaris operating system, 2 GB of RAM, and 2 x 36 GB mirrored drives. DNS facilities will be operated in many geographic locations. This provides improved local response time to users in those areas. Exodus will host the physical servers and systems. They will be connected to the Internet using OC48 connections.

          The billing function will be one of the few operational areas carried out by Afilias staff. The purpose of this section is to give an overview of business requirements for the future new TLD Registry Billing System that Afilias will be sponsoring. The intention is to use this in the selection of the third-party Billing System, or as a basis for the detailed specification if the Billing System is developed from the ground up.

Support from Tucows

          The billing and collection systems execute in the same technical environment as other systems mentioned earlier. They utilize highly scalable application servers, transactional management, and high performance Oracle databases.

          The billing API executes as a part of the same subsystem which controls base registry transactions. This ensures transactional integrity between the billing server and the registry server. The collection system acts as a post process of the billing server.

          The systems run on, and are housed in highly secure Exodus locations. Data security is ensured by using strong data encryption where necessary.

          Access to the physical systems and data is strictly controlled and managed by Tucows.

Critical Requirements

          General requirements that are critical for the Billing System include the following:

• The Registry's TLD services will only be offered to customers who are operational ICANN accredited registrars.
  
  
• The RRP will track all activities and commands executed, and will pass logging to the billing and management system. The billing system will have to determine which of these sessions are billable or not.
  
  
• All domains registration service charge payments will be drawn from the respective customer's established debit account on a per transaction basis.
  
  
• Registry "fee incurring" services will be processed only if a positive balance is maintained in a registrar's debit account.
  
  
• The system must fully support only one currency. It is recommended that the currency be USD however another currency system could certainly be considered.
  
  
• Good query capabilities of the registry operators database will be accessible through an API.
  
  
• Mass changes of certain information will be supported.
  
  
• The application must have capabilities to track and report historical information. The following information should be tracked: transactions (invoice, collections, adjustments), catalog changes, and customer changes.
  
  
• Changes to posted transactions (e.g., invoices or collections) are not allowed. A new transaction must be created to adjust or reverse the original transaction. The cumulative result of both transactions will give the desired result. References among transactions must be tracked.
  
  
• Access to certain functions by external systems and users should be available through an API, in addition to a GUI client for the Billing System. The purpose of the API is to expose certain billing functionality to external systems. External systems may perform specific functionality, e.g., domain registration, accounting system entries, and email processes. The API will also provide extension and customization of billing functionality.

Non-Critical General Requirements

          The following are general requirements that are not mandatory for the Billing System, but have been documented for the Consortium's consideration.

• Support for flexible Company Structure. Particularly, there will be one top-level company - Registrar Consortium, which has unique Information and, distinct functionality. In this document, (RC) and (ER) annotations indicate whether the particular functionality should be supported only for the Registrar Consortium or any external registry respectively.
  
  
• User access defined at the database Record-level: Access to certain records of data should be restricted based on User or User group. Example: support personnel have access only to view customer information and billing clerks have ability to modify customer information.
  
  
• Ability to have all functionality accessible through an API.
  
  
• Ability to have some of the functionality accessible through the Web (browser) Interface.

Organization Structure

          The billing system should have the ability to support multiple Top Level Domain names at varying prices should the new RC registry decide to offer additional TLDs as part of the initial registry bid or in the future.

          If the Consortium decides to resell the services of the registry to other externally sponsored TLDs, then the Customer, Contact, Account, Service Catalog, and all other information will be totally separated between these multiple entities. It means that if one registrar is customer of both the RC TLD(s) and other ER TLD(s) operated by the Consortium, there will be multiple customer records for each of the TLD Registries in question.

User Roles

          The following user roles will typically exist in the Registry Billing Operations Organization: Executive Management, Billing, Manager, Clerks, Customer Service, Billing System Administrator (responsible for configuring the system, e.g. user groups and their access rights, batch process schedule, configurable business rules) and Billing System Operator (responsible for operating the system, e.g., setting up users, monitoring batch processes, system support, error monitoring and handling).

          User roles and their access rights should be custom-defined. System Administrator should be able to create roles and assign them access to certain functionality.

          For examples, Customer Service should be able to view Customers billing history, but should not be able to create any transactions (Invoices, Collections). Billing Clerk should be able to create Invoices and Collections, but not to create the Adjustments; Billing Manager should be able to create Adjustments.

Pricing Rules

          The Charges consist of the following components. Each registrar account will have an initial non-refundable Licensing Charge. Each registrar account will have an annual Maintenance Charge. Transaction service charges will be cataloged as Domain Registration, Renew Domain, Transfer Registrar (for gaining registrars). (It may be decided by the policy group that any access of RRP such as changes to the name server, will also be a billable event)

Additional Information and Provisioning Information

          There should be a facility for configuring custom (user-defined) fields for information purposes (additional information) and as parameters for the Provisioning System (provisioning information). Each Service Type may require different information (parameters) to be recorded.

Summary

          Diagram 11 shows the relationship between Registry, Registrar and Provider during a simple billing cycle:

          1. Registrar submits registration
          2. Provider debits account
          3. Consolidated statement sent to Registry
          4. Send invoice
          5. Pay to registry
          6. Account update

Diagram 11

Domain Registration Services

          The following fee incurring services that are provided by the RC Registry will be made available only to operational ICANN accredited registrars. Any reversals within grace periods must be documented as billing transaction events. (The policies adopted by the registry may cause a change in the terms described below. The billing system must be flexible enough to incorporate these changes.)

• Domain Registration: A registration term from one up to 10 years in total can be specified for new domain registrations. There will be a 5 day grace period to cancel a registration which will trigger a refunds to the registrar.
  
  
• Domain Renewal: Renewal of the domain registration will not result in a registration term longer than the maximum allowable term. Registrar requested renewals can be processed at anytime. The registry will automatically renew registrations by 1 year when domain registrations expire. Registrars shall have a 45 day grace period in which to cancel automatic renewal. If a registrar cancels an automatic renewal there will be a 5 day grace period during which the registrar can reinstate the registration. During this grace period the domain is effectively placed on hold. If the registration is not reinstated a refund will be issue to the registrar.
  
  
• Registrar Transfer: The domain will be registered for one additional year, for which the gaining registrar will be charged.

          The following non-transactional services that are provided by the registry will be made available only to operational ICANN accredited registrars.

• Monthly Account Statements: A detailed monthly transaction statement will be emailed to each customer. The statement will include: Account Summary, Balance Forward, Payments Received, Credits/Adjustments, Detailed list of all fee incurring charges, New Registrations, Registration Renewals, Registrar Transfers
  
  
• Online Billing Reports: Various billing related reports accessible via real time online interface
  
  
• Email notification will be sent for low account balance, insufficient funds, and to provide balance forecasting

          Pricing rates will be defined by the Registrars' Consortium.

          Transactional service charges, initial setup fees and annual yearly fees will be globally applied to all customers.

Billing

          The following Customer Types are defined for billing purposes:

Direct Customer
A customer of the RC's TLD(s) Registry Service.

External Registry
A sponsor of another TLD Registry (ER) using the RC's Registry services.

External Registry Customer
A customer of an ER.

Payment Method Types

          The registry will accept payments by the following methods:

Wire transfer
Any service charges should be the responsibility of the customer.

Debit account
A customer debit account will be established and drawn from for each fee incurring transaction. A positive debit account balance that covers an incurring fee must be maintained or the requested service will not be processed.

Customer Notifications and Reports

          The system will email "Low Account Balance", "Insufficient Funds", and "Balance Forecasting" notifications to all customers as an account management service. The system will also provide emailed monthly account summaries and online transaction reporting tools.

Functionality and Process Flows

          Prior to having an account set up on the registry system's testing environment, each customer will complete and sign a Registry Service Agreement, provide all required customer, contact, and other security related information for purposes of obtaining Operational Certification Status.

          Once a customer has been certified, an annual maintenance fee will be charged before the account is awarded Operational Status. Following receipt of payment, the account is moved into the live operational registry environment where real-time service transactions will be implemented.

          Diagram 12 shows the relationship during the establishment of an account with the registry, and the steps to becoming operational:

1. Contract phase: The registrar completes all contractual documents directly with registry in order to begin the operational tract.
   
   
2. Command to issue software: Registry instructs the provider to release the RRP Software and registrar tool kit to the registrar. Account is set up on the registry database, entered as "test" status.
   
   
3. OT&E test suite: The provider issues the software and supporting tool kit, and conducts the operational test suite with the registrar.
   
   
4. Positive test results: Provider gives immediate feedback directly to the registrar of the status; when the results are positive, the registrar is considered to have passed the tests.
   
   
5. Report of test: Provider reports to the registry that the registrar has successfully completed the test suite.
   
   
6. Account setup: The registrar now sets up the financial accounts in order to guarantee prepayment of domain names. Typically, an amount equivalent to the volume of registrations is put into an account accessible by the registry.
   
   
7. Go live command: Upon confirmation of the registrar account setup, the registry will issue a command to the provider directing them to change the status of the registrar from "test" status to "active" status, and indicates the amount of the credits that should be entered into the registrar's online account. Simultaneously, the registry issues the notification to the registrar that it has been put into active status, and that it can begin registering domain names.

Transactional Services

          The following services will trigger billing events through an API:

Add Domain

• Customer issues request to register new domain for a specified number of years
  
  
• Required fee calculation: yearly fee X requested term
  
  
• Debit account balance checked to verify required fees
  
  
• Domain registered
  
  
• Required transaction fees drawn from customer's account

Cancel Domain

• Customer issues request to cancel registration
  
  
• Registration is canceled
  
  
• System verifies time of request is within 5 day grace period
  
  
• Customer's debit account credited the total transaction fee

Automatic Renew Domain

• The system will automatically issue a request to renew a domain for one year if the customer has not issued a request to renew or cancel.
  
  
• Required fee calculation: yearly fee X 1
  
  
• Debit account balance checked to verify required fees
  
  
• Domain renewed for one year
  
  
• Required transaction fees drawn from customer's account

Customer Requested Renew Domain

• Customer issues request to renew domain for a specified number of years
  
  
• Required fee calculation: yearly fee X requested term (requested term adjusted if resulting registration renewal term exceeds 10 years)
  
  
• Debit account balance checked to verify required fees
  
  
• Domain renewed
  
  
• Required transaction fees drawn from customer's account

• Customer issues request to cancel registration renewal
• Registration is canceled
• System verifies time of request is within 45 day grace period
• Customer's debit account credited the total transaction fee

Registrar Transfer

• Customer issues request to transfer domain registrar
  
• Required fee calculation: yearly fee X 1
  
• Debit account balance checked to verify required fees
  
• Domain transferred and 1 year added to registration term (not to exceed 10 years)
  
• Required transaction fees drawn from customer's account

Billing Customer Support

          The billing system operator will provide adequate customer support on a 24/7 basis. The customer support must be made available by phone, email, and fax methods of contact. There should be a sufficient conduit for support escalation to a higher level of billing system administration and/or to operations support.

          D15.2.7. Data escrow and backup:

          Afilias recognizes the risks posed to the stability of the DNS by the failure of registrars to escrow their Whois and other registration data. Under the decentralized registration database structure currently used in the .com, .net and .org TLDs, registration data lost due to a systems or other failure is often irretrievable.

          A centralized, registry-level database will enable the Company to create redundant systems and mirrors of the registry database and protect against the loss of registration data. The Company also intends to escrow the data contained in the registry database, which is the source for the Whois database, with a trusted third party such as ICANN should it makes itself available for such escrow services. Further, the Company intends to adhere to all data escrow requirements that may be promulgated by ICANN in connection with unrestricted TLDs, including with respect to encryption, relational databases, additional formatting such as XML and minimum update requirements.

          Tucows has extensive backup systems ensuring near-zero data loss. Critical data is housed in RAID disk arrays, replicated on disk in real-time, and backed up to tape on a daily, weekly, and monthly basis.

          Tucows backup system is based on Legato Networker, with Sony AIT tapes in robotic tape drives. Back-up tapes are sent to offsite storage with Iron Mountain, a secure storage facility.

          Escrow data is created monthly, with one copy sent to Iron Mountain, and the other copy sent to the legal firm of Goodman, Phillips & Vineberg of Toronto, Canada.

          D15.2.8. Publicly accessible look up/Whois service:

          There is currently no centralized, real-time Whois system in the .com, .net and .org TLDs. Rather, individual Whois databases are maintained by individual registrars. Persons searching for information regarding a particular domain name registration are thus forced to query each registrar database to find the information they are seeking.

          Although VeriSign Global Registry Services ("VeriSign") operates a registry-level Whois database, it is not updated in real-time. Accordingly, a person searching for Whois information must confirm information obtained at the registry-level Whois with the registrar-level Whois. Technical Whois protocols and policies are currently not standardized among the registrars, and individual registrars have their own practices with respect to the frequency of updates, formatting, and the amount of information disclosed through the Whois service. As a result, information in the registry-operated Whois may be inconsistent with that contained in the registrar-operated Whois. This inconsistency can cause problems both for third parties trying to obtain information on a domain name or registrant, and domain name owners seeking to verify that changes to their own information have been made.

          Afilias will eliminate the aforementioned problems through the maintenance of a registry-level Whois database that will contain information for every domain name registered in the new TLD and be accessible by the general public. The Whois service will contain data transferred by registrars during the registration process. If a registrant changes any registration information relating to the registrant's domain name, the registrar will communicate these changes to the registry at the time they are received. This will provide interested parties with access to up-to-date information for every domain name registered in the new TLD, under a standard protocol with a consistent format.

          The information available through the registry Whois database will include:

• Registrant contact information, including names, postal and e-mail addresses and telephone numbers of technical, administrative and billing contacts;
  
• Registration status and the registration's expiration date.
  
• The date the registration issued for the domain name;
  
• Registrar contact information, including name, postal and e-mail addresses, home page, and telephone number;
  
• Registrar status, including whether the registrar is in good standing with the Company; and
  
• Technical information about the domain name, including information about the nameserver and IP address.

           In order to accommodate the inclusion of additional information in the future, as may be required by ICANN, pursuant to future Company policy or to conform with individual registrar policies, the Whois database will include additional fields for storing and displaying such information. Currently, the Company anticipates that the trademark information that registrants will be required to provide during the Sunrise Period (as described in Section E15) will fall into this category of additional information.

          The Company does not currently intend to provide Whois query capabilities on its own web site. Rather, all queries for the registry-level Whois shall be conducted via individual registrar web sites. Each query will be sent, via an interface, to the Company Whois servers, and the results of each query will be submitted by the Company directly to the registrar website, in order to insure the accuracy of such information.

          In addition to a general Whois query service similar to that currently available through individual registrars, the Company will also provide interested third parties with bulk access to the full Whois database on a subscription basis in a machine-readable format. Bulk access will provide intellectual property owners with the ability to more effectively police their marks while reducing the load on the core Whois system.

          Finally, Afilias intends to develop and offer a subscription-based interface to the Whois database that will permit interested third parties to conduct enhanced Whois searches using boolean and character string technologies. Enhanced search functions will include the ability to identify (i) registered domain names that incorporate a certain character string, or (ii) all the domain names registered by a certain registrant. This service will be a follow on development project that is not expected to be operational in the first 12 months of operations.

Technical Specifications

          The Registry Whois system must be designed for extreme robustness, availability and performance. Additionally, provisions for detection of abusive usage (e.g. excessive numbers of queries from one source) must be made. The Whois system is intended as a publicly available single object lookup. A different service is provided for bulk access.

Lookup Keys

          A query for any domain name should contain information about:

• Domain name
  
• Registration status: available|registered|error (Examples of errors include bad syntax, TLD not sponsored by registry)
  
• Domain status: hold, lock, transfer_in_process, etc.
  
• Current registrar
  
• Both the full name and the lookup key (id/short name):
  
• Current registrar's Whois servers (see 1.4.1)
  
• Associated nameservers and their IP addresses where applicable
  
• Time stamps: registration date, date of last update, expiry date, etc.

          A query for a nameserver should contain the following information:

• Nameserver host name
• Nameserver IP addresses if applicable
• Current registrar if applicable

          An IP address is not a uniquely tied to one nameserver, therefore the result of a such query will show all nameservers associated with that IP address.

          A query for a registrar should contain information about:

• Registrar name, postal address
• Whois servers (see 1.4.1)
• Registrar's status (e.g., OT&E, operational)
• Contacts

          Several dedicated contact types should be defined, to allow for distinctive addressing of questions to the appropriate contact:

• Administrative contact
• General customer support
• Billing support
• Contact for registrar transfer handling, etc.

          The registry should maintain some more contacts for internal usage only between registrars, which are not shown in the publicly available Whois.

          A query for the list of all registrars should provide a list of all registrars accredited for the registry. It should contain the following information:

• Full name
• ID or short name (a 4 letter or number code to identify the registrar)

          Additionally, there is an internet draft of XML based output available at ftp://ftp.ietf.org/internet-drafts/draft-wesson-Whois-export-01.txt . It might be considered for incorporation either in the port 43 based Whois service using a different query syntax (e.g. xml.domainname), or by using a different port number (this would be a future development).

          A better registry should not only have a real-time RRP but also a real-time Whois. There are sophisticated software solutions available to provide for the necessary performance (e.g. read-only-mirror-databases, caching systems). Implementation of a real-time information Whois service is recommended and would also help reduce the load on the RRP.

          The Tucows Whois service is managed as a two-part facility, supporting both localized and centralized capabilities. The localized Whois services are managed as facility of the operation at various registry points. In addition, a large centralized high capacity Whois service is managed as the authoritative source of Whois information.

          The throughput of the Whois service is significantly higher than current query volumes. It also exceeds long-term estimates of query volume. The architecture of the Whois service allows it to be easily scaled in order to meet increasing demand and volumes. This can be done without introducing any data integrity problems.

          The Whois systems run on high-end Sun Microsystems servers and are hosted in highly secure Exodus locations. Using strong data encryption where necessary ensures data security. Connectivity to the Internet is via multiple redundant OC48 connections.

          Access to the physical systems and data is strictly controlled and managed by Tucows.

          D15.2.9. System security:

Physical Security

          All critical registry production systems will be located within secure data centers with the following minimum security standards:

• 24/7 on-site security personnel and security monitoring
• Surveillance cameras
• Controlled access to the data center floor through man traps
• Use of biometric identification systems

          Physical access to the facility will be limited to a small number of technical personnel such as system administrators who will need to perform work such as upgrading or installing equipment. Most administrative functions and all customer support functions will occur remotely, with no physical access to the facility.

          For the Tucows solution, all facilities are colocated with Exodus Communication. All Exodus locations are high security buildings. Security guards are on duty 24/7, and enforce a sign in process where anyone entering facility must be on the approved list. Visitors must show legal photo ID to be granted access to each facility. Once inside the facility, people must use a card key and palm scanner to gain access to the data centre. The Tucows cages are locked within the data centre, and must be unlocked by security. The entire facility is monitored by video surveillance. Multiple air conditioning units are configured in a fully redundant array. Multiple UPS power units with battery backup provide clean and reliable electrical power. Multiple diesel generators are available for extended power outages, in a fully redundant array. Kevlar lined walls for protection against explosion from the outside.

Network Security

          The registry will employ a number of measures to prevent unauthorized access to its network and internal systems. Before reaching the registry network, all traffic will pass through a firewall system. Packets passing to or from the Internet will be inspected, and unauthorized or unexpected attempts to connect to the registry servers will be denied and logged. The registry routers will also act as the first line of defense against any denial of service attacks, with the ability to instantly deny traffic from a specific host, network, or even an entire Internet Service Provider.

          Front-end registry servers should generally sit behind a second layer of network security (provided by load balancing equipment). The hosts should use RFC 1918 reserved address space that is not routable on the public Internet. Packets destined for specific services (such as DNS or the registry SSL-protected applications) will be translated only after being subjected to additional security checks; suspicious traffic is dropped before being translated and cannot reach the servers. Additionally, front-end systems will be arranged into load balanced clusters; even if an attack is successful on an individual host, subsequent requests by the attacker will reach other servers, making it extremely difficult to take advantage of any weakness. Critical internal systems, such as database and file servers, will also have non-routable IP addresses, and absolutely no traffic is to be permitted to reach them from the public Internet.

          Servers that cannot be secured on RFC 1918 addresses will sit in a demilitarized zone (DMZ) separate from the main registry network. Traffic passing from the Internet or the DMZ to the secure internal network must pass through a firewall enforcing a strict security policy.

          The registry will install a network-based intrusion detection system (IDS) that will monitor the network for suspicious activity. If possible malicious activity is detected, appropriate personnel will be notified immediately.

Server Security

          The registry will employ a set of security precautions to ensure maximum security on each of its servers. Minimum standards on each server include:

• Disabling all unnecessary services and processes
  
  
• Regular application of security-related patches to the operating system or critical system applications
  
  
• Installation of tools such as SYN cookies to prevent denial of service attacks
  
  
• Use of tripwire and log file analysis to ensure the ongoing integrity of each system

           Accounts on all production systems will only be assigned to a limited set of administrative personnel. Developers, customer service employees, and others will not have login accounts on these servers.

           Before the registry goes into production, and on a recurring basis, the registry will work with a third party to conduct a detailed audit of its server configuration to verify that it complies with current best security practices.

Application Security

           The registry application will use SSL encrypted network communications. This will prevent malicious third parties from intercepting communications with between registrars and the registry. Access to the registry server will be controlled by three mechanisms:

1. Username and password - Each registrar will be assigned a username and a password that they will keep secure. The passwords will be stored in encrypted form, so that even the registry will not have access to all of the registrars passwords. The password for each username will be changed on a periodic basis.
   
   
2. Client side SSL certificates - Each registrar will use a certificate with their registrar user name as the common name field in the distinguished name (this is the field that is used for the domain name in secure web server certificates). The registry server will only accept certificates that are digitally signed by the registry. (This differs from the NSI registry practice of requiring that certificates be signed by a third party. This eliminates some expense for registrars, and allows the registry to rely on the trusted relationship that it establishes with registrars as opposed to the generic verification policies utilized by third parties.) At the time of signing, the registry will be able to validate that the person requesting the certificate does in fact represent the registrar who has been assigned that particular username. The registry server will only accept connections from a client when the username they log in as matches the username in the certificate.
   
   
3. IP Address Filtering - The registry server will only permit logins from an restricted list of IP addresses. Each registrar will have a list of IP addresses associated with it. This would mean that even though the IP addressees of all registrars will be able to access the registry network, each registrar will only be able to log in from their own IP address range. In order to allow its clients to take advantage of redundant configuration or other special needs, the registry will permit multiple IP ranges per registrar.

           Unlike the current Shared Registry, which considers each of the security factors above independently, the proposed registry will only allow access to a registrar if each of the authentication factors matches the specific registrar. In other words, a registrar must connect using its particular username/password combination and its SSL certificate from its IP address.

           These mechanisms will also be used to secure any web based tools that will allow registrars to access the registry. Additionally, all transactions in the registry (whether conducted by registrars or the registry own personnel) will be logged to ensure accountability and an appropriate audit trail.

Security of Registry Customer Service

           Since the registry customer service will also be able to take actions on behalf of registrars, the personal communication process must be secure as well. Registrars will have to supply a list of specific individuals (5 to 10 people) that are authorized to contact the registry. Each individual will also be assigned a pass phrase. Any phone requests made by a registrar to registry customer service will have to come from someone on the authorized list, and require the pass phrase to be supplied. Any e-mail requests will also need to come from someone on that list and be encrypted and signed with PGP. The registry will store the e-mail address and PGP public key of each authorized person. If a registrar should choose not to use PGP, they can send plain text e-mail and have the registry contact them by phone to verify the pass phrase. In the event that an attempt is made to contact the registry customer service on behalf of a registrar, but appropriate authentication is not provided, the registry will make contact with the registrar to inform it of a breach of security protocol.

           The use of individual passwords and PGP keys allows the registry to identify those who contact its customer service personnel as individuals. This prevents name spoofing (one individual at a registrar pretending to be another) and allows the registry to grant different levels of privilege to different individuals.

Role of the Consortium vs. Outsourced Hosting Provider

           Although most of the security infrastructure will be implemented by an outsourced hosting provider, the registry consortium will still be responsible for key elements of security. Most importantly, the consortium will retain a security officer to verify that these security practices are implemented in the registry design and on an ongoing basis. The security officer will also be responsible for responding to potential attacks on the registry and maintaining security-related information regarding individual registrars.

           Additionally, some types of information, such as billing or other financial data, may only be stored with the consortium and not at the hosting provider. This approach not only allows the consortium to have direct access to important information to offer high quality service, but also mitigates the effects of a successful attack upon the registry outsourced facilities.

           Physical security is handled by Exodus, where the severs are co-located. These are secure facilities, with 24/7 security guards, video camera surveillance, card key access with palm scanners. All servers are installed in locked cages within the data center, these can only be unlocked by security personnel at Exodus.

           Internet security is maintained using firewalls with packet filtering on routers. Access lists are also in place where appropriate. In addition, intrusion detection software monitors the systems and notifies Tucows 24/7 Operations of any attempted intrusions.

           All root/super-user accounts have passwords changed regularly. Shell accounts on production servers are kept to an absolute minimum and limited strictly to senior Network and Operations staff. Secure shell connections are used by Tucows Operations staff to access servers remotely. Any unnecessary services are disabled.

          Tucows has out-of-band management connections to production servers; should there be a denial of service attack on the systems, Tucows Operations staff are still able to connect to the server and address the situation.

          Root access is controlled and managed by Tucows Operations.

          Tucows will invoke pre-determined and documented disaster recovery procedures should they be required.

          Tucows will leverage Exodus's highly redundant infrastructure in event of disaster, as well as having internal business disaster plans in place.

          Intellectual property security is addressed in many ways. From an access perspective, Tucows has firewall and packet filtering enabled on all routers.

          These systems have intrusion detection that will alert Tucows Operations staff should there be an attempted intrusion. All servers have strictly managed root/super user access with passwords that are chosen to be difficult to break (e.g. no proper words are used). These passwords are changed regularly, a minimum of once a month, or sooner if required.

          D15.2.10. Peak capacities:.

          Afilias expects a significant rush for domain name registrations during the period immediately following the initial opening of the TLD, after the close of the Sunrise Period, as described in Section E15 (the "Start-Up Period").

          It is difficult to predict with certainty the volume of registrations that will be received in the new TLD during the Start-up Period, but Afilias's forecasts suggest that the volume will be as follows:

• First day: approximately 125,000 registrations

• First week: approximately 375,000 registrations

• First month: approximately 900,000 registrations

• First quarter: approximately 1,875,000 registrations

           In order to roll-out the registry in a responsible fashion, and insure proper and accurate processing of the registrations in a fair manner across all registrars, the Company will implement the following variations in its registry policies during the Start-Up Period.

          The Company will base the length of the Start-Up Period on the volume of registration requests received per day, the number of registrars and the time necessary to permit registrars to migrate to the systems that will be used during the normal operation of the registry. This period will end when the volume of registrations recedes sufficiently to permit real-time registration of domain names. The Company does not expect such Period to last for more than three months.

          In its normal operation, the Company will accept and process registration requests in real time. The expected volume during the Start-Up Period, however, could overwhelm the registry system ability to process such requests at that speed. If Afilias systems are overwhelmed, they will not be able to process registration requests from registrars as quickly as they are submitted by registrants, which could cause the registrar systems to back-up and fail.

          The Company will implement a registration queue system to avoid these problems and ensure that all registrar requests are processed fairly and equally, and is considering a number of variations on that system. Under the basic queue system, each registrar will assemble a queue of its registration requests, Afilias will download portions of each queue as a batch file and then will process requests from each registrar in a random order using a round robin system. When the Company has completed processing each batch file, the Company will download a new batch file from each registrar and the process will repeat. This round robin approach will allow each registrar to have a fair and equal opportunity to submit requests to the Company during the Start-Up Period.

          Afilias is considering a variety or modifications to the basic queue system that could discourage certain types of practices. For example, the registry could randomize each batch file in order to limit the sale of premium placements in a batch. It could also process requests individually by registrar, instead of processing a series of requests from one registrar until one was successful in order to discourage registrars from filling their randomized batch files with false registration requests that will be denied by the registry system with the intent to accelerate the progress of legitimate requests through the queue, a service for which the registrar could charge a premium price, at the sacrifice of receiving a high volume of registrations.

           After testing each concept, Afilias will implement the system that it believes will efficiently offer each registrant the fairest chance of receiving a registration, regardless of the registrar chosen or the fee paid.

           The Company expects that registrars will accept pre-registrations for domain names under the new TLD, and that other third parties such as resellers and domain name brokers will also accept pre-orders for domain names that will either be submitted to registrars as pre-registrations, or will be submitted immediately following the opening of the TLD. By implementing the round robin approach during the Start-Up Period, the Company believes that it will minimize the advantages that pre-registrations could provide.

           During the Start-Up Period, the Company will suspend its policy of allowing registrars to cancel domain name registrations within five days after they issue, as described in Section E8. This policy, while permitting registrars and registrants to cancel registrations that were submitted in error, also provides domain name speculators with a means for submitting a large number of domain name requests in the hopes of registering only some of the names and paying only for the best of the domain names successfully registered. These bulk submissions create an enormous load on the registry system which, during the Start-Up Period, will limit the registry system ability to process non-bulk requests. Accordingly, the five day discretionary cancellation policy will not commence until after the conclusion of the Start-Up Period. However, cancellations initiated for non-payment or other reasons will be processed as normal.

           All domain name registrations that issue during the Start-Up Period will be locked for the duration of that period, meaning that registrants will not be able to either make changes to their registration information or transfer a registration until the Start-Up Period is over. Such lock will serve to reduce the burden on the registry system during the Start-Up Period. However, as it will throughout its operation of the proposed TLD, Afilias will comply with the order of any court of competent jurisdiction, including orders to transfer a registration to a new registrar or registrant.

           The Tucows system is designed so that peak load can be scaled across multiple processors and multiple servers using a load balancing algorithm. A single mid-range server is capable of handling a peak 286 registration requests per second. Since the architecture is highly scalable, more servers can be easily added. Therefore, no difficulty is foreseen in handling extremely large capacities. Tucows has ensured that all applications and their infrastructures are highly scalable, allowing for easy increases in processing/transaction capacity.

           The backup systems in place will similarly have more than sufficient to handle peak capacities. Maintenance personnel have been allocated based on estimations of average and peak capacities. Additional resources are not anticipated, but can be quickly added if necessary.

           The current test-bed throughput has the capacity to deal with roughly 1.76 completed registration transactions per second (including the associated lookups, billing functions etc.). This works out to roughly 150,000 registrations per day working from one Intel based server (Whois, SRS etc.). The architecture of the system as described should allow for exponentially scaling, with very little overhead, based on the "one-box" numbers. For two servers the capacity should clime to 3.49 crtps. The system is built to ensure the ability to scale to meet almost unlimited demand.

           D15.2.11. System reliability:

           The system is designed so that peak load can be scaled across multiple processors and multiple servers using a load-balancing algorithm. This results in high reliability and redundancy.

           The architecture is highly scalable, and allows several instances of the system to be running simultaneously. Automatic fail-over of the system and subsystems is an integral part of the design of the architecture.

           The system will provide 99.9% availability.

Following testing of the system the following SLA criteria will be added:

           Whois response time
           Whois update maximum lag time
           Zone file update maximum lag time

           All servers are carrier class servers with multiple processors, minimum of 2G memory, redundant hot swappable power supplies (fed from separate UPS breakers), hardware RAID arrays with hot swappable disk drives. Servers are rack optimized, and have field swappable modular components for ease of service.

Availability of hardware components exceeds 99.8%, and mean time between failures is in the thousands of hours. Due to the nature of the architecture, the systems can continue to function even if an entire server were to suffer catastrophic failure.

           Tucows utilizes load balancers to assist in scalability as well as to prevent service outages. Due to the nature of load balancing, in many cases it is possible to also perform upgrades on servers without the customer being impacted. Currently, Tucows has relationships with Radware, Resonate, and F5 for load balancing solutions that are external to the application layer load balancing.

           Systems are protected with Cisco PIX firewalls, and Cisco routers are used throughout the system.

           The database layer that handles the rules and manages the data necessary to support the registry model is composed of services that handle the various registry objects, such as domains, nameservers, and registrants. Multiple instances of each of the services are supported. A load balancer supports the delegation of requests between multiple service handlers. This provides high performance, and high availability.

           The database layer also contains the database store itself. This consists of two database systems with data replicated between them on a continuous basis. If one database fails, the other is able to take over registry operations immediately. By supporting multiple database stores, the registry system offers high performance and high availability.

           All load balancing will be performed by Radware Multi-LAN.

           Services such as DNS servers and Whois servers are load balanced for high performance and high availability. Each registry object service will run on a Sun E450 with quad CPU, 2GB of RAM, 2x36 GB mirrored hard drives, running the Solaris operating system. Equipment within the registry model is connected with dual homed 100Mbit connections. A separate network is used for backups.

           The databases will each run on a Sun E10000 with 16 CPU, 8G of RAM, 8x72 GB RAID hard drives, running the Solaris operating system and a Oracle database.

           The OpenXRS registry uses two Oracle databases, a primary and a secondary, which are continuously replicated. Each Oracle database runs on a Sun E10000, with 16 CPU , Solaris operating system, 8 GB of RAM, and 8 x 72 GB RAID drives.

           Connections between hardware in the OpenXRS registry is made with dual homed 100Mbit connections. A separate network is used for backups.

           In order to provide a more robust and scalable model, the registry is operated in a number of locations. Registries are paired up so that they mirror each other data. This allows for fail-over and fault tolerance in the case of one of the pairs becoming inaccessible.

           Registry facilities will be operated in two geographic locations, allowing for redundancy and fault tolerance. The primary registry facility will be operated in Toronto, Ontario, Canada. The secondary registry facility will be operated in Seattle, Washington, USA.

           The primary registry facility will be a live facility, meaning that it will be the normal full-time registry. The secondary registry facility will be a standby facility, meaning that it will only be activated because of operational concerns about the primary facility.

           The secondary facility will remain continuously synchronized with the primary facility using the mirroring mechanism described earlier and illustrated on Diagram 13. Exodus will host the physical servers and systems for both the primary and secondary locations. They will be connected to the Internet using OC48 connections. The primary and secondary facilities will be connected using a OC48 connection.

Diagram 13

           D15.2.12. System outage prevention:

           Many of the systems described in D15.2.11 directly contribute to reducing and preventing system outages. In particular the dual data center approach is a particular improvement over the current NSI model.

           The Tucows data center collocated with Exodus provides a fully redundant environment with dual UPS, redundant air conditioning, and security. In addition all critical data is backed up to tape daily, and stored off site.

           Each server is connected via Gigabit Ethernet to the Exodus core, where it has multiple OC-48 connections to the backbone/Internet. Further Tucows maintains on-site inventories of spare components which may fail, specifically: disk drives, CPU , power supplies, network cables, memory modules (DIMMs). Tucows supports same day maintenance on all servers. As well, Tucows houses spare server components on site.

           HP Openview and Firehunter are used for system management. These products regularly poll all components to query system and application parameters. Should any parameter be out of spec, an alert is generated and 24/7 Operations staff are notified.

           All software applications developed by Tucows create a detailed error alert if the application encounters a situation that deviates from the baseline specification. These application alerts are automatically sent to the network management system, which generates an alert to the Operations staff 24/7.

           Tucows has 24/7 Operations staff, with all member of the department on call. Escalation procedures are in place ensuring that management is notified of service outages in a timely manner

           D15.2.13. System recovery procedures:

           As the architecture contemplates both live and standby systems in geographically disparate locations, the following descriptions apply to well-contained, non-emergency failures at individual points within the system.

           Well-documented procedures are in place for recovering systems from back up tapes should the system suffer catastrophic failures at both locations. The staff that would perform this recovery are skilled System Administrators with several year experience.

           Tucows has a standard server configuration with respect to operating system and application tools, locations, and so on. All Operations staff have been trained on this configuration and associated procedures. This facilitates the fast re-build of any server if required, thereby ensuring minimal downtime.

           Due to Exodus physical environment, it is very unlikely that a power failure will impact service. UPS systems are fully redundant as are the diesel generators. Tucows servers have redundant power supplies, with each one connected to a separate power feed and breaker.

           Projected time for recovering a system that suffered catastrophic data loss would depend entirely on the specific situation that occurred, and can not be estimated precisely. However, in the worst case scenario, an entire server can be built from scratch, including data recovery from tape, in less than one day.

           It is worth reiterating, that because of the inherently redundant architecture of the system, a single server (in some cases even multiple servers) can fail without severely impacting the system ability to handle transactions.

           In the worst case of outage, Afilias recognizes the importance of a complete suite of escrowed data. Afilias recognizes the risks posed to the stability of the DNS by the failure of registrars to escrow their Whois and other registration data. Under the decentralized registration database structure currently used in the .com, .net and .org TLDs, registration data lost due to a systems or other failure is often irretrievable.

           A centralized, registry-level database will enable the Company to create redundant systems and mirrors of the registry database and protect against the loss of registration data. The Company also intends to escrow the data contained in the registry database, which is the source for the Whois database, with a trusted third party such as ICANN should it makes itself available for such escrow services. Further, the Company intends to adhere to all data escrow requirements that may be promulgated by ICANN in connection with unrestricted TLDs, including with respect to encryption, relational databases, additional formatting such as XML and minimum update requirements.

           D15.2.14. Technical and other support:

           The Registry Operator shall provide a complete package of support services through the Technical Support Group ("TSG"). These services will be dedicated primarily to operational registrars, although inquiries from potential registrars, or those in evaluation stages shall be supported by a sub-group of the TSG. Overall, the TSG shall attempt to provide round the clock, real time professional support ranging from basic inquiries to high level operations critical technical support. Registrars shall receive equal levels of support regardless of their location of operations. Although English shall be the primary language of support during the initial phases, should registrar demand warrant, in future phases of development support in other languages will also be considered.

Access to Registry Data

           The TSG shall have access to registry data sufficient to support the registrar, to the extent that current operating status can be determined, response to specific registrar queries about registrar specific data or specific transactions can be provided. Access to the registry for support staff shall be based on the level of seniority in the TSG, and thus be scaled such that entry level employees have only basic read access to critical data. Tucows employees would be required to properly identify the registrar before providing any registrar critical data, and be prohibited from providing information about other registrar operations.

Help Desk

           Registrar support inquiries will be made to the Tucows TSG help desk. Access to the help desk will be through telephone, email and web based interface. Help desk manning and accessibility is explained through the criteria that follow.

Support for Domain Name Registrants, and Internet Users

           The TSG shall offer support tools for end users in order to improve customer service. In specific, the TSG shall provide an interface that will allow a user to determine the appropriate registrar customer support contact information based on the domain name.

Escalation

           The TSG will operate with an escalation device. Normally support calls or other forms of communication shall start with the lowest level of support, and be escalated should the first level of support be insufficient. In cases where higher levels of support are immediately apparent (all levels of support staff will be trained in identifying these) the escalation chain may be jumped. Also, should the time limit expire with no notice, the support level may be escalated. The escalation levels and response requirements are as follows:

24/7/365 Support

          It is absolutely critical that round the clock support be provided, at a 24 hours per day, seven days per week, 365 days per year basis. To meet this requirement TSG staff shall be assigned on a shift basis, which will require significant manpower from the beginning. (related to escalation policy)

          If geographic diversity is considered feasible during subsequent phases, it is likely that each geographic location shall have primary tech support responsibilities during daylight hours of that time zone. This could offset issues of hiring difficulties for late night shift personnel, and will also provide a higher level of support quality.

Notification for Outages

          Tucows TSG shall be responsible for notifying operating registrars of upcoming maintenance and outages with strict requirements regarding advance notice. At a minimum, all planned outages and maintenance shall be announced at least 30 days prior. A reminder notification with additional details about the maintenance will be provided at least 7 days and 2 days prior to the scheduled date. Further, the TSG shall be required to provide immediate notice of unplanned or unscheduled outages and maintenance. A standard format shall be adopted in order to identify base requirement of information, such as time of occurrence, systems affected, estimated duration of outage, and time of next report. Outage notifications shall be catalogued and logged in order to assist compliance with the Service Level Agreement.

Support Systems, CTI, Database management

          All TSG communications should use to the fullest customer management resource (CMR) systems, computer telephony integration (CTI) and databases to retain a reliable record of registry performance. While institution of such systems may be gradual, the goal should be to provide as much as possible automated systems in order to increase efficiencies and scale of operations.

Geographic Diversity

          To the extent possible, the TSG shall attempt to diversity operations across geographic location. It is feasible to assume TSG operations facilities in North America, Europe, and Asia, operating in tandem to provide the best level of support to registrars in that region, and also to provide support after hours in a non intrusive manner. This geographic diverse nature of the support facilities shall provide better support for local business customs and in the future diverse language support for the registry.

Staffing

          Staffing levels shall be set initially so as to support the estimated 50 operational registrars during the start up phase with 24/7 support. Each watch team shall be made up of no less than 4 Level IV qualified support staff, no less than 2 Level III qualified systems operators, no less than 1 Level II qualified systems engineer and at least 1 Level I qualified senior systems engineer.

Security for Technical Support

          Since Tucows technical support will also be able to take actions on behalf of registrars, the personal communication process must be secure as well. Registrars will have to supply a list of specific individuals (5 to 10 people) that are authorized to contact the registry. Each individual will also be assigned a pass phrase. Any phone requests made by a registrar to registry customer service will have to come from someone on the authorized list, and require the pass phrase to be supplied. Any e-mail requests will also need to come from someone on that list and be encrypted and signed with PGP. The registry will store the e-mail address and PGP public key of each authorized person. If a registrar should choose not to use PGP, they can send plain text e-mail and have the registry contact them by phone to verify the pass phrase.

Registrar Contact Information

          Tucows TSG shall maintain a registrar contact information database in order to ensure it has an accurate list of appropriate registrar contacts and pass codes.

Incoming Registrar Support (OT&E )

          In addition to support for the operating registry, the Tucows TSG shall provide support (on a slightly more limited basis, i.e. not 24/7) for the Operational Testing and Evaluation system that shall be established to allow registrars to test RRP systems and new registrars to test systems before going live.

Standards Compliance

          The Operational Testing and Evaluation support group will also perform periodic standards compliance reviews of operational registrars, as well as conducting the registrar performance review before a registrar is permitted to go live on the system. In addition to standard performance response testing, the group will also test that all operational features are functioning correctly. The standards compliance section will accept complaints about registrars from SLD holders, as an alternative method for compliance measurement.

Registrar Survey

          To ensure that Tucows is providing the highest quality in customer service, the registry will periodically request a third-party to survey registrars for feedback. This would also be useful to evaluate the oursourced operator for the registry.

          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.

          Afilias signed a binding term sheet (the "Term Sheet") with Tucows, Inc. under which Tucows will provide certain registry functions to the Company in the event that ICANN accepts this proposal. Tucows intends to form a joint venture with Q9, Inc. ("Q9") and other minority partners ("RegCo") for the purpose of developing the Afilias registry system and to completely separate Tucows' registrar and registry operations. The Term Sheet is attached hereto as Appendix G. Appendix A to the Term Sheet, which sets forth the registry functions to be provided by Tucows, is identical to Sections D14 through D15.2 of this proposal.

          The initial shareholders of RegCo will be Tucows with a 49 percent interest and Q9 with a 15 percent interest. The remaining 36 percent interest will be divided among other minority shareholders with whom Tucows and Q9 are in discussions. Tucows and Q9 intend to capitalize RegCo sufficiently to cover all expenses anticipated in connection with the development and operation of the Afilias registry system.

          In the unlikely event that RegCo is not formed, Tucows will fund the development of the registry system out of its current cash flow. A copy of Tucows' balance sheet for first quarter 2000 is attached hereto as Exhibit E to Appendix H .

           A copy of Tucows' technical proposal is attached hereto as Appendix H. This Appendix also contains information regarding Tucows' technical, financial and management capabilities. Afilias will provide additional information regarding Tucows or RegCo to ICANN upon its request.

          A copy of the Memorandum of Understanding between Tucows and Q9 relating to Regco is attached as Appendix I .

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.

Counsel to the Company and Authorized Signatory

Afilias, LLC

October 2, 2000