III. TECHNICAL CAPABILITIES AND PLAN

D14. The third section of the Registry Operator's Proposal is a description of the registry operator's Technical Capabilities and Plan. This section must include a comprehensive, professional-quality technical plan that provides a detailed description of the registry operator's current technical capabilities as well as a full description of the operator's proposed technical solution for establishing and operating all aspects of the registry. The technical plan will require detailed, specific information regarding the technical capabilities of the proposed registry. The topics listed below are representative of the type of subjects that will be covered in the Technical Capabilities and Plan section of the Registry Operator's Proposal.

Executive Summary

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

III. TECHNICAL CAPABILITIES AND PLAN

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

D15.2. Technical plan for the proposed registry operations.

D15.2.1. General description of proposed facilities and systems:

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

D15.2.3. Database capabilities:

D15.2.4. Zone file generation:

D15.2.5. Zone file distribution and publication:

D15.2.6. Billing and collection systems:

D15.2.7. Data escrow and backup:

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

D15.2.9. System security:

D15.2.10. Peak capacities:

D15.2.11. System reliability:

D15.2.12. System outage prevention:

D15.2.13. System recovery procedures:

D15.2.14. Technical and other support:

D15.3 Subcontractors.

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

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

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

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

Richard A. S. Lindsay

interQ Inc.

13 years experience

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

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

Eric R. Schaetzlein

Schlund+Partner AG

7 years experience

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

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

Peter Eisenhauer

Schlund+Partner AG

6 years experience

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

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

Peter Chow

interQ Inc.

8 years experience

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

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

John Wong

Domain Registration Services

18 years experience

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

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

Chris Kruk

DomainPeople

15 years experience

Chris Kruk joined NetNation, DomainPeople's parent company in 1997 with12 years of computer experience as an instructor and a programmer. As one of the first members of the Domain Registration department, Mr. Kruk has more than 3 years of experience in both the global and the country-code domain registration industries. Chris continues to contribute to DomainPeople's product and business development divisions with innovative and unique systems related to the domain name registration industry.

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

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

Operational Capabilities

1. Personnel

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

David Sutton

Director, Operations

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

David Antognini

Senior Systems Administrator/Network Architect

10 years' experience

Rob Naccarato

Senior Systems Administrator/Systems Architect

8 years experience

Denis Achibane

Oracle DBA/Senior Systems Administrator

15 years experience

Fred Dorre

Production Application Operator

2 years experience

Yuri Pismerov

Systems Administrator (Unix)

8 years experience

Adrian Daminato

Systems Administrator (Unix/NT)

5 years experience

Kevin Rueckert

Systems Administrator (Unix/NT)

5 years experience

Evan Robinson

Network Operator/Help Desk

1 year experience

2. Tools

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

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

Development Capabilities

1. Personnel

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

Eugene Vasile

Director, Development

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

Greg Wier

Senior Perl developer and content architect

8 years' experience

Bruce Miner

Chief Architect

20 years' experience

Steve Knipe

Architect

11 years' experience

Charles He

Senior Developer

10 years' experience

Frank Thompson

Senior Developer

6 years' experience

Janusz Sienkiewicz

Senior Developer

5 years' experience

2. Tools

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

Technical Achievements

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

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

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

Significant Past Accomplishments

D15.2. Technical plan for the proposed registry operations.

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

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

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

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

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

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

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

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

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

D15.2.1. General description of proposed facilities and systems:

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

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

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

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

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

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

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

North America: Boston, US; Chicago, US; Los Angeles, US; New York, US; Seattle, US; Silicon Valley, US; Toronto, Canada

Europe: Hamburg, Germany, London, UK

Asia/Pacific: Tokyo, Japan

The specific systems are described in Section D15.2.8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[INSERT 2000 HERE]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[INSERT 2001 HERE]

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

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

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

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

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

[INSERT 2002 HERE]

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

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

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

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

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

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

[INSERT 2003 HERE]

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

[INSERT 2004 HERE]

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

The following geographic areas will be used:

Toronto, Ontario, Canada;

Seattle, Washington, USA;

Silicon Valley, California, USA;

Chicago, Illinois, USA;

Boston, Massachusetts, USA;

Hamburg, Germany

London, United Kingdom

Tokyo, Japan

Diagram 6 illustrates these locations.

[INSERT 2005 HERE]

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

[INSERT 2006 HERE]

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

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

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

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

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

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

