Registry Operator's Proposal

 

 

 

I. GENERAL INFORMATION

 

 

D1. Acknowledged.

 

D2.          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

ross@tucows.com

 

D3.          Flint, Michigan

G-3255 Beecher Rd. Suite 100
Flint, Michigan 48532
– Editorial, Author Relations, Content Development

 

Toronto, Canada

96 Mowat Avenue

Toronto, Ontario

- Sales, Marketing, Administration

 

 

D4. Tucows is a corporation organized under the laws of Delaware, United States.

 

D5.          http://www.tucows.com

http://partner.tucows.com

 

 

D6. N/A

 

D7. 234

 

 

D8. Total Revenue: US$2.834 million for the fiscal year May 4, 1999 through December 31, 1999.

 

 

D9. 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.        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

ross@tucows.com

 

 

D11. N/A

 

II. BUSINESS CAPABILITIES AND PLAN

 

 

D13.1.1. 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, MI, 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:

 

§         Critical Path, Inc.  - Selected as the primary supplier of Internet messaging products and services to Tucows business partners.

§         Exodus - Tucows has a co-marketing alliance with Exodus that leverages our complementary product offerings to leading Internet businesses.

§         CAIP - Tucows is an associate member of the Canadian Association of Internet Providers.

§         USIIA - Tucows is a Vendor member of the US Internet Industry Association.

§         ISPBF - Tucows is an associate member of the Internet Service Providers Business Forum.

§         ISP/C - Tucows is a vendor sponsor of the Internet Service Providers Consortium.

§         CIRA - Tucows is an official certified Canadian Internet Registration Authority Registrar.

§         Nominet - Tucows is an official Nominet tag-holder (registrar).

§         ICANN - Tucows is an official ICANN accredited Registrar.

§         CORE - Tucows is a founding member of the Council of Internet Registrars.

§         RISC - Tucows is a founding member of the Responsible Internet Service Companies.

§         ZDNet - Tucows has been selected by ZDNet as the primary supplier of domain name registration services to ZD's clients.

§         Excite@Home Canada - Tucows has been selected by Excite as the primary supplier of domain name registration services to Excite's clients.

§         Go2Net.com - Tucows has been selected by Go2Net as the primary supplier of domain name registration services to Go2net's network of 16 web site properties.

 

Tucows works closely with most software companies around the world that distribute their products via the Internet.  Tucows is a leading distributor of e-business services and applications on the Internet. With a network of more than 4,000 Internet Service Providers, Web hosting companies and Domain Name Resellers in more than 100 countries around the world, we believe Tucows to be the largest network of its kind.  The Tucows site offers over 30,000 software titles in libraries located around the world, providing users with a fast local download.  Tucows Inc. is an ICANN accredited registrar and the leading provider of wholesale domain name registrations and related services.  Trade references can be found in section 13.4.2 of this document.

 

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.

 

D13.1.2. 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, a simple, reliable rating system, editorial resources, and software download libraries 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 its Registration Service Providers with a comprehensive, open source, private label  registration solution. 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 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. 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 1996,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 through 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 Ltd.

 

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 infrastructure that enables the company's resellers to maintain their own pricing structures and relationships with their clients, the registrants. 

 

Chronologically;

·         Tucows has continuously provided content distribution services since 1994.

·         Tucows (via Internet Direct Inc.) has continuously provided webhosting, Internet access, e-commerce and co-location services since 1994.

·         Tucows has continuously provided retail domain name registration services via Tucows Domain Direct since 1997.

·         Tucows launched it's Registry Operations and Management group in October, 1999 when we commenced consultation and design with various country code registries and potential gTLD registry operators.

·         Tucows has continuously provided wholesale domain name registration services as an ICANN Accredited Registrar since January 2000.

 

 

