[A Registry Operator's Proposal is to be submitted as part of every new TLD application. In case of applications for unsponsored TLDs, the registry operator will be the applicant and should prepare and submit the proposal as part of the application. In the case of applications for sponsored TLDs, the sponsoring organization (or, where the sponsoring organization has not yet been formed, organization(s) or person(s) proposing to form the sponsoring organization) will be the applicant. The sponsoring organization should select the proposed registry operator, have it prepare the Registry Operator's Proposal, and submit it as part of the application.
Please place the legend "CONFIDENTIAL" on any part of your description that you have listed in item F3.1 of your Statement of Requested Confidential Treatment of Materials Submitted.
The Registry Operator's Proposal should be separately bound (if more than one volume, please sequentially number them) and labeled: "Registry Operator's Proposal." and must cover all topics described below. This page, signed on behalf of the registry operator, should be included at the front of the Registry Operator's Proposal.]
I. GENERAL INFORMATION
D1. The first section of the Registry Operator's Proposal (after the signed copy of this page) should be a listing of the following information about the registry operator. Please key your responses to the designators (D1, D2, D3, etc.) below.
Acknowledged.
D2. The full legal name, principal address, telephone and fax numbers, and e-mail address of the registry operator.
Tucows Inc.,
535 Fifth Avenue, 17th 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
D3. The addresses and telephone and fax numbers of all other business locations of the registry operator.
Flint, Michigan
B Editorial, Author Relations, Content Development
Toronto, Canada
- Sales, Marketing, Administration
D4. The registry operator's type of business entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is organized.
Tucows is a corporation organized under the laws of Delaware, United States.
D5. URL of registry operator's principal world wide web site.
D6. Dun & Bradstreet D-U-N-S Number (if any) of registry operator.
N/A
D7. Number of employees.
D8. Registry operator's total revenue (in US dollars) in the last-ended fiscal year.
Total Revenue: US$2.834 million for the fiscal year May 4, 1999 through December 31, 1999.
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.
Directors:
Beny Steinmetz
Dennis Bennie
Erez Gissin
Stanley Stern
Colin Campbell
Officers:
Elliot Noss, President, CEO
Michael Cooperman, CFO
Scott Swedorski, Founder, Editor-in-Chief
David Keating, Vice President, Sales and Marketing
Frank Cotter, Vice President, Network and Operations
Beneficial Owners (more than 5%):
Eris Holdings B.V.
Poalim Nechasim (Menayot) Ltd.
Eurocom Communications Ltd.
XDL U.S. Holdings Inc.
Yossi Vardi
Colin Campbell
Relevant Managers:
Ross Wm. Rader, Director, Assigned Names Division
David Sutton, Director, Operations
Bruce Miner, Chief Software Architect
Indra Dosanjh, Director, Systems Integration
Michael Goldstein, Director, Brand Management
Kim Lerch, Director, Customer Service
Jacqui Cook, Director, Product Management, Names
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.
ROSS RADER - Director, Assigned Names Division
Telephone: 416-535-0123 x 335
Toll Free: (800) 371-6992
Cellular: 416-828-8783
International Toll Free: IAC (800) 371-6992
Facsimile: 416-531-2516
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.
N/A
II. BUSINESS CAPABILITIES AND PLAN
D13.1.1. Company information. Date of formation, legal status, primary location, size of staff, formal alliances, references, corporate or other structure, ownership structure.
Incorporated in the state of Delaware on May 1, 1999, Tucows' primary office is located in Toronto, Ontario with branch and satellite offices in Flint, MN, New York, NY, Los Angeles, CA and Philadelphia, PA. Altogether, the company has 230 persons on staff.
Tucows has forged formal relationships with the following organizations:
Tucows is a privately held firm, with majority ownership interest held by a group of private investors. For more information concerning the specifics of these holdings, please refer to the statement of beneficial ownership in section D.9 of this document.
Tucows corporate structure is depicted in the chart below:
D13.1.2. Current business operations. Core capabilities, services offered, products offered, duration of provision of services and products.
Since its formation in 1994, Tucows has developed tremendous expertise in assembling, presenting and distributing content over the Internet (www.tucows.com). Tucows offers Internet users comprehensive software reviews and a simple, reliable rating system, editorial resources, and download libraries and software including Windows®, BeOS®, Java®, MacIntosh®, Linux® , Handheld PDA's, Music, DeskTop Themes, Gaming Software, Children's Software, HTML Tools & Software, and access to News groups. In providing these services, Tucows has gathered extensive knowledge and expertise in the areas of global digital distribution, technical infrastructure management, and customer relationship management.
In addition, and of particular relevance, Tucows, an ICANN accredited registrar, operates Tucows OpenSRS (Open Shared Registration System). OpenSRS is the industry's leading source of wholesale domain name registrations, providing it's Registration Service Providers with the most cost effective and easy-to-use features. Domain Direct, a retail service offered by Tucows, provides its clients with easy-to-use, cost-effective alternatives and enhancements to standard Web hosting. Tucows Names also features DomainSurfer.com, a next generation domain search engine that can retrieve thousands of registered domains at one time. DomainWatch.com, a service offered exclusively by the company, is a business intelligence service that monitors domain registration activities of individual registrars and resellers. Additionally, Tucows continues to consult and support the activities of several ICANN accredited registrars and delegated country code registries.
D13.1.3. Past business operations/entity history. History, date of formation, legal status/type of entity, initial services, duration of provision of services and products.
Through various predecessor organizations, Tucows has been providing Internet services on a variety of levels since 1994. The following is a brief overview of corporate heritage and associated dates.
Tucows was originally founded in 1993 in Flint, Michigan as a distributor of software on the Internet. Individual suppliers contributed their programs to the Tucows "libraries" where they were reviewed and rated by the company's editorial group. In 1994,the company was purchased by a group of Torontonians who created Tucows Interactive Ltd. by merging the Flint based operation with a Toronto Internet service provider. The proprietors of the new company created a series of global relationships by devising a system of mirror Web sites that enabled Tucows to replicate the content of its web site on local ISP's around the world. This process facilitated the transfer of data to the end user as the consumer was able to conduct the download from a proximate web site. The company continues to develop and leverage its relationships with local affiliates to offer its growing set of applications to a larger network of end users.
On April 26, 1999, Tucows Inc., a Delaware corporation, was incorporated to purchase certain of the assets of the Tucows Division of Tucows Interactive.
Although, Tucows began providing domain name registration services on a retail basis in November 1997, prior to January 2000, Tucows generated the majority of its revenues from advertising. Since January 2000, the focus of the business has changed and the majority of revenues have been generated from the registration of domain names. The company's wholesale, or private label, operation commenced in January 2000 when it introduced a flexible infrastruc ture that enables the company's resellers to maintain their own pricing structures and relation ships with their clients, the registrants. Chronologically;
D13.1.4. Registry/database/Internet related experience and activities. Experience with database operation, Internet service provision.
Tucows has developed significant expertise in the areas of database operations, Internet service provision and DNS systems and infrastructure. Indeed, Tucows content distribution efforts have resulted in considerable technology assets and corporate experience. The primary assets drawn upon are the demonstrated capabilities to deal with terabytes of globally located data, data-set synchronization across thousands of host servers and secured authentication of thousands of globally located business partners accessing our systems from remote systems over insecure networks. To date, we have leveraged this expertise against;
- Tucows OpenSRS; a wholesale domain name registration service providing SLD registrations to thousands of business partners in the .uk, .ca, .com, .net and .org namespaces. This service will be extended to offer an additional 100 top-level domain categories to our partners throughout 2000/2001. The OpenSRS system is a standards based client/server application primarily based on open-source tools and software. It currently facilitates more registrations on a daily basis than any other business-to-business or wholesale registrar.
- Tucows OpenXRS; a domain name registry services management system. Currently operating as a functional prototype for the fictional ".moo" TLD, this service has provided registrations to over 200,000 registrants since it's launch on August 1, 2000. OpenXRS (Extensible Registry Service) is a standards based, geographically distributed registry platform integrating best of breed solutions from IBM, Sun, ISC and Oracle with our own proprietary software and manage ment technologies. Tucows is currently in the final stages of negotiation with a country to provide them with technology and management services for their country code registry, centering around the OpenXRS platform.
D13.1.5. Mission. The registry operator's mission and how it relates to expansion into the registry operation field.
Tucows is the leading Internet channel management company, providing digital products, applications and services to Managed Service Providers (MSPs) on a global basis. Managed Service Providers are the most lucrative segment of the Internet economy, with first-touch customer access and an ongoing billing relationship with their end-users. Tucows has the largest channel of MSPs with over 5000 relationships in over 110 countries around the World.
DNS provisioning, management and innovation is not only central to the operation of the Internet, but also to the business operations of our MSP partners. As such, it is critical that we continue to expand the breadth of depth of our offerings in this space to ensure that the ongoing needs of our partners and their clients are met and exceeded. Our commitment to our partners and resultingly, the larger Internet as a whole, is based on the underlying principle that these services must be offered in a responsible, open and accessible fashion. Our initial content offerings were brought forth on this basis. This has also guided our activities as a registrar, and we continue to move forward in accordance with these principles.
D13.1.6. Management. Qualifications and experience of financial and business officers and other relevant employees. Please address/include past experience, resumes, references, biographies.
SCOTT SWEDORSKI, Editor-in-Chief / Founder
Scott Swedorski is the Editor in Chief and founder of Tucows. While working for
local libraries in 1994, Scott noticed the public becoming more interested in
the phenomenon of the World Wide Web. So, as a hobby, Scott started Tucows (The
Ultimate Collection of Winsock Software). Gradually, the small site grew from
hosting only NCSA Mosaic and Trumpet Winsock to the thousands of applications
available today. As the rapid growth of software and information on the
Internet grew Scott noticed that more and more of his time was being used on
his "hobby" and less and less time was available for anything else.
So, Scott made Tucows his full-time job and continues to this day deciding on
content, helping to review software and approving all of the content on the
Tucows Network. As the founder of Tucows, Scott is well-placed to speak to a
variety of industry issues as a compelling and interesting spokesman for web
commerce, piracy, shareware development, Internet advertising, and finding the
latest and greatest Internet applications. Scott has a variety of media
experiences including print, radio and television appearances.
ELLIOT NOSS, President and C.E.O.
As President & C.E.O. of Tucows.com, Elliot possesses the extensive
industry experience to lead the company as a dynamic force in the Internet
market. He brings with him a broad spectrum of legal, financial and Internet
market background and has watched Tucows grow considerably during the time he
has been in office. Elliot started working with Tucows in 1997 as the Vice
President of Corporate Services. He played a significant role in the process
of the separation of the ISP division of the company (Internet Direct) from the
parent company and then took a leadership role heading up the new private
Ontario company, Tucows Interactive Ltd. Elliot then lead Tucows through an
acquisition by Steinmetz Technology Holding International resulting in a change
to Tucows.com Inc. He was then appointed to President & CEO of the
company in May 1999. Elliot leads the strategic direction of the company
through the creation of business plans, creating operational focus,
communicating the corporate vision and develop ing strategic relationships with
key industry players. Elliot has spoken on a wide variety of Internet-related
topics, including: web commerce, online advertising, market trends, online
harassment, ISP development, Internet regulation, anti-competitive activities
by telecom and cable companies, and many other topics. Elliot has a B.A. from
the University of Toronto and a M.B.A and L.L.B from the University of Western
Ontario.
ROSS RADER - Director, Assigned Names Division
Ross has gained valuable experience while working as the Director of Marketing
at Canada's largest independent Internet Service Provider, Internet Direct. He
took his experience to Tucows in joining the executive team heading the Tucows
Names Division, the industry's most compre hensive provider of domain name
registration and related services. At Tucows, Ross creates the business plan
and strategic direction of OpenSRS (Open Shared Registration System) is the
industry's leading source of wholesale domain name registrations and Domain
Direct, a retail group providing its clients with easy-to-use, cost-effective
alternatives and enhancements to standard Web hosting. Ross has spoken at
various Internet events for the past five years and has been quoted in a
variety of publications, such as Wired, The New York Times and CNN.com. Ross
was educated at the University of Winnipeg.
FRANK COTTER - V.P. of Network & Operations
Frank joined Tucows on June 3, 1999. Frank has held a number of senior
management positions including VP Business Development at Bell Canada and
President of Rogers @Home. While at Rogers, he was the driving force behind the production of
@Home, heading up the North American leader in the broadband network. In addition, he
has experience in management consulting at Deloitte & Touche, as well as
product development experience at Bell-Northern Research. Currently, at Tucows,
Frank is responsible for overseeing the design, building and operations of the
Tucows global infrastructure. He is also responsible for managing the Web
development team. Other responsibilities include planning, budgeting and
running the Web department. Frank has a BA and MA Electrical Engineering from
Queens University.
DAVID R. KEATING - V.P. Sales and Marketing
David is responsible for the planning, directing and co-ordination of the
marketing and sales divisions of the company. His role is to execute programs
to ensure the profitable growth and expansion of the company's products and services. David brings to Tucows extensive experience in the technological sales and marketing fields. Before joining Tucows, David was the
VP and General Manager of AT&T Canada Solutions where he was responsible
for keeping track of the "Profit and Loss" of the professional
services division of AT&T in Canada and the design and management of
complex client networks and general management of the AT&T customer care.
As the VP of Marketing in the Business Services Group at Sprint Canada, David
was responsible for the strategic planning, product development, product
management, advertising/promotion and development of new business
opportunities. David was a leading force at IBM Canada reaching significant
milestones with the marketing and sales of the IBM PC. As the Brand Manager, he
was responsible for the revenue and profitability of IBM's leading PC brand, monitors and PowerPC offerings. Plus, Dave Keating also had the management of channel strategies, technical support, pricing and promotion
of key PC brands. David holds an Honours B.A. from Queen's University.
MICHAEL COOPERMAN - Chief Financial Officer
Michael Cooperman has over twenty years experience in the financial and general
management field. Most of his background entails working as a senior financial
executive in the technology industry. Currently, Michael is the CFO at
Tucows.com. Prior to joining Tucows, Michael worked at Archer Enterprise
Systems Inc. which is a provider of Sales Force Automation Software. He served
as CEO, President and a member of the Board of a leading provider of content
publishing tools of the Internet and corporate Intranets known as SoftQuad
International Inc. Previously, he spent 8 years as the CFO, Secretary-Treasurer
and as a member of the Board of Directors at Delrina Corporation where he
directed all the financial management and regulatory activities. Delrina
pioneered the development of PC fax software and became a world leader in the
communication software market during this period. Michael was a key part of the
management team that saw Delrina grow over 2800% in revenue. Prior to joining
Delrina, he was VP of Finance at Ingram Software Ltd. Michael holds a Bachelor
of Accounting Sciences Degree from the University of South Africa.
D13.1.7. Staff/employees. Current staff size, demonstrated ability to expand employee base, hiring policy, employee training, space for additional staff.
As noted above, Tucows currently employs 234 and has been hiring at the average rate of _____ new employees every year since 1994. Tucows has a diverse employee base and strictly adheres to equal opportunity hiring practices. Every new employee is put through a rigorous training program that includes orientation, corporate history, direction and structure as well as ongoing skills development and management training. The Company also provides both internal and external training programs for all employees on a continual basis. Further, the Company has a comprehensive benefits package and its compensation arrangements are believed to be at the high end of the spectrum. Each employee is provided with the tools and space required to achieve their objectives and the Company has sufficient premises at its four locations to accommodate its anticipated human resource requirement. That Tucows is a desirable place for employees is evidenced by its industry low turnover rate of 2.4% per annum. To a certain extent this is the result of the development of a corporate culture that encourages and rewards such values as innovation, fun, dedication and personal growth.
D13.1.8. Commercial general liability insurance. Address/include amount of insurance policy, provider of policy, plans for obtaining additional insurance.
Tucows maintains general liability insurance of $5,000,000 (each occurrence and aggregate) provided by Lombard General Insurance Company of Canada. Tucows is committed to ensuring that we have the appropriate insurance policies in place at all times. As the risk profile of the business and corporate revenues increase, Tucows seeks the counsel of our insurance provider to ensure that appropriate coverage is secured. Acting as a registry operator will require Tucows to seek the counsel of ICANN and the insurance provider prior to operational status of the registry.
D13.2. Business plan for the proposed registry operations. This section should present a comprehensive business plan for the proposed registry operations. In addition to providing basic information concerning the viability of the proposed operations, this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the financial and operational aspects of the proposal. At a minimum, factors that should be addressed are:
D13.2.1. Services to be provided. A full description of the registry services to be provided.
Registry Services - drop a sentence in...
D13.2.2. Revenue model. A full description of the revenue model, including rates to be charged for various services.
Registrations, renewals, transfers
Registrar license fees.
D13.2.3. Market. Market definition, size, demand, accessibility.
Sponsoring Organization to provide
D13.2.4. Marketing plan. Advertising, publicity, promotion strategy, advertisement development strategy, relationship with advertising firm. Use of registrars and other marketing channels.
Sponsoring Organization to provide
D13.2.5. Estimated demand for registry services in the new TLD. Projected total demand for registry services in the TLD, effect of projected registration fees, competition. Please provide estimates for at least 10%, 50%, and 90% confidence levels.
Sponsoring Organization to provide
D13.2.6. Resources required to meet demand. Provide a detailed estimate of all resources (financial, technical, staff, physical plant, customer service, etc.) required to meet the estimated demands, using at least the 10%, 50%, and 90% confidence levels.
Tucows already has a substantial investment in infrastructure to meet its current gTLD and ccTLD demand. On an incremental basis, this particular TLD Registry Operation will require only incremental increases in internal resources to ensure a high level of service to both retail and wholesale markets. Specifically, the incremental resources required by category are shown in the charts below, which depict the estimates for each confidence level in the first year of operation*:
Incremental Resources Required
Resource Category |
10% |
50% |
90% |
| Capital Required | |||
| Additional Technical Staffing | |||
| Investment in Capital Assets** | |||
| Customer Service | |||
| Premises (Square Feet) | |||
* Staff and capital assets will be added on a demand basis in each year of operation. The criteria for determining timing is solely based on response time to provide non-automated customer service issues. To ensure that automated responses are instantaneous, Tucows will always have ___ % excess processing power in place than is required at any given time.
** Includes computers (and related equipment), leasehold improvements, furniture and fixtures.
D13.2.7. Plans for acquiring necessary systems and facilities. Describe plans for acquiring all necessary systems and facilities for providing the proposed services at each estimated demand level. Provide details as to the scope, cost, and vendor for any significant planned outsourcing.
Tucows has a well established procurement team that will ensure that all necessary physical assets and facilities are in place. As indicated above, Tucows already has four offices and has the experience and resources required to build its organization to meet anticipated volume of business resulting from the additional registry operations. No significant outsourcing is anticipated at any of the estimated demand levels
D13.2.8. Staff size/expansion capability. Plans for obtaining the necessary staff resources, capacity for expansion, hiring policy, employee training, space for additional staff, staffing levels needed for provision of expanded technical, support, escrow, and registry services.
Sales - 37
Marketing - 54
Technical Development - 49
Network Operations - 16
Administration - 10
Finance - 8
Senior Management - 9
Customer Service - 17
Business Development - 4
Human Resources - 3
Web Design/Content - 28
Tucows has a human resources department that will ensure that the required staff positions are filled as needed. As indicated above, Tucows already has 234 people on board and experiences an industry low attrition rate of 2.4% per annum as a result of its human resource practices and policies. These include comprehensive training, benefits, and compensation plans as well as a corporate culture that values innovation, fun, dedication and personal growth. With its four offices and 25,000 sq ft available for expansion, not to mention the staff already dedicated to the registry business, Tucows is well positioned to handle the increased business resulting from the registry operation.
D13.2.9. Availability of additional management personnel. How will management needs be filled?
As registry operations are not new to Tucows and management is already in place for this purpose, it is not anticipated that additional senior management personnel will be required. However, to the extent that demand exceeds anticipation and managers are required, Tucows has proven adept at identifying and hiring personnel at all levels.
D13.2.10. Term of registry agreement. State assumptions regarding the term of any registry agreement with ICANN or the sponsoring organization. Note that the .com/.net/.org registry agreement has a basic term of four years.
Tucows anticipates signing the standard registry agreement and acknowledges that this has a basic term of four years.
D13.2.11. Expected costs associated with the operation of the proposed registry. Please break down the total estimated operational costs by the sources of the costs for each estimated demand level. Be sure to consider the TLD's share of ICANN's cost recovery needs. (See < http://www.icann.org/en/financials/budget-fy00-01-06jun00.htm#IIIB>.)
The chart below shows the incremental costs associated with the operation of the proposed registry broken down by sources at each estimated demand level. These costs are for the first year only and are expected to increase annually at the rate of ___%:
Incremental Resources Required
|
Expense Category |
10% |
50% |
90% |
| Human Resources | |||
| Marketing | |||
| Capital Assets | |||
| ICANN | |||
| Premises | |||
| Total |
These expenses are detailed in the pro forma financial statements found in Schedule B (not included).
D13.2.12. Expected revenue associated with the operation of the proposed registry. Please show how expected revenue is computed at each estimated demand level.
The chart below shows the incremental revenue associated with the operation of the proposed registry broken down by sources at each estimated demand level. These revenues are for the first year only and are expected to increase annually at the rate of ___%:
Incremental Revenue Projections
|
Revenue Source |
10% |
50% |
90% |
| Retail Registrations | |||
| Wholesale Registrations | |||
| Retail Price/Registration | |||
| Wholesale Price/Registration | |||
| Retail Revenue | |||
| Wholesale Revenue | |||
| Total Revenue |
These revenue projections are detailed in the pro forma financial statements found in Schedule B (not included).
D13.2.13. Capital requirements. Quantify capital requirements in amount and timing and describe how the capital will be obtained. Specify in detail all sources of capital and the cost of that capital (interest, etc.). Evidence of firm commitment of projected capital needs will substantially increase the credibility of the registry operator's proposal.
As indicated above, Tucows anticipates an incremental investment in capital assets of $______. This is broken down as follows based on the anticipated demand levels:
Capital Asset Requirement Projections
|
Capital Assets |
10% |
50% |
90% |
| Personal Computers | |||
| Servers | |||
| Furniture | |||
| Fixtures | |||
| Leasehold Improvements | |||
| Total Capital Assets |
These expense projections are detailed in the pro forma financial statements found in Schedule B (not included).
Tucows is a well funded organization with a demonstrated capability to raised capital when required.
D13.2.14. Business risks and opportunities. Describe upside and downside contingencies you have considered and discuss your plans for addressing them.
Tucows is making this application for registry operator status based on estimates derived from experience and analysis for market demand and market share. Nonetheless, it is possible that demand will exceed expectations, in which case the ownership group has committed to ensuring that the physical and human resources are in place to guarantee the highest possible level of customer service. On the other hand, it is also possible that demand has been greatly over estimated, in which case, Tucows intends to honour its agreements to provide registry services and provided the highest possible level of customer service B regardless of whether this operation provides the anticipated profits.
D13.2.15. Registry failure provisions. Please describe in detail your plans for dealing with the possibility of registry failure.
There are three important elements that must be taken into account to understand Tucows commitment to providing stable, reliable and efficient registry operations and what the philoso phy behind our failure provisions are.
First, all of our systems are based on readily available open-source tools and systems that increase the portability of the associated data-sets, and therefore the registry operation as a whole. We firmly believe that our value as a Registry Operator lie not with the proprietary nature of our systems and tools, but within the value and service that we provide to all of our clientele. Should we cease operation, or our systems are rendered inoperable for an extended period of time, the portability of our systems and data will serve to minimize most technical issues that may arise as a result of having to move a large number of SLD registrations to another Registry Operator's care.
At it's core, the ability to ensure service continuity for an entire TLD requires another entity to continue to provide service where we leave off. Tucows operates in accordance with the principles of "co-opetition". Our operating history has taught us time and time again that working with our competition towards mutually beneficial goals is far more rewarding and profitable for everyone than the obvious corollary. Leveraging these skills and the strength and trust inherent in our existing relationships will be of paramount importance should we cease operations or otherwise be required to fall-back to a disaster recovery situation.
Perhaps most important to answer this question is the large personal stake that the staff and management of Tucows have in ensuring proper TLD continuity. Since founding, Tucows has strived to offer the highest level of customer support and service possible. Historically, this has been the single largest contributing factor to our success, and our recent wins as an accredited registrar bears witness to this fact. As such, there is a large amount of personal reputation tied to the conduct of the company as a corporate and Internet citizen. Failure to ensure proper continuity of the registry will become an indelible and permanent mark on the reputation of the staff, management and executive of the company.
Notwithstanding, Tucows Registry Operations will be adopting the following policies and procedures from our existing business to ensure maximum availability during failure mode.
1. Standard Escalation & Response - a process which outlines precise escalation proce dures that are to be followed in event of emergencies. This will ensure that affected parties are notified as soon as possible and that work is initiated on solving the problem in a timely manner.
2. Catastrophic System Failure Response - which 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.
3. Emergency Response Unit Deployment - a process description which outlines exact steps and methodology which will be followed to deploy a response unit to affected system.
4. Full cooperation and coordination with our partners and other affected parties to ensure any problems are resolved effectively and in a manner deemed suitable to all.
D13.3. Pro-forma financial projections. Please provide detailed pro-forma financial projections, consistent with your business plan, for the demand scenarios that you estimate under item D13.2.5. The pro-formas should show revenue and expense estimates broken down by detailed categories and should be broken down into periods no longer than quarterly.
See attached pro forma financial statements found in Exhibit B (not included) which includes four years of monthly balance sheets, income statements and cash flow projections for each of the three demand scenarios. As well the major assumptions are included in these projections. The balance sheet for first quarter 2000 is attached as Exhibit E.
D13.4. Supporting documentation. The following documentation should be provided in support of the Business Capabilities and Plan section:
D13.4.1. Registry operator's organizational documents. Documents of incorporation (or similar documents).
Documents of incorporation are found in exhibit C (not included).
D13.4.2. References. A list of significant trade and credit references.
A list of trade and credit references is attached as Exhibit D.
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.
Proof of insurance is found in Exhibit F (not included).
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, profes sional-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.
[ICANN will extensively review and analyze this section of the Registry Operator's Proposal. The content, clarity, and professionalism of this section will be important factors in ICANN's evaluation of applications. We strongly recommend that those who are planning to apply secure professional assistance from engineers and/or other technical consultants to aid in the formula tion of the technical plan and the preparation of the Technical Capabilities and Plan section of the Registry Operator's Proposal.]
D15. The Technical Capabilities and Plan section should consist of at least the following:
D15.1. Detailed description of the registry operator's technical capabilities. This should provide a detailed description of the registry operator's technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce, and access to systems development tools. It should also describe the registry operator's significant past achievements. This description offers the registry operator an opportunity to demonstrate the extent of its technical expertise in activities relevant to the operation of the proposed registry.
Technical capabilities can be grouped into two categories: A. Operational capabilities, and B. Development capabilities, these are described separately below.
Operational Capabilities
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 B Director, Operations
Dave has 16 years of experience in technology management, implementation and support. Dave is a graduate of Electronics Engineering Technology from Sheridan College. After working for 4 years in a technology support role for Sheridan College, Dave went on to manage the Operations team for Cancom where he built Canada = s first VSAT satellite 2-way data network. After 9 year = s with Cancom, Dave moved to Alias|Wavefront (an SGI company) for 3 years to lead Alias = worldwide IT department. In March 2000, Dave joined Tucows to oversee the Operations team.
David Antognini B Senior Systems Administrator/Network Architect B 10 yrs exp.
Rob Naccarato B Senior Systems Administrator/Systems Architect B 8 yrs exp.
Denis Achibane B Oracle DBA/Senior Systems Administrator B 15 yrs exp.
Fred Dorre B Production Application Operator B 2 yrs exp.
Yuri Pismerov B Systems Administrator (Unix) B 8 yrs exp.
Adrian Daminato B Systems Administrator (Unix/NT) B 5 yrs exp.
Kevin Rueckert B Systems Administrator (Unix/NT) B 5 yrs exp.
Evan Robinson B Network Operator/Help Desk B 1 yr exp.
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 7x24x365, with a 5 person rotation providing after hours support/monitoring.
Development Capabilities
Personnel:
Tucows development consists of a highly skilled mix of Perl developers and enterprise developers. The Perl developers focus on content and portions of the client side embed ded/distributed components. Enterprise developers focus on those components which execute inside of the transactional framework.
Key Staff, are as follows:
Greg Wier B Senior Perl developer and content architect B 8 yrs exp.
Bruce Miner B Chief Architect B 20 yrs exp.
Eugene Vasile B Director, Development B 11 yrs exp.
Steve Knipe B Architect B 11 yrs exp.
Charles He B Senior Developer B 10 yrs exp.
Frank Thompson B Senior Developer B 6 yrs exp.
Janucz Sienkiewicz B Senior Developer B 5 yrs exp.
Tools :
JDK1.2.2
TogetherJ (Control Centre Edition)
Significant Past Experience
D15.2. Technical plan for the proposed registry operations. This should present a comprehensive technical plan for the proposed registry operations. In addition to providing basic information concerning the operator's proposed technical solution (with appropriate diagrams), this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the technical requirements of registry operation. Factors that should be addressed in the technical plan include:
D15.2.1. General description of proposed facilities and systems. Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe in detail buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.
Locations, buildings, internet connectivity:
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."
This proposal would locate systems in the following Exodus Locations around the world:
North America: Boston, US; Chicago, US; Los Angeles, US; New York. US; Seattle, US; San Francisco, US; Toronto, CA
Europe: Germany, London, UK
Asia/Pacific: Tokyo, JP
The specific systems are described later in this document.
All Exodus locations are high security buildings. Specifically, they have the following features:
- 7x24 security guards
- sign in process where anyone entering facility must be on the A approved @ list, and must show legal photo id to be granted access
- once in the facility, people must use a card key and palm scanner to gain access to the data centre
- the Tucow = s 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 in a fully redundant array
- multiple UPS power units with battery backup
- multiple diesel generators for extended power outages, in a fully redundant array
- Kevlar lined walls for protection against explosion from the out side
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 Tucows office at 96 Mowat Ave., Toronto, Ontario, Canada.
Equipment:
Tucows prime technology vendor is 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 are 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 = s, power supplies, network cables, memory modules (DIMMs).
Operating systems:
Regarding operating system environments, Tucows takes a A best of breed @ approach. Specifically, a combination of Solaris, NT, and Linux, with emphasis on Solaris for high availability applications such as the back end database servers.
Security of intellectual property:
Intellectual property security is addressed in many ways. From an access perspective, Tucows has Firewall = s 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:
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.
OpenXRS Registry Model:
The fundamental building block of the Tucows registry model is the OpenXRS registry. This system implements all functional requirements necessary to implement a gTLD 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 shown below:
Each component in the OpenXRS system (Domains, Registrars, Nameservers), runs on two Sun E450, each with 4 CPU = s, Solaris operating system, and 2 GB of RAM. A load balancer serves requests to components between the two systems. This provides improved performance and fault tolerance.
The OpenXRS registry uses two Oracle database, a primary and a secondary, which are continuously replicated. Each Oracle database runs on a Sun E450, with 4 CPU = s, Solaris operating system, and 2 GB of RAM.
Connections between components and database are done with Fiber channel.
Registry Mirrors:
In order to provide a more robust and scalable model, the registry is operated in a number of locations. Registries are A paired up @ so that they mirror each other = s data. This allows for fail-over and fault tolerance in the case of one of the pairs becoming inaccessible.
In the following diagram which illustrates this principle, location A and location B acts as mirrors of each other. If either location becomes unavailable, the system automati cally switches over to the other member of the pair.
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 A hot @ facility, meaning that it will be the normal full-time registry. The secondary registry facility will be a A cold @ facility, meaning that it will only be activated if problems arise with 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 following diagram illustrates this architecture.
D N S Model:
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 and several DNS servers to handle the requests.
This architecture is illustrated in the following
diagram:
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 = s, Solaris operating system, and 2 GB of RAM.
DNS facility locations:
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;
San Francisco, California, USA;
Chicago, Illinois, USA;
Boston, Massachusetts, USA;
Germany
London, United Kingdom
Tokyo, Japan
The following diagram illustrates these locations.
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.
The following diagram illustrates this architecture:
The centralized whois service uses two Oracle database, a primary and a secondary, which are continuously replicated. Each Oracle database runs on a Sun E450, with 4 CPU = s, Solaris operating system, and 2 GB of RAM.
Connections between the whois server and the database are made with Fiber channel.
D15.2.2. Registry-registrar model and protocol. Please describe in detail.
Tucows supports two registry-registrar models and protocols. First, the NSI RRP protocol, and second, an XML based Registry-Registrar Protocol. Both of these protocols are supported simultaneously, so that either method can be used to access the registry model.
NSI RRP Protocol:
The proposed solution, fully supports the NSI Registry Registrar Protocol (RRP) specification as defined in RFC2832. This specification can be used to handle new gTLD's. The only addition to the protocol that needs to be addressed, is functionality needed to handle the extended (centralized) whois service. This functionality will be added with full input from Registrars as appropriate.
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. This will allow registrar's to leverage the investments they have already made in supporting existing gTLD's, as well as offer them a quick upgrade path to using new gTLD's that are introduced.
XML Registry-Registrar Protocol:
In addition to full support of the RRP protocol specification, the proposed solution also supports and XML based 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 infor mation about a particular domain, nameserver or regis trant.
renew: The renew function (OXRSrenew) is used to delete a particular domain, nameserver or registrant.
See Appendix F to the Afilias Registry Operator's Proposal for specific details and examples on the XML Registry-Registrar Protocol.
D15.2.3. Database capabilities. Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.
Database scalability:
The database is 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 develop ment, 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 capabili ties.
Database throughput:
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.
Functional support:
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 report ing that is required.
D15.2.4. Zone file generation. Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.
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.
D15.2.5. Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them.
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;
San Francisco, California, USA;
Chicago, Illinois, USA;
Boston, Massachusetts, USA;
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.
D15.2.6. Billing and collection systems. Technical characteristics, system security, accessibility.
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 system 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.
D15.2.7. Data escrow and backup. Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.
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. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.
The 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 authorita tive 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, and are hosted in highly secure Exodus locations. Data security is ensured by using strong data encryption where necessary. 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. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.
Physical security:
Physical security is handled by Exodus, where the severs are co-located. These are secure facilities, with 24x7 security guards, video camera surveillance, card key access with palm scanners.
All servers are installed in locked cages within the data centre, these can only be unlocked by security personnel at Exodus.
Internet security:
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 7x24 Operations of any attempted intrusions.
Host security:
All root/super-user accounts have passwords changed regularly. Shell accounts on production servers are kept to an absolute minimum. Secure shell connections are used by Tucows Operations staff to access servers remotely. Any unnecessary services are disabled.
Tucows has A 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.
Disaster recovery:
Tucows will invoke pre-determined and documented disaster recovery procedures should they be required.
Tucows will leverage Exodus = highly redundant infrastructure in event of disaster, as well as having internal business disaster plans in place.
D15.2.10. Peak capacities. Technical capability for handling a larger-than-projected demand for registration or load. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.
The 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.
The backup systems in place will 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 neces sary.
D15.2.11. System reliability. Define, analyze, and quantify quality of service.
The system is designed so that peak load can be scaled across multiple processors and multiple servers using a load balancing algorithm. This offers 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.
D15.2.12. System outage prevention. Procedures for problem detection, redundancy of all systems, back up power supply, facility security, technical security, availability of back up software, operating system, and hardware, system monitoring, technical maintenance staff, server locations.
Redundancy:
Exodus provides a full data centre environment with redundant UPS, redundant air conditioning, and security. All critical data is backed up to tape daily, and stored off site.
Maintenance:
Tucows supports same day maintenance on all servers. As well, Tucows houses spare server components on site.
System Management and Monitoring:
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 7x24 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 7x24.
Technical staff:
Tucows has 7x24 Operations staff, with all member of the Operations 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. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures, the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation, the availability of the hardware needed to restore and run the system, backup electrical power systems, the projected time for restoring the system, the procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.
Well documented procedures are in place for recovering systems from back up tapes should the system suffer a catastrophic failure. The staff who would perform this recovery are skilled System Administrators with several year's experience.
Tucows has a 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.
D15.2.14. Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support, support services to be offered, time availability of support, and language-availability of support.