[INSERT 2007 HERE]

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

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

Data Management

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

[INSERT 2008 HERE]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The model supports the following registry transactions:

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

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

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

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

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

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

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

D15.2.3. Database capabilities:

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

[INSERT 2009 HERE]

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

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

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

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

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

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

D15.2.4. Zone file generation:

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

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

The generation schedules will be publicly documented.

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

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

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

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

D15.2.5. Zone file distribution and publication

Distribution

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

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

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

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

Publication

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

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

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

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

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

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

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

D15.2.6. Billing and collection systems:

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

Support from Tucows

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

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

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

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

Critical Requirements

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

• The Registry's TLD services will only be offered to customers who are operational ICANN accredited registrars.

• The RRP will track all activities and commands executed, and will pass logging to the billing and management system. The billing system will have to determine which of these sessions are billable or not.

• All domains registration service charge payments will be drawn from the respective customer's established debit account on a per transaction basis.

• Registry "fee incurring" services will be processed only if a positive balance is maintained in a registrar's debit account.

• The system must fully support only one currency. It is recommended that the currency be USD however another currency system could certainly be considered.

• Good query capabilities of the registry operators database will be accessible through an API.

• Mass changes of certain information will be supported.

• The application must have capabilities to track and report historical information. The following information should be tracked: transactions (invoice, collections, adjustments), catalog changes, and customer changes.

• Changes to posted transactions (e.g., invoices or collections) are not allowed. A new transaction must be created to adjust or reverse the original transaction. The cumulative result of both transactions will give the desired result. References among transactions must be tracked.

• Access to certain functions by external systems and users should be available through an API, in addition to a GUI client for the Billing System. The purpose of the API is to expose certain billing functionality to external systems. External systems may perform specific functionality, e.g., domain registration, accounting system entries, and email processes. The API will also provide extension and customization of billing functionality.

Non-Critical General Requirements

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

• Support for flexible Company Structure. Particularly, there will be one top-level company - Registrar Consortium, which has unique Information and, distinct functionality. In this document, (RC) and (ER) annotations indicate whether the particular functionality should be supported only for the Registrar Consortium or any external registry respectively.

• User access defined at the database Record-level: Access to certain records of data should be restricted based on User or User group. Example: support personnel have access only to view customer information and billing clerks have ability to modify customer information.

• Ability to have all functionality accessible through an API.

• Ability to have some of the functionality accessible through the Web (browser) Interface.

Organization Structure

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

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

User Roles

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

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

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

Pricing Rules

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

Additional Information and Provisioning Information

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

Summary

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

1. Registrar submits registration

2. Provider debits account

3. Consolidated statement sent to Registry

4. Send invoice

5. Pay to registry

6. Account update

[INSERT 2010 HERE]

Domain Registration Services

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

• Domain Registration: A registration term from one up to 10 years in total can be specified for new domain registrations. There will be a 5 day grace period to cancel a registration which will trigger a refunds to the registrar.

• Domain Renewal: Renewal of the domain registration will not result in a registration term longer than the maximum allowable term. Registrar requested renewals can be processed at anytime. The registry will automatically renew registrations by 1 year when domain registrations expire. Registrars shall have a 45 day grace period in which to cancel automatic renewal. If a registrar cancels an automatic renewal there will be a 5 day grace period during which the registrar can reinstate the registration. During this grace period the domain is effectively placed on hold. If the registration is not reinstated a refund will be issue to the registrar.

• Registrar Transfer: The domain will be registered for one additional year, for which the gaining registrar will be charged.

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

• Monthly Account Statements: A detailed monthly transaction statement will be emailed to each customer. The statement will include: Account Summary, Balance Forward, Payments Received, Credits/Adjustments, Detailed list of all fee incurring charges, New Registrations, Registration Renewals, Registrar Transfers

• Online Billing Reports: Various billing related reports accessible via real time online interface

• Email notification will be sent for low account balance, insufficient funds, and to provide balance forecasting

Pricing rates will be defined by the Registrars' Consortium.

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

Billing

The following Customer Types are defined for billing purposes:

Direct Customer

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

External Registry

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

External Registry Customer

A customer of an ER.

Payment Method Types

The registry will accept payments by the following methods:

Wire transfer

Any service charges should be the responsibility of the customer.

Debit account

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

Customer Notifications and Reports

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

Functionality and Process Flows

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

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

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