D13.1.4.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 the registry back-end for the fictional ".moo" TLD, this service has provided demonstration registrations to over 200,000 participants 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 management technologies. Tucows is currently in the final stages of negotiations with various countries to provide them with technology and management services for their country code registry, centering around the OpenXRS platform.

 

 

D13.1.5. 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 are central to the operation of the Internet, and 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 introduce service enhancements and new services in accordance with these principles.

 

 

D13.1.6. Management Overview:

 

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, 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 lead Tucows through an acquisition by Steinmetz Technology Holding International resulting in a change to Tucows.com Inc.  He was 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 developing 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 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 comprehensive provider of domain name registration and related services. At Tucows, Ross creates the business plan and guides the strategy and  direction of Tucows OpenSRS (Open Shared Registration System), Domain Direct and the recently formed Registry Operations Group. 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.

 

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. At Tucows, Frank oversees the design, building and operations of the Tucows global infrastructure and manages the Web development team. 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 managed 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 led 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 accountable 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. 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. As noted above, Tucows currently employs 234 staff, a number that has been consistently growing since its founding. 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.  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 two locations to accommodate its anticipated human resource requirement through 2000, however the firm is currently negotiating for additional office facilities in Toronto and Flint to accommodate growth through 2001/2002.  As is evidenced by its industry low turnover rate of 2.4% per annum, Tucows is a desirable place for employees.  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. 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.1. Tucows provides a variety of Registry Operations services including, but certainly not limited to;

 

§         Shared Registrar Interface support

§         Registration Services (add, renew, transfer, delete, modify)

§         Registrar Support services

§         gTLD DNS services

§         Policy enforcement and compliance

§         Registry systems maintenance and development

§         Billing and collections

 

D13.2.2. Tucows has adopted a subscription based renewal model based on the per year transaction fees collected for domain name registrations within the TLD. Tucows will be charging Registrars $6.00 per registration per year for  new registrations, registration renewals and registrar transfers. License and setup fees will also be collected from Registrars as they enter into agreements with the Registry Operator to sell the gTLD to their clients. Tucows anticipates that this will be a one-time $3,000.00 fee.

 

D13.2.3. –D.13.2.5. See section C12. of the Sponsoring Organization Proposal and the Business Plan Summary, Attachment 7 to the Sponsoring Organization’s Proposal.

 

 

D13.2.6. Tucows already has a substantial investment in infrastructure to meet its current gTLD and ccTLD demand.  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 requested. It is important to note that Tucows' planning model assumes maximum requirements regardless of volume, hence the expenditures will remain the same at all confidence levels*:

 

Incremental Resources Required (in thousands)*

 

Resource Category

10%

50%

90%

Capital Investment

$411

$411

$411

Capital Assets**

$1,511

$1,511

$1,511

Compliance Staff***

$383

$383

$383

Technical Staffing Costs

$882

$882

$882

Customer Service Staff

$343

$343

$343

Total

$3,530

$3,530

$3,530

 

* This chart details the dollar value of each resource category - the staffing requirements may be found in the detailed pro forma projections found in Appendix B.

 

** See Technical Plan and Related Appendices for details of the technical infrastructure to be built.

 

*** Does not include benefits and bonuses which can be expected to be 25% of compensation.

 

D13.2.7. 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. Current staffing levels:

 

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

27

Total

234

 

 

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. 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.  Tucows anticipates signing the standard registry agreement and acknowledges that this has a basic term of four years.

 

D13.2.11. The chart below shows the major costs associated with the operation of the proposed registry broken down by sources at each estimated demand level for the first four years of operations.

 

Expected Costs (in thousands)

 

Expense Category

10%

50%

90%

ICANN

$2,220

$1,776

$1,332

Sponsor**

$22,253

$17,806

$13,350

Bank Charges

$1,277

$1,025

$771

Salaries & Benefits

$2,010

$2,010

$2,010

Research & Development

$660

$660

$660

Capital Assets

$1,511

$1,511

$1,511

Total

$29,931

