The Kids' Place on the Web!
Acknowledged.
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
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
Tucows is a corporation organized under the laws of Delaware, United States.
http://www.tucows.com
http://partner.tucows.com
N/A
234
Total Revenue: US$2.834 million for the fiscal year May 4, 1999 through December 31, 1999.
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
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
N/A
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.
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.
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.
- 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.
Tucows is the leading Internet channel management company, providing digital products, applications and services to Managed Service Providers (MSPs) on a global basis. Tucows looks forward to improving the Internet experience for children by working with the sponsoring organization, .KIDS Domains, Inc..
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.
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.
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.
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.
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
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 charge the sponsoring organization, .KIDS Domains, Inc. $4.00 for each of the first 250,000 domain years registered in the .KIDS registry and $3.00 for each domain year, including renewals, registered thereafter. In addition, Tucows will receive $50,000 payable from .KIDS Domains, Inc. subsequent to the grant of a .KIDS license by ICANN in consideration of Tucows prepatory efforts in readying the .KIDS registry. Tucows shall also be paid a monthly operation fee of $5,000.
Sponsoring Organization, .KIDS Domains, Inc has identified the target market as:
1) Children worldwide who use the Internet occasionally or everyday, and who have been born into the potential occasion to become the most educated, enlightened, and successful generation in history as a result of the information opportunity created by the Internet.
2) The parents, grandparents and guardians of those children, who understand the promise and potential power of the Internet in the lives of their children, but who fear the effect on their children of unfiltered exposure to the tremendous amount of inappropriate content that is currently present and readily available online.
3) Family focused businesses and websites that count children as an important part of their community and customer base. Most businesses, because of their ownership of only one branded, recognizable domain must tailor their Internet sites to their adult users. .KIDS Domains intends to allow businesses and site operators to create parallel sites specifically tailored (navigation, content, limitations on personal information requests, etc.) for child users that simultaneously allow the company to fully leverage is brand awareness (i.e. amazon.com and amazon.kids).
The sponsoring organization that we are partnered with, .KIDS Domains, Inc. will be responsible for the marketing of the .kids tld. .KIDS Domains, Inc. has engaged CarryOn Communications of Beverly Hills, California to direct and coordinate its marketing and advertising efforts.
In addition to commercial marketing, .KIDS Domains, Inc. has allocated a significant portion of its budget to the creation and production of Public Service Announcements promoting Internet safety, and education on Internet safety for children and their parents.
Demand for the first and second year (in number of registrations) is estimated with the following confidence levels:
Confidence Level |
Registrations Year 1 |
Registrations Year 2 |
10% |
1,500,000 |
3,045,000 |
50% |
810,000 |
1,847,000 |
90% |
250,000 |
508,000 |
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 |
$3,511 |
$3,511 |
$3,511 |
Capital Assets** |
$17,017 |
$17,017 |
$17,017 |
Compliance Staff*** |
$383 |
$383 |
$383 |
Technical Staffing Costs |
$1,422 |
$1,422 |
$1,422 |
Customer Service Staff |
$647 |
$647 |
$647 |
Total |
$ 22,980 |
$ 22,980 |
$ 22,980 |
* 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.
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
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.
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.
Tucows anticipates signing the standard registry agreement and acknowledges that this has a basic term of four years.
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,173 |
$1,372 |
$384 |
Sponsor** |
$204,222 |
$154,088 |
$35,480 |
Bank Charges |
$1,471 |
$840 |
$256 |
Salaries & Benefits |
$3,776 |
$3,091 |
$1,715 |
Research & Development |
$3,000 |
$2,280 |
$528 |
Capital Assets |
$6,298 |
$6,266 |
$1,861 |
Total |
$220,940 |
$167,937 |
$40,224 |
* These expenses, except for those contained in the ‘Sponsor’ row, are detailed in the pro forma financial statements found in Appendix B.
** The Sponsoring Organization is responsible for Marketing, customer service, billing, and all other expenses associated with .kids tld.
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** |
1,500 |
3,045 |
4,664 |
6,385 |
10% Confidence Level Revenue*** |
$4,800 |
$8,136 |
$13,881 |
$18,156 |
|
|
|
|
|
50% Confidence Level Registrations** |
810 |
1,847 |
2,824 |
3,874 |
50% Confidence Level Revenue*** |
$3,004 |
$5,543 |
$8,463 |
$11,622 |
|
|
|
|
|
90% Confidence Level Registrations** |
250 |
508 |
777 |
1,064 |
90% Confidence Level Revenue*** |
$1,000 |
$1,524 |
$2,334 |
$3,193 |
* These revenue projections are detailed in the pro forma financial statements found in Schedule B.
** Includes new registrations, transfers and renewals.
As indicated above, Tucows anticipates an incremental investment in capital assets of $3,511,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.
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.
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.
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.
See Appendix C.
See Appendix D.
See Appendix E.
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.
See Appendix F.
Technical capabilities can be grouped into two categories: A. Operational capabilities, and B. Development capabilities, these are described separately below.
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.
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)
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.
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.
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 center
- the Tucows cages are locked within the data center, and must be unlocked by security
- the entire facility is monitored by video surveillance
- multiple air conditioning units 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 service 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.
Radware
Multi-Lan will perform all load balancing.
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.
The
database systems are based on a high availability model with a robust and
distributed transaction architecture. The
distributed architecture allows for a very large throughput and data capacity.
The
database uses industry standard methods to facilitate and normalize the
development, deployment and assembling of high performance application
components. These methods are
leveraged to provide a robust and scalable architecture.
The
result is a system that is transactional, database-oriented, multi-user,
secured, and portable. It is
platform and operating system independent.
In addition, since the database components are distributed, this allows
for redundancy and fail-over capabilities.
The
database will handle 230 transactions per second, with sustained levels of 250
transactions per second, and peak levels of 286 transactions per second.
Since
the database will be highly scalable, additional capacity and support for higher
throughput can be added as required.
The database will support all registry actions that are defined in the registry-registrar model and protocol. This includes creation, editing, deletion, change notifications, and registrar transfer procedures.
In addition any grace period requirements will be built into the database manager business logic.
Since the system and database architecture uses components to encapsulate business rules, it can be quickly and efficiently leveraged to provide any level of detailed reporting that is required.
The 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.
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.
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 that 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.
Using strong data encryption where necessary ensures data security.
Access to the physical systems and data is strictly controlled and managed by Tucows.
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.
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.
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 is 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.
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 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 similarly have more than sufficient to handle peak
capacities.
Maintenance
personnel have been allocated based on estimations of average and peak
capacities. Additional resources are not anticipated, but can be quickly added
if necessary.
The
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.
Exodus provides a full data center 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.
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 cannot 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.
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, and 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.
The
following is a detailed description of the XML Registry-registrar protocol.
OXRS uses a standard message format expressed as an XML payload.
“OXRScommand“
is the standard delimiter of an atomic registry server command. As such the
embedded instructions are considered to be atomic in nature. It is used to identify the scope of a logical transaction.
It may represent an atomic physical transaction if sent outside of the
boundary of an “OXRScommand” group. The command body is the actual function
being requested by the client.
Definition:
<OXRScommand>
…
command body …
OXRScommandgroup:
“OXRScommandgroup”
is used to identify a group of commands to be sent to the registry server.
OXRScommandgroup includes one or more OXRScommands as part of its delimited
payload.
Definition:
<OXRScommandgroup>
{<OXRScommandgroupscope>{all,none}</OXRScommandgroupscope>}
{<OXRScommandgroupreturn>{isolated,
list, none}</OXRScommandgroupreturn>}
{<OXRScommandgroupsequence>{on,
off}</OXRScommandgroupsequence>}
<OXRScommand>
…command
body…
</OXRScommand>
<OXRScommand>
…command body…
</OXRScommand>
</OXRScommandgroup>
“OXRScommandgroupscope”
identifies the atomicity of the execution of any updates invoked by
OXRScommandgroup.
all:
Specifying
“all” as OXRScommandgroupscope directs OXRS to treat all of the contained
OXRScommands as a single unit of work.
none:
Specifying
“none” as OXRScommandgroupscope directs OXRS
to treat each of the contained OXRScommands as an isolated unit of work.
The
OXRScommandgroupreturn identifies the atomicity of the response to any
OXRScommandgroup.
isolated:
Specifying
“isolated” as OXRScommandgroupreturn directs OXRS to treat all of the
contained OXRScommands as a isolated requests and as such send a response for
each command as soon as the OXRScommand is completed. Important Note: If the
OXRScommandgroupscope is set to all, then the “isolated” option if specified
is overridden with “list”.
list:
Specifying
“list” as OXRScommandgroupreturn directs OXRS to treat all of the contained
OXRScommands as a group of requests and as such send a single for the group as
soon as the OXRScommand is completed for the entire group. To retain
request/response context one of the following should take place:
Either:
The OXRScommandgroup sequence should be set “on” such that the sequence of
response is equal to the sequence of request arrivals.
Or:
The original request is returned as part of the response to allow client
applications to process the results.
none:
Specifying
“none” as OXRScommandgroupreuturn directs OXRS
to not send any response to the request. (i.e
none is needed).
OXRScommandgroupsequence:
on:
Specifying
“on” for the OXRScommandgroupsequence indicates that the requests should be
processed in the order of arrival and that a sequence identifier should be
attached to each of the requests (and responses).
off:
Specifying
“off” for the OXRScommandgroupsequence indicates that the requests should be
processed any order, regardless of the order of arrival. In this mode a unique
identifier (either user supplied or system generated) to enable the matching of
the request response pairs.
The
OXRSadd function is used to add resources such as domains, nameserver and
registrants to OXRS . The OXRSadd function is typed by the
type of resource being added.
Description:
<OXRScommand>
<commandtype>OXRSadd:{domain, nameserver, registrar}</commandtype>
… res1add command body …
</OXRScommand>
It
should be mandatory to add the name server at the time of registering the domain
The
syntax should express a consistent format for dates and number of years, time
period
<OXRScommand>
<commandtype>OXRSadd:domain</commandtype>
<domainname>…
domain name … </domainname>
<sequence:ns>
<seq>…
name server sequence …</seq>
<name>…
name server name …</name>
</sequence>
</OXRScommand>
<OXRScommand>
<commandtype>OXRSadd:domain</commandtype>
<domainname>mydomain.com</domainname>
<sequence:ns>
<seq>1</seq>
<name>ns1.mydomainns.com</name>
</sequence>
</OXRScommand>
<OXRScommand>
<commandtype>OXRSadd:nameserver</commandtype>
<sequence:ns>
<seq> … name server sequence </seq>
<name>
… name server name </name>
<ip>
… name server ip address …</ip>
</sequence>
</OXRScommand>
<OXRScommand>
<commandtype>OXRSadd:nameserver</commandtype>
<sequence:ns>
<seq>1</seq>
<name>ns1.myns1.com</name>
<ip>111.222.111.1</ip>
<seq>2</seq>
<name>ns2.myns2.com</name>
<ip>111.222.111.2</ip>
</sequence>
OXRSadd
registrar syntax:
<OXRScommand>
<commandtype>OXRSadd:registrar</commandtype>
<registrarid>
… unique registrar identifier … </registrarid>
<registrarname>
… registrar name … </registrarname>
<registrarpwd>
… registrars pwd … </registrarpwd>
</OXRScommand>
<OXRScommand>
<commandtype>OXRSadd:registrar</commandtype>
<registrarid>
12345 </registrarid>
<registrarname>
my registrar </registrarname>
<registrarpwd>
rover </registrarpwd>
</OXRScommand>
There
should be no limit on the maximum ratios of nameservers to edit for on the
initial release.
Overview:
The
OXRSverify function is used to verify the existence of a particular domain.
Need
to determine the need for sequencing for the domain name “verifies”.
<OXRScommand>
<commandtype>OXRSverify:domain</commandtype>
<sequence:domain>
<seq> name sequence </seq>
<name>
… domain name </name>
</sequence>
</OXRScommand>
OXRSverify
single domain example:
<OXRScommand>
<commandtype>OXRSverify:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
</sequence>
</OXRScommand>
OXRSverify
multiple domains example:
<OXRScommand>
<commandtype>OXRSverify:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
<seq>2</seq>
<name>myotherdomain.com</name>
</sequence>
</OXRScommand>
The
OXRSdelete function is used to delete a particular domain, nameserver or
registrant.
<OXRScommand>
<commandtype>OXRSdelete:domain</commandtype>
<sequence:domain>
<seq> name sequence </seq>
<name>
… domain name </name>
</sequence>
</OXRScommand>
OXRSdelete
single domain example:
<OXRScommand>
<commandtype>OXRSdelete:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
</sequence>
OXRSdelete
multiple domains example:
<OXRScommand>
<commandtype>OXRSdelete:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
<seq>2</seq>
<name>myotherdomain.com</name>
</sequence>
The
OXRSversion function is used to determine the version of a particular
OXRSversion executing.
The
OXRSupdate function is used to update information about a particular domain,
nameserver or registrant.
<OXRScommand>
<commandtype>OXRSupdate:domain</commandtype>
<sequence:domain>
<seq> name sequence </seq>
<name>
… domain name </name>
</sequence>
</OXRScommand>
OXRSupdate
single domain example:
<OXRScommand>
<commandtype>OXRSupdate:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
</sequence>
OXRSupdate
multiple domains example:
<OXRScommand>
<commandtype>OXRSupdate:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
<seq>2</seq>
<name>myotherdomain.com</name>
</sequence>
</OXRScommand>
The
OXRSrenew function is used to delete a particular domain, nameserver or
registrant.
The
contact information that we keep about a particular name server or registrant
may also need to be renewed.
Need
to add syntax to identify the number of years as part of the renewal information
<OXRScommand>
<commandtype>OXRSrenew:domain</commandtype>
<sequence:domain>
<seq> name sequence </seq>
<name>
… domain name </name>
</sequence>
</OXRScommand>
OXRSrenew
single domain example:
<OXRScommand>
<commandtype>OXRSrenew:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
</sequence>
OXRSrenew
multiple domains example:
<OXRScommand>
<commandtype>OXRSrenew:domain</commandtype>
<sequence:domain>
<seq>1</seq>
<name>mydomain.com</name>
<seq>2</seq>
<name>myotherdomain.com</name>
</sequence>
</OXRScommand>