1. Contract phase: The registrar completes all contractual documents directly with registry in order to begin the operational tract.

2. Command to issue software: Registry instructs the provider to release the RRP Software and registrar tool kit to the registrar. Account is set up on the registry database, entered as "test" status.

3. OT&E test suite: The provider issues the software and supporting tool kit, and conducts the operational test suite with the registrar.

4. Positive test results: Provider gives immediate feedback directly to the registrar of the status; when the results are positive, the registrar is considered to have passed the tests.

5. Report of test: Provider reports to the registry that the registrar has successfully completed the test suite.

6. Account setup: The registrar now sets up the financial accounts in order to guarantee prepayment of domain names. Typically, an amount equivalent to the volume of registrations is put into an account accessible by the registry.

7. Go live command: Upon confirmation of the registrar account setup, the registry will issue a command to the provider directing them to change the status of the registrar from "test" status to "active" status, and indicates the amount of the credits that should be entered into the registrar's online account. Simultaneously, the registry issues the notification to the registrar that it has been put into active status, and that it can begin registering domain names.

[INSERT 2011 HERE]

Transactional Services

The following services will trigger billing events through an API:

Add Domain

• Customer issues request to register new domain for a specified number of years

• Required fee calculation: yearly fee X requested term

• Debit account balance checked to verify required fees

• Domain registered

• Required transaction fees drawn from customer's account

Cancel Domain

• Customer issues request to cancel registration

• Registration is canceled

• System verifies time of request is within 5 day grace period

• Customer's debit account credited the total transaction fee

Automatic Renew Domain

• The system will automatically issue a request to renew a domain for one year if the customer has not issued a request to renew or cancel.

• Required fee calculation: yearly fee X 1

• Debit account balance checked to verify required fees

• Domain renewed for one year

• Required transaction fees drawn from customer's account

Customer Requested Renew Domain

• Customer issues request to renew domain for a specified number of years

• Required fee calculation: yearly fee X requested term (requested term adjusted if resulting registration renewal term exceeds 10 years)

• Debit account balance checked to verify required fees

• Domain renewed

• Required transaction fees drawn from customer's account

Customer Requested Cancellation of Automatic Renew

• Customer issues request to cancel registration renewal

• Registration is canceled

• System verifies time of request is within 45 day grace period

• Customer's debit account credited the total transaction fee

Registrar Transfer

• Customer issues request to transfer domain registrar

• Required fee calculation: yearly fee X 1

• Debit account balance checked to verify required fees

• Domain transferred and 1 year added to registration term (not to exceed 10 years)

• Required transaction fees drawn from customer's account

Billing Customer Support

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

D15.2.7. Data escrow and backup:

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

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

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

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

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

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

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

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

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

The information available through the registry Whois database will include:

• Registrant contact information, including names, postal and e-mail addresses and telephone numbers of technical, administrative and billing contacts;

• Registration status and the registration's expiration date.

• The date the registration issued for the domain name;

• Registrar contact information, including name, postal and e-mail addresses, home page, and telephone number;

• Registrar status, including whether the registrar is in good standing with the Company; and

• Technical information about the domain name, including information about the nameserver and IP address.

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

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

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

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

Technical Specifications

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

Lookup Keys

A query for any domain name should contain information about:

• Domain name

• Registration status: available|registered|error (Examples of errors include bad syntax, TLD not sponsored by registry)

• Domain status: hold, lock, transfer_in_process, etc.

• Current registrar

• Both the full name and the lookup key (id/short name):

• Current registrar's Whois servers (see 1.4.1)

• Associated nameservers and their IP addresses where applicable

• Time stamps: registration date, date of last update, expiry date, etc.

A query for a nameserver should contain the following information:

• Nameserver host name

• Nameserver IP addresses if applicable

• Current registrar if applicable

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

A query for a registrar should contain information about:

• Registrar name, postal address

• Whois servers (see 1.4.1)

• Registrar's status (e.g., OT&E, operational)

• Contacts

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

• Administrative contact

• General customer support

• Billing support

• Contact for registrar transfer handling, etc.

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

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

• Full name

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

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

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

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

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

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

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

D15.2.9. System security:

Physical Security

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

• 24/7 on-site security personnel and security monitoring

• Surveillance cameras

• Controlled access to the data center floor through man traps

• se of biometric identification systems

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

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

Network Security

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

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

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

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

Server Security

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