$24,788

$19,634

 

* These expenses are detailed in the pro forma financial statements found in Appendix B.

** The Sponsoring Organization is responsible for Marketing.

 

D13.2.12. The chart below shows the incremental revenue associated with the operation of the proposed registry broken down by sources at each estimated demand level. 

 

Incremental Revenue Projections (in thousands)*

 

Revenue Source

Year 1

Year 2

Year 3

Year 4

10% Confidence Level Registrations**

$4,619

$8,468

$11,753

$14,459

10% Confidence Level Revenue***

750

1,523

2,332

3,193

 

 

 

 

 

50% Confidence Level Registrations**

600

1,218

1,866

2,554

50% Confidence Level Revenue***

$3,717

$6,794

$9,422

$11,587

 

 

 

 

 

90% Confidence Level Registrations**

450

918

1,399

1,915

90% Confidence Level Revenue***

$2,819

$5,118

$7,088

$8,711

 

* These revenue projections are detailed in the pro forma financial statements found in Schedule B.

** Includes new registrations, transfers and renewals.

*** Includes one-time fees from registrars.

 

D13.2.13. As indicated above, Tucows anticipates an incremental investment in capital assets of $411,000 regardless of the confidence level, which will be funded from cash on hand (see Financial Statements in Appendix C). Should additional capital be required, Tucows has a demonstrated capability to raised capital.

 

D13.2.14. 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 – regardless of whether this operation provides the anticipated profits.

 

D13.2.15. There are three important elements that must be taken into account to understand Tucows commitment to providing stable, reliable and efficient registry operations. These elements also reflect our philosophy concerning failure mode planning and execution.

 

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 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.

 

The ability to ensure service continuity for an entire TLD requires a plan to ensure another entity can continue to provide service should we cease operations. 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 than the simplistic competition. 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 fallback to a disaster recovery situation.

 

The third, and perhaps most important to element is the personal commitment of the staff and management of Tucows to ensure proper TLD continuity. Since its 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 proves this. 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 that outlines precise escalation procedures 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 that 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 that outlines exact steps and methodology that 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. See attached pro forma financial statements found in Appendix B.  These include balance sheets, income statements, cash flow projections and related schedules for each of the three demand scenarios for the first four years of operations, summarized annually and detailed by month. As well, the major assumptions are included in these projections.

 

D13.4.1. See Appendix C.

 

D13.4.2. See Appendix D.

 

D13.4.3. See Appendix E.

 

D13.4.4. Tucows intends to fund these efforts through cash flow and existing reserves. Please see Appendix E for more details. If incremental investment is required, Tucows will be able to raise the requisite funds from existing shareholders.

 

D13.4.5. See Appendix F.

 

 

III. TECHNICAL CAPABILITIES AND PLAN

 

D15.1. 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 – 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 four years in a technology support role for Sheridan College, Dave managed the Operations team for Cancom where he built Canada’a first VSAT satellite 2-way data network.  After 9 year’s with Cancom, Dave moved to Alias|Wavefront (an SGI company) for three years to lead Alias’ worldwide IT department.  In March 2000, Dave joined Tucows to oversee the Operations team.

 

David Antognini – Senior Systems Administrator/Network Architect – 10 yrs exp.

 

Rob Naccarato – Senior Systems Administrator/Systems Architect – 8 yrs exp.

 

Denis Achibane – Oracle DBA/Senior Systems Administrator – 15 yrs exp.

 

Fred Dorre – Production Application Operator – 2 yrs exp.

 

Yuri Pismerov – Systems Administrator (Unix) – 8 yrs exp.

 

Adrian Daminato – Systems Administrator (Unix/NT) – 5 yrs exp.

 

Kevin Rueckert – Systems Administrator (Unix/NT) – 5 yrs exp.

 

Evan Robinson – Network Operator/Help Desk – 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 five person rotation providing after hours support/monitoring.

 