• Disabling all unnecessary services and processes

• Regular application of security-related patches to the operating system or critical system applications

• Installation of tools such as SYN cookies to prevent denial of service attacks

• Use of tripwire and log file analysis to ensure the ongoing integrity of each system

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

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

Application Security

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

1. Username and password - Each registrar will be assigned a username and a password that they will keep secure. The passwords will be stored in encrypted form, so that even the registry will not have access to all of the registrars passwords. The password for each username will be changed on a periodic basis.

2. Client side SSL certificates - Each registrar will use a certificate with their registrar user name as the common name field in the distinguished name (this is the field that is used for the domain name in secure web server certificates). The registry server will only accept certificates that are digitally signed by the registry. (This differs from the NSI registry practice of requiring that certificates be signed by a third party. This eliminates some expense for registrars, and allows the registry to rely on the trusted relationship that it establishes with registrars as opposed to the generic verification policies utilized by third parties.) At the time of signing, the registry will be able to validate that the person requesting the certificate does in fact represent the registrar who has been assigned that particular username. The registry server will only accept connections from a client when the username they log in as matches the username in the certificate.

3. IP Address Filtering - The registry server will only permit logins from an restricted list of IP addresses. Each registrar will have a list of IP addresses associated with it. This would mean that even though the IP addressees of all registrars will be able to access the registry network, each registrar will only be able to log in from their own IP address range. In order to allow its clients to take advantage of redundant configuration or other special needs, the registry will permit multiple IP ranges per registrar.

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

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

Security of Registry Customer Service

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

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

Role of the Consortium vs. Outsourced Hosting Provider

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

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

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

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

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

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

Root access is controlled and managed by Tucows Operations.

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

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

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

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

D15.2.10. Peak capacities:.

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

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

• First day: approximately 125,000 registrations

• First week: approximately 375,000 registrations

• First month: approximately 900,000 registrations

• First quarter: approximately 1,875,000 registrations

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

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

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

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

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

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

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

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

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

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

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

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

D15.2.11. System reliability:

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

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

The system will provide 99.9% availability.

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

Whois response time

Whois update maximum lag time

Zone file update maximum lag time

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[INSERT 2012 HERE]

D15.2.12. System outage prevention:

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

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

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

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

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

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

D15.2.13. System recovery procedures:

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

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

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

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

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

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

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

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

D15.2.14. Technical and other support:

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

Access to Registry Data

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

Help Desk

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

Support for Domain Name Registrants, and Internet Users

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

Escalation

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

Level I Catastrophic outage, or disaster recovery involving critical operations to the registry overall. Response reports shall be provided every 15 minutes, by no less than a senior registry systems engineer.

Level II Systems outage involving non-critical operations to the registry affecting one or more registrars only, but not the entire system. Response reports shall be provided every 30 minutes, by no less than a qualified registry systems engineer.

Level III Technical based question, usually unique to the registrar, that may require support from a registry systems operator or engineer. Requests for information or technical support shall be provided within on hour unless is it deemed to be a Level II incident.

Level IV Entry level support, basic questions of operations or registrar information, provided on an immediate 24/7 level. Response reports provided by TSG support staff within 4 hours.

24/7/365 Support

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

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

Notification for Outages

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

Support Systems, CTI, Database management

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

Geographic Diversity

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

Staffing

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

Security for Technical Support

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

Registrar Contact Information

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

Incoming Registrar Support (OT&E )

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

Standards Compliance

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

Registrar Survey

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

D15.3. Subcontractors.

If you intend to subcontract any the following: all of the registry operation function; any portion of the registry function accounting for 10% or more of overall costs of the registry function; or any portion of any of the following parts of the registry function accounting for 25% or more of overall costs of the part: database operation, zone file generation, zone file distribution and publication, billing and collection, data escrow and backup, and Whois service, please (a) identify the subcontractor; (b) state the scope and terms of the subcontract; and (c) attach a comprehensive technical proposal from the subcontractor that describes its technical plans and capabilities in a manner similar to that of the Technical Capabilities and Plan section of the Registry Operator's Proposal. In addition, subcontractor proposals should include full information on the subcontractor's technical, financial, and management capabilities and resources.

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

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

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

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

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

__________________________________________

Signature

Rita A. Rodin

Name (please print)

Counsel to the Company and Authorized Signatory

Title

Afilias, LLC

Name of Registry Operator

October 2, 2000

Date