Development Capabilities

 

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 which 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 yrs exp.

 

Bruce Miner – Chief Architect – 20 yrs exp.

 

Steve Knipe – Architect – 11 yrs exp.

 

Janusz Sienkiewicz – Senior Developer – 5 yrs exp.

 

Frank Thompson – Senior Developer – 6 yrs exp.

 

Charles He – Senior Developer – 10 yrs exp.

 

 

Tools:

 

JDK1.2.2

TogetherJ (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:

 

1994 - the fledging team built and launched the first wide-area, IP-based pizza order and delivery system for a Toronto based franchise.

 

1994 - the team created the client/server technology and protocols required to conduct a political leaders debates for a provincial election via the Internet. This was the first time an effort of this nature had been successfully undertaken.

 

1995/6 - the team created and launched an automated version of the content mirroring system in use by Tucows at the time. The system was responsible for monitoring and synchronizing content between the existing Tucows content mirrors located at various data centers around the globe. This was the first implementation of automated content mirror via the World Wide Web.

 

1997 - the team created and launched Domain Direct, an automated domain name registration service that resold the registration products offered by Network Solutions. This launch predated competitive offerings by up to a year.

 

October, 1999 - the team completed design and coding of OpenSRS, the industries first open-source based domain name registration service. Including complete CRM and billing functionality, the system allowed business partners to purchase domain name registrations on a wholesale basis, a capability not available at that point in time.

 

August, 2000 - the team completed and launched OpenXRS, a registry management and operations platform leveraging the core capabilities of the OpenSRS system.

 

D15.2.1. 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; Silicon Valley, US; Toronto, CA

 

Europe:                  Hamburg, 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 “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 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 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 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’s, 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’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 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 the diagram “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 are 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 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 best illustrated by the following diagram:

 

 

 

 

Each component in the OpenXRS system (Domains, Registrars, Nameservers), runs on a Sun E450, each with 2 CPU’s, 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’s, 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’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 automatically 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 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.

 

The following diagram illustrates the registry facilities and how they are interconnected.

 

 

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 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, 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

 

 

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 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’s, Solaris operating system, 8 GB of RAM, and 8x72GB 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 8x72GB RAID drives.

 

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

 

D15.2.2. Tucows 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 exiting 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 A for specific details and examples on the XML Registry-Registrar Protocol.

 

D15.2.3.  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.

 

D15.2.4.  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. 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

 

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. 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. 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. 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 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. 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 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.

 

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’ highly redundant infrastructure in event of disaster, as well as having internal business disaster plans in place.

 

D15.2.10. 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 forseen in handling extremely large capacities. 

 

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.

 

D15.2.11. 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.

 

D15.2.12. 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.

 

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 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.

 

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. 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’s 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.

 

D15.2.14. Technical support will be offered to registrars, Internet users and registrants. 

 

TUCOWS will leverage its existing comprehensive customer support services which are used today to support the successful OpenSRS service.

 

Support services will consist of web based help, telephone support, and email support.  These are described below.

 

The web based help will make use of an online Frequently Asked Questions list (FAQ), and publicly accessible online (web-based) discussion lists.

 

Telephone support will be offered 24x7 via specific dedicated support phone numbers. In addition, support will be offered by fax using a specific dedicated fax number.  All phone numbers will be internationally accessible.

 

Email support will be offered via a specific support email address, and this will be managed 24x7.  Several email addresses will be established for varying levels of severity.  This will allow email support to be managed effectively, while allowing serious issues to be handled quickly.

 

Telephone support, fax support, and email support will be offered in multiple languages, including but not limited to: English, French, Spanish, German. Additional language support will be added as needed.

 

All support services will operate using a tier method for directing and managing support.  Clearly defined escalation procedures exist to resolve difficult questions, and deal with customer satisfaction.

 

TUCOWS is serious about supporting the registry system and committed to a high level of customer satisfaction.