The third section of the .org Proposal is a description of your technical plan. This section must include a comprehensive, professional-quality technical plan that provides a full description of the proposed technical solution for transitioning and operating all aspects of the Registry Function. The topics listed below are representative of the type of subjects that will be covered in the technical plan section of the .org Proposal.

Technical plan introduction

Only NeuStar has the requisite combination of experience and skills in both the transition and the operation of a large registry system to ensure that the .org TLD is transitioned in a smooth and seamless fashion to a stable, robust, high-availability global registry infrastructure. 

The transition of a large Internet TLD such as .org from one operator to another is not a trivial task.  A successful transition and the continued operation consistent with technical, business, and policy mandates of the TLD requires that both the incumbent and the successor operator have an intimate understanding of the transition process and associated technical risks and requirements.  Moreover, the new registry operator must have in place both stable, secure, high-availability registry infrastructure, as well as comprehensive, tested policy and business mechanisms to assume the complex day-to-day operations of a large TLD.  Specifically, the new registry operator must:

• Have experience operating a stable, well-functioning, and highly secure global registry infrastructure;

• Have detailed, practical experience in the transition of a TLD between operating registry platforms to ensure a seamless transition with no interruption in DNS resolution of the existing registered names; and

• Have in place working and tested mechanisms for the integration of, and continued compliance with, the often complex daily technical, business, contractual, and policy requirements associated with the operation of the .org TLD.

Other applicants will offer solutions for one or more of these criteria based upon experience operating a registry.  Only NeuStar, however, offers a solution that incorporates practical, non-theoretical experience in each of these criteria.  All other proposals will include theoretical solutions based upon the applicant's experience in other aspects of registry operations, but lacking the important benefit of having been applied successfully in “real world” operations.

NeuStar's .org solution begins with a proven, high-availability, highly secure and stable existing registry platform.  NeuStar's global registry infrastructure is home to the .biz and .us TLDs, and serves over 800,000 names of registered domain names in a near real-time robust environment.  Added to this strong infrastructure is NeuStar's practical experience with the smooth transition of a multitude of live mission-critical registries.  For example, NeuStar was responsible for the transition of critical numbering services.  In particular, NeuStar successfully transitioned number pooling registries from vendors in multiple states in the U.S. in a timely and successful fashion.  More importantly, however, NeuStar recently completed the highly successful transition of the existing .us ccTLD from VeriSign.  This transition is directly analogous to the transition of .org, which will benefit from NeuStar's experience and lessons learned.

Finally, as the existing operator of registries governed by ICANN and the U.S. Department of Commerce, NeuStar has in place comprehensive, effective processes for the integration of important policy and contractual requirements.  These processes will ensure continued compliance with the important requirements of the .org TLD, and ensure that the TLD continues to serve the global noncommercial community.

The following Proposal Sections—C17, C18, and C19—provide complete discussions of the points summarized above.

Technical plan for performing the Registry Function.

This should present a comprehensive technical plan for performing the Registry Function. In addition to providing basic information concerning the proposed technical solution (with appropriate diagrams), this section offers the applicant an opportunity to demonstrate that it has carefully analyzed the technical requirements for performing the Registry Function. Factors that should be addressed in the technical plan include:

NeuStar’s proven registry architecture and technical plan for the .org TLD is the foundation for stability.

The ICANN correctly lists as its first criterion in the transition of the .org registry preservation of “the stability of the Internet, including the domain-name system (DNS).”  Further, consideration will be given to “ICANN’s level of confidence that particular proposal will result in technically sound, high-quality services that meet the needs of .org registrants.”  In developing a sound technical plan, there are a number of critical matters that the plan must address, including:

• The implementation of a stable, scalable and secure architecture designed to ensure that the .org community receives world-class reliable service;

• The development of open standard protocol solutions and customer support systems in compliance with registry specifications and industry best practices;

• The development and implementation of processes and mechanisms to minimize system outages, maximize response and recovery capability, and ensure future integrity of the system and data as a whole.

Although each of these requirements seems both obvious and seemingly easy to implement, the development of a comprehensive registry solution is a complex and resource-intensive undertaking.  Not all applicants will be capable of addressing each of these matters in a comprehensive and efficient manner.  NeuStar’s legacy is the development and provisioning of such highly complex systems within a reasonable timeframe and in a cost-effective manner.

NeuStar’s architecture comprises a comprehensive, next-generation solution for critical Internet registry services.  Detailed discussions of each of these elements are contained in the following subsections.

General description of proposed facilities and systems.

Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.

NeuStar has deployed a world-class registry infrastructure including redundant Shared Registration System (SRS) data centers in Sterling, Virginia and Chicago, Illinois USA and six nameserver sites geographically dispersed for diversity and global reach.  Our facility locations were selected and engineered to provide diverse network connectivity and resilience against natural and man-made disaster scenarios.  Our systems and hardware were selected to provide scalability, stability and security.  ICANN and the .org community will benefit from the highly stable, secure, redundant, and scalable architecture of the NeuStar registry infrastructure.  

In this section we will describe how NeuStar’s registry architecture and infrastructure combine to meet the need of ICANN and the .org community for a highly stable, secure, redundant and scalable solution.  We will address; registry facilities and locations, network connectivity, registry system architecture and infrastructure, and system descriptions. 

Registry facilities and locations

NeuStar’s registry architecture consists of redundant SRS data centers and six nameserver sites to provide a seamless, responsive, and reliable registry service to registrars and Internet users. As shown in Exhibit C17-1 our registry’s redundant SRS data center and nameserver sites are geographically dispersed worldwide and interconnected via a Virtual Private Network (VPN) to provide worldwide coverage and protect against natural and man-made disasters and other contingencies. In addition to the existing six nameserver sites, we will deploy two more nameserver sites—one in Europe and one in Asia—to provide additional global reach. The facility locations are provided in the following table.

The number and placement of our sites allows NeuStar to commit to the highest service levels in the industry.  We believe these are the minimum service levels necessary for a registry such as .org with over two million names serving the critical needs of the global noncommercial community.  Our substantial service level commitments include:

• SRS service availability is guaranteed at 99.9% per calendar month.

• Whois service availability is guaranteed at 99.95% per calendar month. 

• Nameserver service availability is guaranteed at 99.999% per calendar year

Environmental description
NeuStar maintains high-security, world-class facilities globally.  Each of these facilities share similar environmental and security attributes, which have been chosen to meet exacting service level requirements.  NeuStar’s SRS data centers in Chicago and Sterling are operated and maintained on a full-time basis by dedicated NeuStar personnel.  In addition, the nameserver sites located in San Jose, London and Singapore are maintained in world-class co-location facilities.  All of the nameserver equipment in the nameserver sites is owned, engineered, implemented, and maintained by NeuStar personnel. 

Each site is located in a modern, fire-resistant building that offers inherent structural protection from such natural and man-made disasters as hurricanes, earthquakes, and civil disorder.  Facilities are protected by a public fire department, and have their internal fire-detection systems connected directly to the fire department.  Data centers are additionally protected from fire by sprinkler systems, each equipment room is protected by a pre-action fire-suppression system that uses Inergen gas as an extinguishing agent.  The important environmental factors at the SRS Data Center and nameserver sites are described below.

Building security
NeuStar vigilantly controls physical access to our facilities.  Physical security mechanisms include security guards, closed circuit TV surveillance video cameras, and intrusion detection systems.  Our network operations center (NOC) monitors access to all locations on a 24 x 7 x 365 basis.

At NeuStar’s SRS data center locations employees must present badges to gain entrance, and must wear their badges at all times while in the facility.  All visitors must register to gain entrance to any NeuStar facility.  Visitors must display visitor badges at all times while they are in the facility, and must be escorted by a NeuStar employee.  Visitor registration records are maintained for a period of one year.

NeuStar on-site security personnel are on duty 24 x 7 x 365 to monitor closed-circuit television cameras placed strategically throughout the facilities. Security personnel are stationed at each building-access point throughout normal working hours; at other times, employees must use authorized electronic key cards to gain access to the buildings. Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only upon activation of a hand geometry reader.  Senior facility managers establish the rights of employees to access individual rooms, and ensure that each reader is programmed to pass only authorized individuals. The hand geometry readers compile and maintain an access record.

For co-located nameserver sites, NeuStar has leased a separate room from all other tenants with its own access point to house its registry infrastructure.  Access to NeuStar’s room is as strictly enforced as it is at NeuStar’s SRS data centers. The co-location facility provider is given a limited list of authorized individuals granted access to NeuStar facilities.  NeuStar employees are responsible for accepting or denying access.  Visitors sign in and must wear a badge while on the premises.  They are escorted either by NeuStar personnel or personnel provided by the co-location facility.  Security personnel are located at each entrance point to the building and individuals must present the proper credentials to gain access.  Each location is monitored on a 24 x 7 x 365 basis by the facility provider’s NOC.  In the event of an alarm associated with NeuStar’s room, the facility provider’s NOC will contact NeuStar’s NOC to seek further direction related to the event. 

Network connectivity

NeuStar uses the Internet to provide connectivity to the Registrars and a Virtual Private Network (VPN) to provide a secure Registry Management Network for communications between the SRS data centers and the nameserver sites.  Each nameserver site will be connected to the Internet independently of the other sites. 

Internet connectivity – SRS data center
NeuStar has deployed two ISP links at each SRS data center to serve registry needs.  Each link is provided by a different ISP for a total of four separate ISP interfaces.  Exhibit C17-2 for a diagram of the SRS data center connectivity.  Each link has available capacity of 45MB for a total of 90MB at each data center.  For cost efficiency reasons, we have committed to using 10MB on each of the links. However, we can utilize the entire 45MB if demand requires. If demand were to consistently exceed 10MB, we would adjust our agreements for more “committed” bandwidth.  

Internet connectivity—nameserver site
Nameservers sites located at the SRS data centers share Internet bandwidth with the SRS data center.  Bandwidth engineering for those sites is covered in the previous section.  For co-location sites, the co-location facility provider provisions Internet bandwidth at the co-located sites.  The facility provider has provisioned a highly diverse and redundant network.  NeuStar has provisioned at least 2MB of capacity into each nameserver location.  For security purposes, the NeuStar routers will be configured to only allow DNS UDP/TCP traffic.  The router is connected to a load balancer that distributes the query load among the nameservers in that site’s cluster.  A firewall protects the whole system in each location to provide the highest level of packet filtering from a TLD system today. We also use intrusion detection systems to proactively detect and deter security incidents. 

VPN registry management network
Each SRS data center is connected to each of the nameserver sites over a secure VPN.  Two ATM links connect the two SRS data centers.  Refer to Exhibit C17-2 for a diagram of the data center connectivity.  These links comprise NeuStar’s Secure Registry Management Network. 

The links between the data centers are used for:

• Alternate access to the internet in the event of an outage;

• Providing zone file updates for nameserver site #2;

• System maintenance and monitoring;

• Updating the back-up registry database; and

• Updating the Whois databases in the backup data centers. 

The VPN between the data centers and the nameserver sites is used for:

Zone file updates;

• System maintenance and monitoring, and

• Remote Administration of nameservers.

Building LAN backbone
Within NeuStar’s data centers, a redundant switched 100 MB Ethernet building LAN backbone maintains high network availability via redundant Ethernet switches. Devices are dual attached to each of the Ethernet switches to provide a redundant LAN architecture. The building LAN is protected from the Internet via a firewall that provides IP filtering and network-based intrusion detection services. This protects the system from hacking and denial of service attacks.

Registry system architecture and infrastructure

NeuStar has deployed a world-class registry architecture to support its current registry service.  The NeuStar architecture was designed:

• With near military-grade security,

• To be highly stable under extreme loads,

• To be easily and efficiently scaled for higher demand, and

NeuStar’s registry architecture represents superior next generation design among the best in the industry.

Shared registration system (SRS) data center

As depicted in Exhibit C17-3, NeuStar has created a highly robust five-layer SRS architecture for its registry solution.  This architecture is duplicated in both data centers.  The five layers are:

1. External network layer;

2. Protocol server layer (herein referred to as protocol layer);

3. Internal network layer;

4. Application server layer (herein referred to as application layer); and

5. Database layer

NeuStar’s SRS is the only registry system to ever have performed a first come first serve (FCFS) “landrush”.  To address service failure concerns, all landrushes prior to NeuStar’s launch of the expanded .us, have been performed in an off-line batch mode.  This is a different registration process than the real-time process to which registrars and consumers have become accustomed.  Recognizing the needs of the domain name community NeuStar built its registry to be able to support a real-time landrush.  NeuStar’s SRS operated during FCFS landrush exactly as it would during normal operations (with the exception of some additional network monitoring).  The SRS was able to support a peak demand associated with 30,000 registrations in one hour during the FCFS landrush and a total transaction load of five million transactions in the first 24 hours. 

This existing infrastructure will serve as the core for the .org registry.  Upgrading the existing NeuStar registry to support .org is primarily a matter of adding RRP servers at the protocol and application layers. 

External network layer
The external network layer, as shown in Exhibit C17-4, is NeuStar’s Internet interconnection point.  This layer is dedicated to security and traffic management, thus ensuring a secure and robust connection between the registrars and the protocol servers at the second layer.  The external network layer consists of four redundant servers each performing its own security function or traffic management and security function: 

• Edge router—The edge router provides Internet connectivity and performs IP-packet filtering. 

• Traffic shaper—The traffic shaper is an intelligent bandwidth management device.  It has the ability to manage bandwidth in multiple ways, including on an aggregate basis, on an individual port basis, and on an individual registrar basis.  The traffic shaper also performs IP-packet filtering. 

• Firewall—The firewall is dedicated to perimeter security.  It provides policy-based IP filtering to protect against system hacks, break-ins, and denial of service attacks. The firewall also includes network-based intrusion detection to protect against Internet hackers.

• Load balancer—The load balancers distribute traffic among the clusters of protocol servers (RRP, EPP, Whois, and Web) in the second layer of the SRS data center.  Load balancing protects our protocol layer from common denial-of-service attacks; e.g., SYN floods, ping floods, and “smurf” attacks. Security policies can be based on any combination of source address, destination address, and protocol type or content.  Load balancing is also a critical element for providing scalability at the protocol layer.  It provides the ability to easily add additional protocol servers without re-engineering the protocol software and network equipment. 

In addition to the security provided by each of these servers, there is an Intrusion Detection System (IDS) that works cooperatively with all of this equipment as well as the equipment at the internal network layer.  The IDS monitors and logs every packet that enters and leaves the data center.  Most IDSs simply monitor ingress; NeuStar’s also monitors egress.  This is used to detect, among other things, the possibility of a hacker trying to use a NeuStar site to launch a denial of service attack.  After logging the packets, the IDS performs sophisticated data analysis including, audits, statistical analysis, and checks against a negative list of known bad actors in an effort to detect a security breach.  Once a breach is detected the IDS can work with any combination of the servers in the layer to isolate the attack and filter the packets. 

Protocol layer
The protocol layer, as depicted in Exhibit C17-5, consists of servers that provide the interface with our customers.  All servers are deployed in a cluster configuration to provide scalability.  Packets coming from the load balancers in the external network layer are distributed among the different servers in the cluster to provide load sharing.  In a cluster configuration, no one server gets more traffic than any other server.  Additional capacity is added at the protocol layer by adding additional servers.  Adding capacity does not require any re-engineering of the protocol server software or network configuration.  Servers at the protocol layer include:

EPP servers—These servers interface with the current registrars of NeuStar’s existing registry service for the purposes of processing EPP transactions.  .Org registrars will be migrated to these servers when the .org registry is migrated from an RRP interface to an EPP interface. 

Whois database servers—The Whois database provides information pertaining to the domain name holder.

Web servers—A high capacity secure Web Server cluster is provided to enable secure web services and information dissemination that is outside the scope of the RRP protocol.  It contains a registry home page to enable registrars to sign in and inquire about account status, obtain downloads and whitepapers, access frequently asked questions, obtain self help support, or submit a trouble ticket to the .org registry help desk. 

Internal network layer
The internal network layer, as depicted in Exhibit C17-6 is in place specifically to manage traffic between the protocol layer and the application layer and to detect and deter any security breach in the unlikely event that the first two layers do not prevent a given breach.  The internal network layer consists of redundant firewalls and load balancers.  These serve the same security functions identified in the external network layer.  In addition the load balancers provide scalability at the application layer.  Specifically they provide the ability to easily add additional application servers without re-engineering the application software and network equipment. 

The internal network layer, like the external network layer, also works in conjunction with the IDS.  These two security and traffic management layers coupled with the IDS create a State-of-the-Art security architecture for data centers. 

Application layer
The application layer, as depicted in Exhibit C17-7 consists of servers that provide an interface between the RRP servers in the protocol layer with the .org database in the database layer.  (It also includes EPP application servers for our existing EPP based registry services.)  The application servers contain the business logic required to interface commands originated by the registrars, through the protocol servers, with the .org database. 

For example a registrar may perform a “check domain” on neustar.org.  The protocol server receives that request and sends it to the application server.  The application service will format a query to the .org database to seek exactly the information necessary to respond to a “check domain” on the name neustar.org.  It receives the response from the database and forwards it to the protocol server that then forwards it to the registrar in the RRP format. 

NeuStar will deploy the RRP application servers to support the .org domain.  .Org service will be migrated to the EPP application servers in this layer when the .org registry migrates from an RRP interface to an EPP interface. 

Database layer
The database layer, as depicted in Exhibit C17-8 stores the .org database as well as administrative servers that perform update functions for the zone file and Whois.  These servers include:

.org database—The database has been purposely designed to reside behind multiple levels of security.  Each database server consists of two identical Fault-tolerant RISC systems that are designed for high volume on-line transaction-processing database applications.  A multi-session, multi-threaded server and dual cache architecture (client/server) provides exceptionally high throughput and fast access to stored objects.  The database enables transparent database failover without any changes to application code or the operating system.  Updates at the primary data center are replicated to the database servers in the back-up data center. 

Zone file distribution administrator—The zone file distribution administrator polls the .org database for updates.  It then passes updates on to the master nameserver. 

Master nameserver—The master nameserver receives updates from the zone file distribution administrator and then updates the clusters of nameservers in the six, soon to be eight, nameserver sites.  This is not to be confused with a primary nameserver in DNS terminology.  The master nameserver does not receive DNS queries from resolvers on the Internet.  It is strictly for NeuStar’s internal administrative purposes.  Updates are processed from the .org database to the nameserver sites in less than 15 minutes. 

Whois distribution administrator—The Whois distribution administrator polls the .org database for updates.  It collects updates and then distributes them to the Whois databases located at the primary and back-up data centers. 

Nameserver sites

There are six nameserver sites in NeuStar’s registry architecture.  We plan to deploy two more sites, one in Europe and one in Asia, to provide additional diversity and global reach to the .org community. 

Each nameserver site is equipped with a router, firewall, load balancer, and a cluster of nameservers.  NeuStar’s nameserver architecture is one of the few TLD nameservers that includes a firewall.  This provides an additional level of security above and beyond the basic level of security provided in the DNS protocol.  The combination of a nameserver cluster behind a load balancer provides a highly scalable solution.  Additional capacity can simply be added by adding another nameserver to the cluster.  The nameserver architecture is depicted in Exhibit C17-9. 

System descriptions

NeuStar utilizes moderate-level, mid-level, and high-end cluster server platforms for installation at each site. The servers are selected for applications depending on the requirements, storage capacity, throughput, interoperability, availability, and level of security. These server platform characteristics are summarized in the following table.

Registry-registrar model and protocol.

Please describe in detail, including a full (to the extent feasible) statement of the proposed RRP and EPP implementations. See also item C22 below.

To ensure the highest levels of stability and equal access for all .org registrars, NeuStar will implement a fully functional RRP implementation for the transition of .org and will migrate all registrars to the EPP protocol upon its adoption as an IETF Proposed Standard.

NeuStar is dedicated to the development and implementation of open industry standards.  Common, well-documented interface protocols are critical to the overall stability of the Internet.  Therefore, NeuStar is an active participant in and contributor to the IETF Provreg Working Group which is developing the open EPP protocol for registry-registrar interfaces.  In fact, NeuStar’s registry has a truly EPP-04 compliant interface.  Most other EPP implementations reflect either earlier versions of EPP or are incomplete EPP-04 implementations.  Thus, implementation on the NeuStar platform of the most current version of the EPP protocol already is complete.  The larger issues for .org are the appropriate timing of a migration from RRP to EPP, and the technical issues associated with such a migration, particularly for the registrars that must develop new registry interfaces.  The details of NeuStar’s proposed migration to EPP for the .org registry is contained in Proposal Section C22 of this proposal.

To ensure the continuing stability of the .org registry for the existing .org registrars, NeuStar will implement a fully functional, standard implementation of the RRP protocol that will be used by all registrars prior to migration.  This implementation will comply with both the standard and the RRP toolkit in use by the registrars at the time of transition.  Even though RRP is a proprietary protocol, it is well documented and understood.  It is documented as an IETF Informational RFC (RFC 2832) and VeriSign distributes copies of an RRP toolkit to its registrars.  As of the writing of this proposal, VeriSign intends to update RRP to Version 2.0.0.  NeuStar’s implementation of RRP will, of course, track such updates and any new tools used by the registrars.

Once IETF has issued EPP as a Proposed Standard, NeuStar will begin the migration of registrars from RRP to EPP, as discussed in Proposal Section C22.  Of course, consistent with NeuStar’s practices, the then most current version of the EPP protocol will be implemented.

Database capabilities.

Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

NeuStar will provide an enterprise-strength, fault-tolerant database system capable of managing large databases and high transaction-processing loads reliably and with scalable growth to accommodate change. The database system supports data synchronization from the primary data center to the back-up SRS data center that is geographically dispersed.  The proposed database system is shown to be a stable and operational system as it has been successfully deployed for NeuStar’s existing registry systems.

The heart of the SRS is its database systems, which provide not only simple data storage-and-retrieval capabilities, but also the following attributes:

• Persistence—Storage and random retrieval of data to enable rapid response times;

• Concurrency—Ability to support multiple users simultaneously to provide consistent support for each registrar;

• Distribution (data replication)—Maintenance of relationships across multiple databases for redundancy and data security;

• Integrity—Methods to ensure data is not lost or corrupted (e.g., automatic two-phase commit, physical and logical log files, roll-forward recovery) to ensure data accuracy as well as redundancy and security;

• Availability—Support for 24 x 7x 365 operations to support the registrars around the clock and around the world;

• Scalability—Unimpaired performance as the number of users, workload volume, or database size increases to meet the increasing needs of the .org community.

As application architectures, such as our SRS, become increasingly dependent on distributed client/server communications and processing, system designers must carefully architect data processing occurs whether it’s on the database server, applications server, or the client server.  Our final design distributes the processing workload in a way that maximizes scalability and minimizes down time.

For purposes of clarity, NeuStar’s response to item C17.3 address each of the three core SRS databases; i.e., .org, billing and collection (B&C), and Whois; and includes:

C17.3.1  Database functional overviews—Describes the characteristics of the SRS databases (i.e., size, throughput, and scalability); database procedures and functions for object creation, editing, and deleting; change notifications; transfer procedures; grace-period functions; and reporting.

C17.3.2  Database system descriptions—Describes the database system components, server platforms, and scalability.

C17.3.3  Database security and access privileges—Describes the access controls for granting and denying users and administrators access to the databases.

Database functional overviews

NeuStar’s registry will include three major databases

• .org database—This database’s primary function is to provide highly reliable persistent storage for all of the registry information required to provide domain-registration services.  The .org database is highly secure, with access limited to authenticated registrars, trusted application-server processes, and highly restricted access by the registry’s database administrators. 

• Billing and collection (B&C) database—This database will provide the information required for NeuStar to render B&C services to the registrars. Access to its data is restricted to the trusted B&C system processes and to registry database administrators. Registrars can view billing data through a secure Web portal.

• Whois database—The Whois database is a searchable database that any Internet user can access to view details of the domain name stored in the .org database. The Whois database maintains data about registrars, domain names, nameservers, and IP addresses. The Whois database will be updated from the .org database via a dynamic and incremental replication process.

In addition to these databases, the registry will maintain various internal databases to support various operations, e.g., authorizing login userIDs and passwords, authenticating digital certificates, and maintaining access control lists.

In implementing the .org database systems, our system designers will carefully analyze the differing requirements for the three major databases and select the optimum solution for each.  Design techniques and considerations will include:

• Multiple logical data models that will be optimized for the different types of information that each system needs to serve registrars efficiently;

• Content that will include data related not only to domain names and domain name registration, but also to registrars, registrants, nameservers, Whois servers, and the B&C system;

• Differing volumes of database transactions and database sizes;

• Differing business needs;

• Differing performance and availability requirements; and

• Replication of databases to achieve high availability and facilitate backup/recovery. 

Database size, throughput, and scalability
The following table lists design parameters for the initial design of the three major .org databases.  The parameters are based on projected volumes in the next two years.  The term “scalability” in the table refers to the database’s ultimate capacity expressed as a multiple of the initial design capacity in terms of size and transaction processing power.

Attributes of all database servers are:

• RISC 400 Mhz CPU;

• 64bit, 2 to3 2-way crossbar SMS, with 8x8 non-blocking multi-ported cross bar;

• 32GB ECC RAM;

• 240 MB/sec channel bandwidth;

• Maximum internal storage 288 GB

• Maximum external RAID 10TB

• Redundant hot-swappable, power supplies;

• Dual-attach 100BaseTX/FX Ethernet Adapters;

• Event management software for remote management; and

• 64-bit Unix operating system.

Database procedures and functions
The database system is critical to the processing of SRS business transactions.  The .org database is accessed during most registrar/registry transactions. If a transaction is completed successfully, the system updates these two databases. The .org database will update B&C database and the Whois database if appropriate. The following registry functions are supported by the .org database:

Object creation—Domain name and nameserver registration;

Object editing—Modifying domain name or nameserver data and creating or modifying associations;

Object deletion—Domain name cancellations;

Object existence and information query—Obtain information on domain name or nameserver;

Object transfer—Transfer a domain name to a different registrar;

Automatic domain renewal—Extend a domain name registration for a year;

Grace period implementation—Allow various time periods before actions become final;

Registrar administration—Add, delete, or change to a registrar account or billing profile;

Account-related information—Billing information provided to registrars and designated registry staff;

Reporting—Account and billing information that can be viewed on line or via e-mail; and

Operations on objects
Operations on domain name objects refer to the first six functions in the list above, namely creation, modification, deletion, query, transfer, and auto-renewal. In addition, nameserver information can be created, associated with, disassociated with, and deleted with respect to domain name objects. Whether nameserver information is treated as attributes of the domain object or as a separate object is an implementation detail internal to the .org database.

Since the .org registry will be a “thin” registry during the transition these object operations will be sufficient to ensure a seamless transition of the .org registry and to maintain the stability of the domain name systems for the Internet.

In terms of the registry-registrar interface, both RRP and EPP have corresponding commands to support these six object operations. RRP is the protocol currently used for the .org registry, while EPP is the upcoming IETF standard that is being used by a number of registries including NeuStar.  Proposal Section C22 further discusses the migration strategy for the .org registry-registrar interface.

Grace period implementation
NeuStar’s registry supports grace periods for several registry functions and will support those for .org.  They include:

• Add grace period;

• Renew grace period;

• Auto-renew grace period; and

• Transfers grace period.

We also support ICANN’s policy on overlapping grace periods.  We are participating in and following ICANN’s progression redemption grace period for delegated names and will implement the resulting solution.

Registrar administration
Registrar administration refers to adding or deleting registrars, and providing each registrar with secure access to the system and to that registrar’s data. The .org database manages most registrar data; the B&C database contains the B&C profile and contacts.  Any “Add/Delete Registrar” or “Change Registrar Profile” request will generate the appropriate changes in the .org and B&C databases.

Registrar transfer procedures
Registrants may transfer their domain name from one sponsoring registrar to another after the first 60 days of the initial registration of the domain name.  NeuStar currently performs registrar transfers in its existing registry service over an EPP (extensible provisioning protocol) interface.  In the .org registry the transfer process is done over an RRP (registry-registrar protocol) interface.  The process is very similar except for the fact that once the registry receives the “transfer” request from the gaining registrar, the registry will notify the both gaining and losing registrar via an e-mail.  Then when the transfer has been completed it again notifies both registrars via e-mail.  In the EPP protocol both of these notifications are done over the EPP interface. 

The transfer steps are as follows:

• The registry receives a transfer request from the gaining registrar.

• The registry transmits an e-mail to both the gaining and losing registrars notifying them of the transfer.

• The transfer will be completed if:

  • The losing registrar expressly "acknowledges" the request, or

  • VGRS does not receive a response from the losing registrar within five days.

• When the registry’s database has been updated to reflect the change to the gaining registrar the registry will transmit an e-mail notification to both registrars. 

The losing registrar may deny the transfer request by replying to the “transfer” request with a negative acknowledgement (or NACK) within five days of the initial transfer request. 

NeuStar has been active at ICANN with regard to efforts to modify this process or the policy related to this process.  We commit to implementing whatever changes are required by the registry to meet the agreements reached at the conclusion of this effort. 

Billing notifications
NeuStar’s B&C system will monitor the registrars’ accounts for insufficient funds.  If it determines that the balance is below the required minimum, the registrar will be notified by the registry’s customer-service personnel.

Reporting capabilities
To support a detailed, usage-based accounting and billing structure, the B&C database and the .org database generates a substantial amount of highly detailed resource accounting data.  This includes:

Monthly account statements—NeuStar will send a detailed monthly transaction statement to each registrar via e-mail.  The statement will include the following:

• An account summary, including payments received, balance forward, and credits and adjustments; and

• A detailed list of all fee-incurring charges; e.g., new registrations, registration renewals, registrar transfers.

Online B&C reports—The B&C system will generate a variety of reports for internal and external users.

• Using the Internet, registrars will be able to access their account statements and detailed transaction reports, but not those of other registrars.

• Registrars will be able to request custom reports. The system will generate these reports in a batch process, and will store them in the FTP directory for the requesting registrar to download.

Audit reports—NeuStar will create audit reports for internal and external purposes. Audit reports will include:

• Policy implementation;

• Access privileges;

• Capacity handling; and

• Accountability.

Database system descriptions

Although the three primary SRS databases—.org, Whois, and B&C—will differ, depending upon the services they support, the SRS on the whole, will be structured to:

• Manage large quantities of data;

• Support applications that use data models with complex relationships;

• Perform complex operations on managed objects; and

• Process large volumes of transactions from users.

NeuStar forecasts that, as with most online transaction processing (OLTP) applications, the anticipated volume of SRS transactions will have a high ratio of “reads” to “writes.”   We will design the databases and applications by partitioning the workload to improve response times and scalability.

.org Database
The .org database will support and provide information for primary domain-registration services. The following table lists the data stored in the .org database.

NeuStar will configure the database system to provide appropriate response times for the transactions that registrars perform. We will do capacity planning to ensure that as business requirements increase and demand for domain names grows, the system will be able to easily handle the workload within agreed response times.

B&C database
The B&C database provides information for B&C services. Its contents include:

• Registrar billing profile—accessed and modified by the registrar administration function;

• Registrar account—queried, credited, and debited while processing transactions from registrars; and

• Catalog—Pricing information for different transactions queried in the charging process.

Whois database
Anyone can query the Whois database. Each database entity includes the following information for all second-level Internet domain names registered in the TLD:

• Domain name;

• Nameserver;

• IP address; and

• Registrar.

Database administration
NeuStar personnel who administer and maintain the databases will perform their tasks at times and intervals scheduled to ensure maximum system availability. Typical database administration tasks include the following:

• Monitoring and tuning;

• Backing up and recover;

• Adding additional data volumes;

• Implementation clustering strategies;

• Reorganizing;

• Adding and removing indexes;

• Evolving the schema;

• Granting access;

• Browsing and querying; and

• Configuring fault tolerance.

Database backup/restore
Proposal Sections C17.7 (Data Escrow and Backup) and C17.15 (System Recovery Procedures) describe our proven backup/restore processes, which we will employ for the SRS operations.  Backup frequency and logging processes will minimize data loss in case of system outage.

Disaster recovery
The active SRS data center will synchronize its database with that at the back-up SRS data center in near real time.  As Proposal Sections C17.7 (Data Escrow and Backup) and C17.15 (System Recovery Procedures) explain, in the unlikely event of a catastrophic outage at one data center, the SRS operations will fail-over to the replicate database.

Database security and access privileges

Proposal Section C17.9 explains NeuStar’s security measures in detail.  The major technical security related controls on the database platforms to ensure data integrity and security include the following:

• Server operating system level access control provides protection against unauthorized access.  It employs userID and password, along with and file-access-control lists.

• Database security with user profiles enables NeuStar to grant or deny access privileges to registrars, database users, and database administrators.  The controllable level of granularity extends down to the individual data field.

• NeuStar will establish security policies and routine logging/auditing/monitoring functions to ensure there is no unauthorized access. We will periodically review security to ensure that the system is functioning as needed.

• Registrar access to the database is via trusted processes on both the application server, and the B&C server.

• NeuStar will establish routine auditing and monitoring features to ensure there is no unauthorized activity, and will periodically review our security features to ensure that the system is functioning as needed

Zone file generation.

Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

NeuStar will implement its proven methodology for generating incremental zone file updates, which allows for propagation of the zone file on a near real-time basis.  This will improve the service to the .org community by allowing them to rely on rapid implementation of zone file updates and changes.  

Zone file generation and distribution represents the core function of the registry.  NeuStar developed an enhanced, near real-time zone file update process for .biz and .us that has greatly improved zone file service for both.  .org will directly benefit from this next-generation registry capability.  The remainder of this section compares and contrasts the traditional method with NeuStar’s dynamic, streamlined approach.

Traditional zone file generation process
The zone file is a flat database file consisting of the technical information that the DNS requires to function correctly: the domain name, nameserver hostname, and IP addresses (as necessary).  Traditionally, a TLD registry would update the zone file by generating a completely new zone file.  This zone file would be propagated to the nameservers, and would write over the existing zone file.  The size of the zone file and the fact that it was a complete replacement for the existing zone file dictated that the process be done infrequently, resulting in a process that could update zone files at most once or twice a day.  This is the process used currently for .org. 

The current file generation process has caused many problems for both registrars and registrants.  Registrants, in particular, have been troubled by the long delay before their registered domain names “go live” (or are re-delegated).  Common issues with the current process include:

• Zone file generation (and propagation) is a batch process performed twice a day.

  • Because updates occur infrequently, registrants have an additional delay before their domain names become “live.”  This delay confuses the registrants, who believe that a problem exists and contact their registrar.  The registrars must, in turn, respond by deploying unnecessary customer support resources.

  • Currently, websites can easily go down when a registrant transfers a domain name to a new hosting provider.  Because of the current delay in zone file generation, the original hosting provider removes the web site before the DNS is updated with the new delegation information.  This adversely affects the general stability of the Internet.

• Zone file information does not match Whois information because the two files are often updated at different times.

  • Currently, registrants can update zone information, and then check the Whois server to verify it.  Because the zone file and Whois service are not synchronized, the registrants become confused.  As with delayed zone file updates, this information mismatch causes additional and unnecessary customer support demands on registrars.

Improved zone file generation process: the NeuStar solution
To eliminate these deficiencies, NeuStar has implemented an incremental zone file generation process.  Zone file updates are keyed off of changes in the .org database.  The registrars initiate changes to the .org database on behalf of their registrants.  For example, a registrar may add a new domain name through the RRP interface to the registry.  Once the name is added, the appropriate information (i.e., a DNS resource record) must be added to the zone file. 

NeuStar has created a function within the registry called a zone file distribution administrator, as depicted in Exhibit C17-10.  This administrator polls the .org database for updates on a regular basis.  When it has accumulated a certain number of updates or a certain time limit has passed, it will create a file of incremental updates and initiate the process of incrementally updating the zone files hosted in the nameservers.  The update process is explained in more detail in Proposal Section C17.5. 

Security
The .org database stores all data used to generate and distribute the zone file updates.  For security reasons, registrars cannot access this database directly; the application layer controls all database access.  Registrars access the database (through the application servers) using the RRP protocol via the protocol layer.  The following procedures govern creation and modification of database information:

• Registrars are solely responsible for creating, modifying, and deleting information that is updated in the zone file.  The RRP protocol is the only gateway available to registrars for zone file editing.  This protocol is accessed using the NeuStar RRP servers.

• A registrar gains access to a domain name (and associated nameserver) when it registers that domain name or when the appropriate “transfer of registrar” is enacted.  In the case of a “transfer of registrar”, access control is revoked from the losing registrar after the transfer. 

• Access control to zone file data for RRP “Delete/Modify Domain Name” commands is granted only to the registrar that has management rights over the domain name. 

• In the case of an RRP “Create/Modify/Delete Nameserver” command, access control is granted only to the registrar that has management rights over the nameserver’s parent domain name (i.e., ns1.icann.org has a parent domain name icann.org).

Logging and data back-up
All zone files and updates are generated using information from the .org database.  All updates are recorded as database transaction logs.  Proposal sections C17.7, C17.14, and C17.15 contain information about the primary database backup and escrow systems, data center replication, and data recovery procedures.

Standards compliance
Each nameserver will run software that correctly implements the IETF standards for the DNS (RFC1035, RFC1995, RFC2136, RFC2181).  Further, NeuStar has implemented all applicable best-practice recommendations contained in RFC2870 (Root Nameserver Operational Requirements) for its existing registry business, and will implement them for the .org TLD.

Zone file distribution and publication.

Locations of nameservers, procedures for and means of distributing zone files to them. If you propose to employ the VeriSign global resolution and distribution facilities described in subsection 5.1.5 of the current .org registry agreement, please provide details of this aspect of your proposal.

NeuStar’s existing near real-time zone file update capability will provide a significant improvement in the registry service provided to the .org community. 

Traditionally, zone file updates in .org have been performed by writing-over the existing zone file with a new zone file that included any updates.  The new zone file was updated in the primary nameserver; the primary nameserver would then update the secondary nameservers.  Upon notification, a secondary nameserver would request the start of authority (SOA) record from the primary nameserver. If the serial number of the zone file was greater than that on the secondary nameserver, the secondary nameserver would initiate the zone transfer procedure.  If a secondary nameserver has not received a notification from the primary nameserver for a predefined period, it would request the SOA record from the primary nameserver and follow the same procedure as just described.

The problem with this process is that it relies on a complete new file for an update.  This approach is cumbersome and places a heavy load on the nameservers.  For these reasons, zone file updates have been traditionally limited to once or twice a day.  The current .org nameservers are only updated twice a day. 

The .org community would benefit from more frequent updates of the zone file.  This would reduce synchronization problems that occur between the Whois, the .org database (for check domain), and the zone file.  It would also allow for less downtime for the registrant when transferring e-mail or web hosting services from one provider to another.  The incremental zone file generation process defined in Proposal Section C17.4 is the first step required to allow more frequent updates to the zone file. 

Locations of nameservers and process of distribution
As discussed in Proposal Section C17.4, the zone file distribution administrator frequently polls the .org database for events that would generate a change in the zone file.  Once certain conditions are met (i.e., quantity of updates or expiration of a time interval), the administrator will push out an incremental file to a master nameserver located within the SRS data center.  The master nameserver compiles those changes since the last zone file update into a new incremental zone file update. Triggered by predefined conditions, the master nameserver provides the incremental update to the constellation of nameserver clusters.  Zone file updates are engineered to occur in intervals no longer than fifteen minutes.  As previously shown, Exhibit C17-10 depicts the nameserver generation, distribution and publication architecture. 

The master nameserver performs only one function—it updates the constellation of NeuStar nameserver sites shown in Exhibit C17-11.  The master nameserver does not receive and respond to DNS queries from the Internet.  It is the interface between the zone file distribution administrator and the nameservers that do receive and respond to DNS queries from the Internet.  We prefer not to call this the primary nameserver because we’ve designated a.gtld.biz to be the primary nameserver in our TLD start of authority (SOA) resource records.

Our central network management system will log all modifications to the .org database, all zone file-update actions, and all attempts at intrusion or other security-related events.  The master nameserver interconnects to the other nameservers over a secure IPsec-compliant VPN, with the exception of one nameserver cluster that is co-located with the master nameserver at the SRS data center.  That nameserver cluster is updated over the internal high-speed LAN.  Access to the VPN requires userID and passwords.  Passwords are rotated frequently. 

NeuStar will not employ the VeriSign global resolution and distribution facilities described in subsection 5.15 of the current .org registry agreement.

Billing and collection systems.

Technical characteristics, system security, accessibility.

The fundamental goal of the system is to maintain the B&C data and create reports which are accurate, accessible, secured, and scalable.  B&C will enable detailed transaction-based charging to the customers, based on extensive resource accounting and usage data recording performed in the registry.  The B&C system must produce timely and accurate account statements and billing reports that are accurate, easy to understand and contain only clearly defined charges for the services rendered. Such account statements are ultimately more economical because they are less likely to provoke costly billing disputes.

NeuStar’s simple B&C process, as depicted in Exhibit C17-12, is based on debit accounts established by each of our registrar clients.  We will withdraw all domain registration service payments from the incurring registrar’s debit account on a per-transaction basis.  We will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) for a registrar only so long as that registrar’s account shows a positive balance.  The B&C system will be sufficiently flexible to adapt to different billable events, grace-period implementations, and pricing structures, as the need arises.

NeuStar’s B&C system will be located at the two redundant SRS data centers in Sterling, VA, USA and Chicago, IL, USA. These systems will handle the key B&C functions, including:

• Debiting and crediting registrars accounts;

• Initiating low-balance notifications;

• Enabling registrars to view their accounts; and

• Tracking and reporting historical information.

B&C system technical capabilities and characteristics

NeuStar has developed a B&C solution to ensure data processing accuracy, accessibility, flexibility, and scalability to accommodate increasing transaction volumes and additional billable events.  Our financial and technical experts are experienced in customizing systems to evolve smoothly from performing simple to more complex tasks, and from small-scale to large-scale operations. We selected this solution after conducting a detailed analysis of the options for administering the registry’s B&C system. The system will be operational in time for the transition and will meet all .org B&C requirements, including:

• Generating the large amount of detailed resource-accounting information needed to support detailed usage-based charging of registrars;

• Supporting flexible queries of the .org B&C database through an API; and

• Tracking and reporting historical information.

B&C system description
Exhibit C17-13 illustrates the following key components of the B&C system and its interfaces with other SRS subsystems.

• Registrar profile administrator—This component responds to the registrar administration component of the application server; and

• B&C processor—This component processes all domain registration-related requests and other billable events from external servers.

B&C database—This database, which is separate from the .org database, contains the data shown in the following table.  Proposal Section C17.3 discusses the capabilities, management, administration, and backup of all databases, including the B&C database.  This subsection discusses only the design aspects of the B&C database.

Monitor and notifier—This component monitors the registrars’ accounts for sufficient funds and monitors domain name expirations and renewals.  When it detects actionable items, it notifies the transaction processor and the registry’s customer service organization.

Report generator—This component will generate monthly account statements and various reports, including annual reports.  This is also the component that customer service will use to generate custom reports requested by a registrar. After generating custom reports in a batch process, the report generator sends them to the FTP directory, where they are stored for the registrar to download.

B&C procedures
The B&C system processes data that is generated during the following types of procedures:

• Registrar administration—The B&C system will manage the B&C profile for registrars, along with the account and contact information.

• Transactional services—Actions that trigger a B&C event.  Registrar’s requests result in “transactions” at the application level and “events” in the B&C process. 

• Non-transactional services—Actions including balance forecasting, account balances.

The following tables provide details of each type of process flow. 

B&C system security

Proposal Section C17.9 provides extensive details about security issues, including system, network, and physical security, including specific issues such as access control, authentication, and authorization. This subsection discusses only security provisions that are specific to B&C.  Like the overall registry system, the B&C system will implement security at the network, system, and user levels, as follows:

Network-level security—The primary network-level communications technology underlying the B&C system is the IP protocol.  The only interfaces that have access to the B&C system are the Secure Web GUI to monitor account status and the FTP server to download reports. A firewall forms the secure interface between NeuStar’s secure internal network and the public Internet.  Firewalls use filters to permit or deny packet flow on the basis of the origin and/or destination of the packet’s addresses and ports.

Users who want to obtain access to the Secure Web portal that we provide to the registrars must first obtain access to the Secure Web server within the SRS.  When the user’s Web browser attempts to establish an HTTPS (secure web application protocol) session with the registry, our system initiates the SSL (secure sockets layer).  Part of the initialization sequence is a public key exchange or identification.  Once the SSL initialization is complete, it establishes a secure, encrypted channel between the user’s web browser and the registry’s web server, and exchanges digital certificates to ensure the integrity and authenticity of the session.  The use of a secure web browser/server ensures that no clear text, including passwords, is sent over the public or shared-data network.

System-level security—Secure user login facilities ensure that Secure Web Server users are fully authorized and authenticated.  The SRS Secure Web Server presents a login menu on the user’s Web browser.  The login menu includes 20 lines of warning message stating that this is a private computer system and authorization is required for access. 

When users attempt to log into the Secure Web server, they must enter their userID and password.  The login/password information forwarded back to NeuStar’s registry web server is encrypted through the secure SSL channel previously established. 

User-level security—Every B&C system user (individual and application, external and internal) has a unique user login account on the system, with unique user-identification codes (userIDs) and passwords to authenticate the user and an access control list to control his/her access to system resources and applications.   User profiles are set up and maintained in the database system so that user access to the B&C system is controlled by their user profile and the access privileges granted therein. NeuStar has established well-defined security procedures for adding and deleting users and modifying their logon account, access control lists, and user profile access privileges depending on the user’s functional role.  The following subsection, “Access Privileges,” contains additional information about user roles and privileges. 

B&C system access privileges

The B&C system and network employ multi-tiered access control to ensure that all B&C resources—transactions, data, etc.—are only accessed and used by authorized users. As previously discussed, access to the proposed B&C system via the network is fully secure behind a perimeter firewall and userID and password system, while physical access is controlled using electronic keys and palm readers. Once an authorized user gains access to the system, their privileges are controlled by the operating system access control lists and the database system user profile that determines what functions, system resources, and data the user is allowed to access and use.  Access privileges are broadly defined and controlled and limited to registry employees and registrars.  The following subparagraphs discuss the access privileges.

Registry employees
Only internal registry staff members, using cardkeys, can gain access to the registry facility. Registry employees who are authorized to access the B&C system do so using workstations connected through the registry LAN.   Except for the system administrators, these employees access the system using the B&C client interface, which will be established specifically for staff members to perform billing adjustments, maintenance, and related functions.

Each internal user of the B&C system is also associated with a user role that will permit or deny his access to different functions in the B&C system. The system administrator will create roles and allow them to access certain functionality.  We have defined user roles within NeuStar’s B&C-operations organization as follows:

• System administrators—perform system upgrades, maintenance, and user administration.

• B&C system administrator—configures the B&C system; e.g., user groups and their access rights, batch-process schedule, configurable business rules, etc.

• B&C system operator—establishes users, monitors back processes, provides system support, and monitors and corrects billing errors.

• Customer service—views a registrar’s billing history and collect information for the B&C manager.

• B&C clerks—creates transactions, such as invoices and collections, but do not make adjustments.

• B&C manager—creates adjustments, catalog changes, and customer changes.

• B&C database administrator—performs database updates, and modifications.

Registrars
Registrars only have “view” access to their B&C account status, account statements, and reports. They have to contact B&C personnel within the registry’s customer support organization for any billing adjustments, custom reports, or special arrangements.

Adjustments—For billing issues or adjustments in profile or account statements, registrars must contact NeuStar’s customer service organization via e-mail, phone, or fax. The B&C manager has the capability of performing any billing adjustments or similar services requested by a registrar.

Notifications and statements—The registry will e-mail to each registrar a detailed monthly transaction statement, an account summary, and a detailed list of all fee-incurring charges.  In addition, the B&C system will e-mail “Low Account Balance” and “Insufficient funds” notifications to any registrar when needed.

B&C system backup and recovery

NeuStar will employ the same backup and recovery procedures for the B&C system that is used for the overall registry system. Proposal Section C17.7 describes these procedures in detail.  They include: 

• Daily backup to DLT Tapes.  The tapes are stored in a secure off-site location.

• Periodic archives of history files and data.  Also stored in a secure off-site location.

If the B&C system fails (i.e., the API interface to the application returns an “Error status”), a built-in recovery mechanism will ensure against loss of transactions and data as follows: the application server will log all undeliverable B&C transactions, with transaction identifiers, to an internal file.  After the problem is corrected, the file will be transferred to the restored B&C system for processing.

B&C audits

NeuStar will provide the infrastructure to collect all data needed for accounting upon request and auditing reports that meet commercially accepted standards, and will provide this data to ICANN-designated auditors upon request.  Data will be available for the current fiscal year and for an agreed number of preceding years.  NeuStar will assist ICANN auditors by providing all required statements and reports. Annually, NeuStar’s internal auditors will audit the registry’s B&C system, records, and supporting documentation to verify the accuracy of billing for registry services.

Data escrow and backup.

Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.

To ensure data integrity, NeuStar will back up the databases in our data centers in Sterling, VA and Chicago, IL, USA and will regularly place escrow copies of the backups in secure offsite locations. These procedures are essential elements of our plans for continuity of operations in the event of system failures and natural or man-made disasters.

Given the potentially devastating effects of such a failure, NeuStar, of course, seeks to avoid ever having to utilize its recovery plans.  NeuStar’s first line of defense against data loss is its highly secure, redundant registry infrastructure.  Responsible operations, however require a recovery plan.

Data recovery procedures must address both small-scale failures as well as more serious total system failures.  The goal of any data backup and recovery procedure is full recovery from failures without any loss of data.  Data backup strategies handle system hardware failures (e.g. loss of a processor or one or more disk drives) by reinstalling the data from daily backups, supplemented by the information on the “before” and “after” image-journal backup files that the database creates.  More serious failures require more aggressive solutions.

The conventional strategy for guarding against loss of an entire facility because of fire, flood, or other natural or man-made disaster is to provide off-site escrow of the registry data in a secure storage facility.  Even when successful, this recovery strategy does not prevent the loss of a certain volume of transactions between the time the data was backed up and the occurrence of the disaster. Users are subject to loss of service during the time required to recover the data center database and/or reestablish operations at an alternate disaster-recovery site.  Relocating the data center normally requires at least 24 hours, and the escrowing of full backups are done only weekly, meaning that a disaster could result in substantial loss of both services and data.  The recovery from daily incremental backups requires additional recovery time. Reducing the risks for data loss.

NeuStar’s solution utilizes two SRS data centers operating in a primary/back-up failover mode. Each SRS data center is capable of handling the entire workload should a major system failure or natural or man-made disaster occur at the other. The transactions from the active data center are synchronized in near real-time with the hot-standby database over a redundant high-speed direct telecommunications links. The active SRS data center conducts full database snapshots from a third mirror of this data twice a day and back up all database transaction logs, as described in the following paragraph. Since the two SRS data centers are synchronized, our back-up strategy maintains continuity of operations and enables full recovery of all transactions, even in the event of multiple hardware failures. 

Frequency and procedures for backup of data 

The active SRS data center implements a zero-downtime/zero-impact incremental data backup each day, and a full data backup weekly. We copy static data (e.g., the operating systems, BIND software, applications software) to CD-ROMs for quick reload, should that become necessary.  We back up to high capacity DLT storage tapes any dynamically changing files (e.g., log files vital to system maintenance and operation, database files, database-journal files, software configurations). Weekly, we perform full-system backups to DLT tape of all databases identified in Section C17.3 (.org DB, Whois, Billing). We will place escrow copies of the backup tapes in a secure off-site storage facility operated by a third party whose business is data escrow. 

The backup procedures include the following 4 steps:

• The database is put into maintenance mode to guarantee a consistent version of the data on the snapshot copy that is written to a RAID disk array for subsequent (slower-speed) copying to tape. While the database is in maintenance mode, the RRP, Whois, and Billing applications continue to function and to access the data.  The database normally is in maintenance mode for only about five to 10 minutes.

• The backup software writes the data to the RAID disk array.

• The backup software, which is located on a backup server independent from the application servers, creates the backup DLT tape copy from the snapshot copy on the RAID disk array.

• When the backup is finished, the DLT tapes are transported to the secure, offsite escrow facility.

Backup hardware and software systems

Exhibit C17-14 depicts the SRS data centers’ backup process.  Each data center’s system includes two backup servers with DLT robotic tape libraries.  To achieve zero-downtime/zero-impact backup, we use a RAID disk array and a high-speed fiber, channel bridge interconnect to the robotic tape libraries. The backup server copies not only the database server’s backup files to the disk array, but also the backup files of the cluster servers.  During the few minutes this process requires, applications still have access to the cluster servers and database server.  Then the backup server copies the files to the DLT robotic tape device. This approach ensures that we meet our Service Level Commitments.

Procedures for retrieval of data/rebuild of the database

We maintain a three-tape rotation to maximize efficiency and effectiveness:

• One DLT backup tape in transit to the secure escrow facility;

• A second DLT tape in storage in the secure escrow facility; and

• The third DLT tape in the active data center for reuse.

The full backup tapes are maintained in a 2-tape rotation, with one tape at the secure escrow facility and one at the active data center for reuse. A copy of the static-data
CD-ROMs for the operating systems and applications will also be maintained at the escrow facility.

In the event of an outage at the primary data center service will failover to the back-up data center.  The back-up data center will have a current copy of the .org database due to the data base synchronization process.  The back-up data center will assume the primary data center’s role and continue SRS operations with the near-zero downtime.  The following steps will be taken to restore the primary data centers:

• Retrieve the full and incremental back-up tapes from escrow;

• Restore the full files;

• Restore the incremental files;

• Synchronize the recovered database from the back-up datacenter; and

• Restore the primary datacenter to operations.

This backup procedure enables NeuStar to meet the service-level agreements required for continuous availability and near-zero unplanned downtime, maintaining stability, enhancing public confidence, and improving customer satisfaction.

NeuStar has reached agreement with Iron Mountain for the third-party provision of data escrow services.  Founded in 1951, Iron Mountain is an Industry leader in data storage and escrow services.

Publicly accessible look up/Whois service.

Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.

NeuStar’s existing Whois provides a reliable, stable, standards-compliant platform for supporting the .org registry. Near real-time updates to the Whois will synchronize updates with the zone file and the .org database to avoid customer confusion

One of the critical functions of a registry is the Whois.  Whois is an administrative tool that provides identifying information related to the domain name.  The protocol is defined in RFC954.  It will be available to anyone via the IANA-assigned port 43 or the .org registry website. 

NeuStar’s current Whois supports a “thick” registry model and the .org Whois supports a “thin” registry model.  The thick registry contains contact information associated with the registrant, whereas the thin model does not.  NeuStar will have to modify its processes associated with Whois and its Whois database for this difference. 

The Whois service will accommodate queries regarding the data sets listed in the following table.

Whois system architecture
NeuStar will deliver a Whois service that incorporates near real-time update, scalable infrastructure, and multiple layers of redundancy.  As shown in Exhibit C17-15, we will deploy two Whois clusters at each SRS data center, for a total of four Whois clusters.  All four Whois clusters are operational and receive queries from the Internet. 

Each Whois server is equipped with a full copy of the Whois database. At each SRS data center, a load balancer to a cluster of two Whois servers distributes incoming queries. The load balancer can also re-route the Whois traffic to its counterpart in the other SRS site if the Whois servers on its site are down. This configuration will provide both redundancy and scalability through the addition of servers to either cluster. Exhibit C17-16 depicts the update process for the Whois databases.

As the .org database is updated, the system will also update the Whois distribution administrator in real time.  This happens on the active SRS site.  Incremental changes made to the Whois distribution database will be propagated to the Whois databases in each Whois cluster in near real time (e.g., no greater than 15 minutes).  Propagation of Whois information between data centers always occurs over the secure VPN. 

The proposed Whois architecture and process offers the following benefits:

• Service can be scaled by adding servers to each Whois cluster;

• Service can be scaled by deploying Whois infrastructure to additional remote sites;

• Inherent redundancy ensures high availability; and

• Update process ensures near real-time availability of the latest information.

Attributes of the Whois servers are:

• RISC 400Mhz CPU;

• 64-bit, 2 to 32-way crossbar SMP, with 8x8 non-blocking multi-ported crossbar;

• 32 GB ECC RAM;

• 240 MB/sec channel bandwidth;

• Maximum internal storage 288 GB;

• Maximum external RAID storage 10 TB;

• Redundant hot-swappable power supplies;

• Dual-attach 100 BaseTX/FX Ethernet Adapter;

• Event management software for remote management; and

• 64-bit Unix operating system.

Network connectivity
The large volume of Whois queries places a significant network-connectivity burden on the registry.  Based on the assumption that each Whois query will generate approximately 10 Kbits of network traffic, we will use the following engineering guidelines for provisioning bandwidth:

• Initially, we will provide 2 Mbits per data center.  The total of 4 Mbits will support approximately 400 queries per second (approximately 35 million requests per day).

• As the volume of registrations grows, we will extend the service at a rate of 1.5 Mbits per one million domain-name registration records under our management.  For example: when the registry manages 6 million domain names, we will dedicate 10 Mbits of Whois bandwidth, which will support nearly 86 million Whois queries per day.

These guidelines will be compared with actual usage data and adjusted accordingly.

We will engineer the Whois service to provide the following average service levels:

• 20 million queries per day.  We will increase this query-service demand based on the total number of domain name registrations managed by the registry, as previously discussed.

• 1,500-millisecond or less response time for 95% of the Whois queries.

We will scale the exact number of Whois and database servers deployed in each cluster and at each data center to maintain the specified service levels.

Search capabilities
Users will be able to search for the following record types:

• Domain name, e.g., icann.org;

• Registrar, e.g, XYZ Registrar; and

• Nameserver, e.g., ns1.neustar.biz or 209.173.53.70.

Coordination with other Whois
NeuStar has been following the progress of ICANNs efforts to provide a more efficient and comprehensive access mechanism to Whois data.  We understand it is possible that ICANN may designate a third party to host TLD Whois data from other registries.  NeuStar is in full support of this effort and agrees to provide copies of .org Whois data sets to the entity designated by ICANN, after ICANN has made such arrangements. 

Full data sets would be provided on a weekly basis and incremental updates would be performed on a daily basis.  NeuStar will deploy an FTP (file transfer protocol) server available for the purposes of exchanging the Whois data sets. 

Conclusion
Whois is an important administrative function of any registry.  NeuStar has developed a highly scalable, high transaction Whois architecture with near real-time update capabilities.  This platform will provide the stability and reliability necessary for the .org community.   

System security.

Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.

NeuStar’s registry offers unparalleled security to the .org community.  The SRS and .org databases are protected by two layers of security and traffic management working cooperatively with an intrusion detection system.  Our nameservers are one of the few protected by a firewall.  A secure VPN interconnects all of our locations and allows us to monitor all traffic and equipment.

High profile Internet operations such as Shared Registration System (SRS) and nameserver sites are subject to a wide range of security threats; including hacking, break-ins, data tampering, denial of service, and physical attacks against the facility.  Further, because the registry will contain proprietary data from competing registrars, security procedures must incorporate user-authentication procedures that ensure each registrar’s files are available only to its own personnel. Failure to address these security threats creates the risks of unscheduled down time and the disruption or denial of services.

NeuStar’s registry solution incorporates comprehensive system security for our networks, servers, applications, and customer support services. Our security architecture is a policy-based, multi-tiered system based on proven industry standards. Our solution, highlighted in the following table, integrates the following security features to provide assurances that multiple security threats or attacks will be unsuccessful:

• Perimeter protection utilizing a combination of network and security technology;

• Application-level security features for the registry-registrar interface and customer-service applications;

• Connection security;

• Data security;

• Intrusion detection system;

• User identification and authentication;

• Continuity of operations; and

• Physical security. 

SRS data center

NeuStar operates highly secure redundant data centers to provide the highest levels of security and service availability.

Network security - two layers of security

Generally, data centers typically fit into one of the following three categories with regard to network connectivity:

1. No external connections—all connections from and to the data center are over a private network dedicated to the data center provider. 

2. Dedicated connections to other entities—the data center interconnects to other entities/companies but does so over a private network.

3. Connected to the public Internet—the data centers are connected to the public Internet.

An Internet registry fits into the third category because its nameservers receive and send traffic to the general public and its SRS data center connects to its registrars over the public Internet.  Because the data center is connected to the public Internet, it is the hardest to protect from a security perspective.  NeuStar has designed a state-of-the-art architecture when it comes to protecting the data center from attacks that can originate on the public Internet. 

NeuStar has deployed a five-layer architecture at its SRS data centers as depicted in Exhibit C17-17.  This architecture is duplicated in both the primary and back-up data center.  The five layers of the architecture are:

• External Network Layer;

• Protocol Layer;

• Internal Network Layer;

• Application Layer; and

• Database Layer.

The two Network Layers—external and internal—are dedicated to security and traffic management.  The equipment at these layers work together with an Intrusion Detection System (IDS) to provide an even greater level of security. 

The External Network Layer is the point where NeuStar interconnects to the Internet.  Each SRS data center is served by two ISPs.  The External Network Layer consists of four redundant servers each performing its own security or traffic management and security function: 

1. Edge router—The edge routers provides Internet connectivity and performs IP-packet filtering. 

2. Traffic shaper—The traffic shaper is an intelligent bandwidth management device.  It has the ability to manage bandwidth on an aggregate basis, on an individual port basis, on an individual registrar basis, etc.  The traffic shaper also performs IP-packet filtering. 

3. Firewall—The firewall is dedicated to perimeter security.  It provides policy-based IP filtering to protect against system hacks, break-ins, and denial of service attacks. The firewall also includes network-based intrusion detection to protect against Internet hackers.

4. Load balancer—The load balancers distribute traffic among the clusters of protocol servers (RRP, EPP, Whois, and Web) in the second layer of the SRS data center.  Load balancing protects our application servers from common denial-of-service attacks; e.g., SYN floods, ping floods, and “smurfs” attacks. Security policies can be based on any combination of source address, destination address, and protocol type or content.

After the Protocol Layer is the Internal Network Layer.  The Internal Network Layer is in place specifically to manage traffic between the Protocol Layer and the Application Layer and to detect and deter any security breach in the unlikely event that it makes it past the first two layers (security at the Protocol Layer is addressed in the server and application security sections).  The Internal Network Layer consists of redundant firewalls and load balancers.  These serve the same security functions identified for the External Network Layer. 

These two layers, coupled with the IDS, create a state-of-the-art security architecture for data centers that interconnect to the public Internet. 

Server security

The SRS operating systems provide access protection through a user login procedure and through file-level access-control lists. These access-control mechanisms perform the following functions:

• User-account security—Establishes the access capabilities of a specific authenticated user. After authenticating a user, each application’s security-data tables control access to information.  Access is based not only on userID, but also on the type of application being used; e.g., RRP, Billing and Collection, etc. The application server uses userID to provide precise control of access privileges to – and uses of (read, write, execute) – all system resources: screens, menus, transactions, data fields, database tables, files, records, print facilities, tape facilities, software tools, and software executables.

• Group-level security—Establishes the access capabilities of all users within a specific group.  All users belong to one or more access-control groups.  Access control is identical to that for individual users.  

• System administration-level security—Restricts access to system administration tools, including the ability to change resource-access privileges. SRS system administration staff use dedicated links on an internal LAN/WAN to access administrative functions that are off limits to others.  There is no external access to this LAN.  All sessions require user identification by user name and password; access control lists determine what resources a user or user group is allowed to access and use. Super-user access is managed through an auditable delegation system.

The SRS operating systems will perform security-relevant logging functions, including:

• User login—Whenever a user login is attempted, whether successful or not, the event is logged.  The logged information includes the userID, time, and device requested.

• User accounting—“User Accounting” logs every process executed by every user.  The output includes date and time, userID, point of entry, process, resources accessed, and result of the operations.   This log may be selectively viewed for actions performed by a specific user or users.

• System logging—This inherent, configurable logging capability permits monitoring the kernel, user processes, mail system, authorization system, etc.  In addition, the operating system detects when file-access privileges have been changed and also audits the use of telnet, finger, rsh, exec, talk, and similar operations.

The following provisions apply to passwords:

• Passwords must be at least six alphanumeric characters in length.  At least one character must be alphabetic; at least one must be a numeric or punctuation character.

• If a user forgets his/her password, the system administrator verifies the user’s identity and then provides the user with a temporary password that enables him/her to log on only to the site where users create their own new passwords.

• Passwords are valid only for a pre-established duration (typically 45 days or less depending on the level of security required).  Prior to password expiration, the system instructs the user to create a new password. 

• When a user changes his/her password, the system first re-authenticates the existing password and then requires the user to verify the new password before accepting the change. The system will not accept, as a user’s new password, the user’s two most recent passwords.

• Passwords are encrypted and stored in an protected system file.

Application security

Each SRS application will have its own set of security processes and technical controls. The SRS applications that interface with the registrars (e.g., the RRP and the Secure Web Customer Service portal) employ the SSL (secure sockets layer) protocol element that uses public-key exchange and RC4 encryption.  Public services (e.g., Whois, DNS queries, and the public Internet Web portal) rely on the previously discussed network perimeter-security devices—edge routers, firewalls, and load balancers—to protect the internal LAN and applications servers.

Security related to applications include:

• RRP applications security—NeuStar’s RRP server will authenticate against a series of security controls before granting service, as follows:

  1. The registrar’s host initiates a SSL session with the RRP server.

  2. The RRP server receives the registrar’s private key with the incoming message and authenticates it against the registrar’s public key, which is stored in the registry’s RRP server. 

  3. After the RRP server verifies the key exchange, it completes the SSL initialization to establish a secure, encrypted channel between itself and the registrar’s host computer.  This secure, encrypted channel ensures the integrity of the registrar’s session with registry applications.

  4. In combination with completing the SSL connection, the RRP server authenticates an X.509 digital certificate to verify the registrar’s identity. Digital certificates are maintained in the SRS authentication server database. 

  5. The registrar logs on to the RRP server using a userID and password that determines access privileges.  NeuStar will provide each registrar with multiple userIDs and password pairs, so that each can establish its own group of authorized users.

• Whois application security—Although any Internet user has read-only access to the Whois server, NeuStar’s perimeter-security mechanisms—edge routers, firewalls, and load-balancers—will protect it against denial-of-service attacks. A designated registry administrator performs common database-administration tasks on the Whois database, including monitoring its performance.

• Nameserver security—All Internet users have read-only access to the nameservers.  Similarly, the edge router, firewall, and load-balancers protect the nameservers as they do the Whois servers.

• Secure web customer service portal—The secure web customer service portal uses the same security mechanisms employed by the RRP server; namely, SSL session encryption, digital certificates, and userID and password between the SRS secure web server and the registrars’ Web browsers. In addition, e-mail messages are encrypted with a Pretty Good Privacy (PGP) public-key-infrastructure implementation. Digital certificates are maintained in the authentication server.

Nameserver site security

NeuStar’s approach to nameserver security is a subset of the security mechanisms we employ at the SRS data centers. NeuStar’s nameserver sites are one of the only TLD nameservers that utilize a firewall for security. Most registries believe the inherent security of the DNS protocol provides sufficient security.  NeuStar believes that the importance of the service being provided demands the utmost level of security.  Like the SRS data center, the Nameserver site security also relies on multi-layer perimeter protection, controlled access, enforcement of applications security features, and strong physical security protection.  Exhibit C17-18 depicts NeuStar’s nameserver architecture.

Network security

The same mechanisms used for the SRS data center are employed at the Nameserver sites. Edge routers and firewalls provide perimeter protection for the data-center network and applications systems, guarding against unauthorized access from the Internet.

• Edge router—The edge routers employs IP-packet filtering to allow only DNS UDP/TCP packets to pass into and out of the perimeter network. 

• Firewall—The firewall provides policy-based IP filtering to protect against system hacks, break-ins, and denial of service attacks. It also includes network-based intrusion detection to protect against Internet hackers.

• Load balancer—Managing the server load protects our application servers from common denial-of-service attacks; e.g., SYN floods, ping floods, and “smurfs” attacks. Security policies can be based on any combination of source address, destination address, and protocol type or content.

• Intrusion detection system—The IDS monitors and logs every packet and analyzes the patterns for external attacks. 

The SRS data centers are connected to the nameservers over an IPSec VPN to perform database updates at the nameservers, network-based backup/restore, remote system/network management, and system administration.  Keys used to access the VPN are rotated frequently.  VPN technology achieves secure data transfer through encrypted data-communications links.

Server security

The nameserver operating systems provides access protection for remote system administration through a user login procedure and through file-level access-control lists. These access-control mechanisms perform the following functions:

User-account security—Establishes the access capabilities of a specific system administration authenticated user. After authenticating the user, the operating system’s access control lists control access to information.

System administrator level securityRestricts access to system administration tools, including the ability to change resource-access privileges. Nameserver system-administration staff use dedicated links on an internal LAN/WAN to access administrative functions that are off-limits to others.  There is no external access to this LAN.  All sessions require user identification by user name and password; access control lists determine what resources a user or user group is allowed to access and use.

The nameserver operating systems will perform security-relevant logging functions, including:

• User login—Whenever a user login is attempted, whether successful or not, the event is logged.  The logged information includes the userID, time, and device requested.

• User accounting—“User Accounting” logs every process executed by every user.  The output includes date and time, userID, point of entry, process, resources accessed, and result of the operations.  This log may be selectively viewed for actions performed by a specific user or users.

• System logging—This inherent, configurable logging capability permits monitoring the kernel, user processes, mail system, authorization system, etc.  In addition, the operating system detects when file access privileges have been changed, and also audits the use of telnet, finger, rsh, exec, talk, and similar operations.

Application security

The nameserver essentially enables the public, via the Internet, to make DNS queries. Public services, such as DNS queries, rely on the previously discussed network perimeter-security devices—edge routers, firewalls, and load balancers—to protect the internal LAN and application servers.

Physical security

NeuStar vigorously enforces physical-security measures, controlling all access to our facilities.  Throughout normal working hours, security personnel stationed at each building entrance verify that employees are displaying proper identification badges and control access by non-employees.  Non-employees must sign in to gain entrance; the sign-in books are stored for a period of one year.  If the purpose of his/her visit is found to be valid, the non-employee is issued a temporary badge; otherwise, he or she is denied entrance.

At all times while they are in the facility, visitors must display their badges and must be escorted by a NeuStar employee.  We also strictly enforce the policy that employees must wear their badges prominently displayed at all times while in the facility.

During off-hours (6:30pm to 6:30am and all day on weekends and major holidays), individuals must use the proper-electronic key cards to gain access to the building.  We issue electronic-key cards only to employees who need access for business purposes.  Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only by individuals who activate a hand geometry reader.  Senior managers establish the rights of employees to access individual rooms, and ensure that each reader is programmed to pass only those authorized individuals.  We grant access rights only to individuals whose duties require them to have hands-on contact with the equipment housed in the controlled space; administrative and customer-service staffs normally do not require such access.  The hand geometry readers compile and maintain a record of those individuals who enter controlled rooms. 

Access in and out of the data centers is monitored 24x7x365 by the network operations center (NOC).  All access is recorded and stored for three days on digital video.  There are audible alarms on doors in the event of unauthorized entry or if the doors are kept open for more than 30 seconds. 

Peak capacities.

Technical capability for handling a larger-than-projected demand for registration. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.

NeuStar has built capacity into our existing registry to support estimated peak traffic demand.  Our network connectivity has been designed to automatically scale as demand increases and our servers (SRS and nameserver) have been designed in a cluster configuration to easily and seamlessly add capacity.  Furthermore, we have implemented two layers in our registry architecture dedicated to security and traffic management to be able to manage highly volatile traffic demand.  The peak load capacity and built-in scalability of the NeuStar registry ensures ICANN that adequate capacity is available to handle the current and future demand of the .org registry.

To avoid creating bottlenecks for SRS, Whois, and nameserver services, NeuStar will engineer for peak usage volumes, based on the most recent statistics published for the .org registry.  In addition, NeuStar will deploy redundant SRS data centers and a network of nameserver sites that are sized to handle the current peak volumes. Subsequently, we will add additional nameservers to handle the anticipated growth. Our SRS, Whois, and nameserver architectures are designed with highly scalable server clusters and connected through networks that can be smoothly scaled up without disrupting the system.  Expansion provisions include the following:

• Servers scale from Intel SMP machines to high-end RISC SMP database platforms with shared-memory architectures;

• Server processors scale to 2-way SMP for the medium-range Intel machines, and from 2-way to 32-way SMP for the high-end RISC database machines;

• The number of servers in a cluster can conceivably, scale beyond 32 servers;

• The external telecommunications-network connectivity to the SRS and nameserver sites scales from dual T-3 to quad T-3 and more as a function of the SRS transaction load and the Whois and DNS query loads; and

• The internal SRS and nameserver LANs consist of a switched Fast Ethernet backbone fabric with extensive port expandability.

SRS peak capacity
The SRS provides the core subsystems that handle registrar transaction-based services, including RRP processing, billing and collection, Secure Web portal, and backend database system services. This subsection describes the SRS subsystems peak capacity in terms of sizing and scalability of the network, server, and database platforms to specifically address the ability of the registry to handle larger-than-projected volumes of registrations. 

Network—The RRP peak transaction load is projected to be 350 transactions per second (tps), or a little more than 1.2M transactions in a peak hour.  Our registry’s network connectivity has enough capacity to support transaction six times that volume or 2,100 tps. The average transaction size is 5,000 bits, which translates to a required telecommunication capacity of 10.5 MBPS.  Our external communication network connectivity to the Internet is two T-3 (45-MB)
local-access links for a total of 90 MB, at each data center, to handle RRP transactions and Whois queries.  The registry’s Virtual Private Network (VPN) between the sites consists of two ATM links.  The VPN handles zone-database updates, server backup/restore, system/network management, and system-administration functions and can grow well beyond 90MBs.  

Server clusters—The RRP server cluster and the associated application server clusters are front ended with load balancers that distribute the transaction processing workload across the servers in each cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.

The RRP server and application server clusters are sized to handle six times the projected steady-state workload, or 2,100 peak transactions per second.  The processing capacity can grow linearly by adding additional servers to the cluster. The total system capacity is a cluster size of 32 SMP 8-way RISC servers. 

The Billing and Collection system is sized to handle 350 peak transactions per second, because not every RRP transaction results in a billable event.

Database system—The database system consists of dual high-end RISC machines, each with 2- to 32-way SMP scalability. The processing capacity of the database system is
4-way SMP.

The database system can grow to handle eight times the initial projected volume of transaction loads. NeuStar will closely monitor system usage, and will scale the database capacity correspondingly.

Whois peak capacity
NeuStar will increase network bandwidth and add high-performance database capabilities to the Whois service infrastructure.  This subsection describes the Whois-subsystems peak capacity in terms of initial sizing and scalability of the network, server, and database platforms. 

Network—The peak Whois transaction rate is estimated to be 350 queries per second, with an estimated packet size of 10,000 bits. This produces a maximum load of 3.5 MBPS.  Initially, we will provide communication-network connectivity for Whois queries between the Internet and each data center as two T-3 Internet Service Provider (ISP) local-access links (shared with the RRP traffic).  Although these links initially will not be used at full capacity, they ultimately can carry 90 MBPS per data center before we upgrade to larger links.

Whois server cluster—Our Whois server cluster is front-ended with load balancers to distribute the transaction-processing workload across the servers in each cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.

The Whois server cluster in each SRS data center consists of four Whois database servers, each of which has its own copy of the Whois database.  The two load balancers in the two respective SRS data centers are also connected via internal network for failover purpose. If the Whois server cluster on one data center fails, the load balancer on that site can re-route the Whois traffic to the load balancer on the other site without Whois service interruption. To improve query response time and lighten the load on the database, the Whois servers cache frequently accessed domain names.

The processing capacity can grow linearly by adding additional servers to the cluster. The total system capacity is a cluster size of 32 SMP 6-way Intel servers.  NeuStar will closely monitor Whois usage and will increase the system’s capacity to accommodate increasing demand.

Database system—The Whois database servers are dual mid-range RISC machines, each with 2-way SMP scalability.  The total processing capacity will be 350 tps, scalable to 1000 tps. 

DNSQuery peak capacity
NeuStar’s registry handles DNS queries at the nameservers.  This subsection describes the nameservers’ peak capacity in terms of the network, server, and database platforms sizing and scalability.  NeuStar’s design will easily scale as load increases. 

Network—NeuStar has provisioned at least 2MB of bandwidth at each of our six nameserver sites.  With an average DNS packet size of 1,600 bits this will accommodate 2MBs will accommodate over 1,200 queries per second at each nameserver site.  Each namseserver site is equipped with additional bandwidth, so that growth can be implemented rapidly.   In addition to the extensive bandwidth provisioned and the easy growth, NeuStar will deploy two more nameserver sites for .org, one in Europe and one in Asia. 

Nameservers—Our DNS nameserver cluster will be front ended with load balancers to distribute the transaction processing workload across the nameservers in the cluster.  Distribution algorithms including least connections, weighted least connections, round robin, and weighted round robin.

The nameserver cluster is sized to handle three times the projected steady state workload, or 5,000 queries per second.  To improve query response, the entire zone will be held memory resident.

Processing power can grow linearly by adding additional servers to the cluster up to its total system capacity: a cluster size of 32 Intel 2-way SMP servers.  NeuStar will closely monitor system usage, and will scale up as required.

Zone file update—All nameservers are Intel machines with 2-way SMP scalability. They are configured as secondary nameservers for zone file update.  Zone file update is performed in near real-time by the master nameserver at the SRS data center. Proposal Sections C17.4 and C17.5 describe the zone file update and distribution process.

Miscellaneous servers and personnel
NeuStar backup/recovery systems, escrow systems, system/network management, and system administration systems are enterprise strength hardware and software platforms that can easily be scaled to meet our high growth estimates throughout the entire registry operations lifespan. Additional desktops/workstations can be added to accommodate growth in staff and registry workload as usage increases and the registry infrastructure grows. Our maintenance support, help desk, and technical support functions are staffed for the peak usage period, and staff can be increased to handle workload surges caused by registry marketing and promotional events.

Technical and other support.

Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support, support services to be offered, time availability of support, and language-availability of support.

NeuStar’s registry provides 24x7x365 customer support in six languages.  Our experienced customer support staff has helped registrars with the most complex issues such as testing, problem resolution and accreditation.  To make our support more effective we have augmented it with e-mail, web portal information, and a registrar test environment.

NeuStar is committed to provide uninterrupted technical support for registry services, as well as for continuous registry operations to ensure seamless transition of the .org registry. Our technical support will be made available to all ICANN-accredited .org registrars worldwide on a 24x7x365 basis.

Technical help systems

Registrars have a great deal of internal technical capabilities because of their need to support an IT infrastructure for their marketing and sales efforts and for their customer-support and billing and collection services.  NeuStar will enhance these registrar capabilities by providing the registrars with the following types of technical support:

• Web-based self-help services, including:

  • Frequently asked questions

  • White papers

  • Downloads of RRP client software (EPP is to be supported in the future)

  • Support for e-mail messaging

• Telephone support from our central Help Desk

• Fee-based consulting services. 

To maximize a competitive market amongst registrars, all support will be available on a 24x7x365 basis.  Further NeuStar currently provides support in French, German, Spanish, Italian, Korean and English.  We will continue to support additional languages where possible.

Web portal
NeuStar will implement a secure Web-based multimedia portal to help support registrar operations.  To obtain access to our Web-based services, a .org registrar must have implemented our security features (including SSL encryption), log in with userID and password, and digital certificates for authentication.

The home page of the web portal will include a notice to registrars of planned outages for database maintenance or installation of software upgrades.  This notification will be posted 30 days prior to the event in addition to active notification including phone calls and e-mail.  We will also record outage notifications in the help desk database to facilitate compliance with the service-level agreement. Finally, seven days and again two days prior to the scheduled event, we will use both an e-mail and a Web-based notification to remind registrars of the outage.

Non-affiliated registrars, registrants, and the general Internet community may obtain generic information from NeuStar’s public Web site, which will describe our .org registry service offerings, list ICANN-certified registrars providing domain-name services, and access to the .org Whois.  Please see Proposal Section C25 and C35 for more details.

Central help desk
In addition to implementing the web site, we will provide telephone support to our registrars through our central Help Desk. Access to the help desk telephone support is through an automatic call distributor that routes each call to the next available customer support specialist.  Requests for assistance may also come to the Help Desk via e-mail, either directly or via the secure Web site. 

The help desk’s three tiers of support are:

Tier-1 Support—Telephone support to registrars who normally are calling for help with customer domain name problems and other issues such as RRP implementation or billing and collections.  Problems that can not be resolved at Tier 1 are escalated to Tier 2.

Tier-2 Support—Support provided by members of the technical support team, who are functional experts in all aspects of domain name registration.  In addition to resolving escalated Tier 1 problems with RRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing. 

Tier-3 Support—Complex problem resolution provided by on-site maintenance technicians, third-party systems and software experts, and vendors, depending on the nature of the problem.

In turn, the Help Desk uses an automated system to collect call statistics and record service requests and trouble tickets in a help desk database.  The help desk database documents the status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being breached.  Each customer support and technical support specialist uses our problem management process to respond to trouble tickets that includes troubleshooting, diagnosis and resolution procedure, and a root-cause analysis.

Escalation policy
Our escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they are not resolved within the escalation-policy time limits. The following table is an overview of our escalation policy.

Test and evaluation facility

NeuStar will establish an operational test-and-evaluation facility that will be available 24x7x365 for registrars to test their client RRP system. Our technical support team, which consists of functional experts in the processes and technologies for domain name registration, will support the registrars’ testing.

Once a registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineer. After a registrar has passed the acceptance test, we will issue its userID, passwords, and digital certificates, and the registrar can begin operations.

Compliance with specifications.

Describe the extent of proposed compliance with technical specifications, including compliance with at least the following RFCs: 954, 1034, 1035, 1101, 2181, 2182.

NeuStar’s registry operations are fully compliant with all applicable industry standards—a key component of registry stability.

The success of the Internet as a whole is largely due to the open nature of the standards that govern much of its operation.  As NeuStar has noted elsewhere in the proposal, compliance with core industry standards related to registry operations is critical to the provision of stable and responsive services.  Internet users rely on various aspects of a registry to act in well-defined ways.  For example:

• Internet users rely on the registry’s nameservers to resolve domain names according to set protocols;

• Registrars rely on the registry’s SRS to manage the domain names registered by the registrants; and

• Many users rely on the registry’s Whois server to identify important information about domain names. 

Industry standards ensure that the registry develops such capabilities in a consistent manner while providing guidelines on how users can expect the services to work.  Also, the vast majority of devices that use the Internet for communications; routers, firewalls, e-mail servers, web browsers, instant message servers, and voice over IP servers (to name a very small subset) rely on consistent protocols to interoperate globally and route necessary messages regardless of geographic distribution and variations in hardware.

While some registries may decide, for various reasons such as cost or to gain a perceived competitive advantage, to deviate from accepted Internet standards, they may find that these savings or advantages are illusory as they ignore the collective learning of Internet operations experts embodied in those standards.  For example, a registry could choose to deploy secondary nameservers in only one location to save real estate leasing cost.  This decision would, of course, be in direct violation of RFC 2182 which states:

A major reason for having multiple servers for each zone is to allow information from the zone to be available widely and reliably to clients throughout the Internet, that is, throughout the world, even when one server is unavailable or unreachable.

In the event of some single disaster or other unforeseen event, that registry might lose its entire nameserver network.  Following the standard would have avoided such an outcome.  NeuStar has deployed a constellation of six nameserver sites at locations around the world including North America, Europe and Asia.  We plan to add two new sites, one in Asia and one in Europe to support the .org community. 

Similarly, a registry might choose to deviate from industry standards by creating new resource records or new resolution capabilities to provide what the registry believes is new or enhanced proprietary functionality.  Unfortunately for such a registry operator, DNS resolver developers rely on the standards set forth in RFCs 1034, 1035, and 2181 to ensure proper resolution of domain names.  Resource records that deviate from the precepts of these standards may simply not work, causing increased resolution failure and corresponding decreased reliability.  This scenario actually occurred with respect to the provisioning of an internationalized domain name capability.

NeuStar has always relied on industry standards for the services it provides.  In some cases, such as the local number portability administration system, NeuStar lead the industry in a very specific effort to develop these standards.  In other cases, like the TLD registry, we can rely on a very significant and detailed set of standards existing in the industry. 

NeuStar’s current registry is fully compatible with all of the industry standards identified by ICANN;

• RFC954—which defines the Whois protocol;

• RFCs:1034. 1035 and 2181—which collectively define the core concepts and protocols of the domain name system;

• RFC2182—which is a Best Current Practice for the selection and operation of secondary nameservers; and

• RFC1101—which defines the name and number mapping capability.  (We do not, however, support the Yellow Pages functionality defined in this RFC because it is experimental, not widely deployed, and not considered a requirement for a registry.)

NeuStar’s .org registry will also be fully compatible with all of these standards, as well as Informational RFC 2832 governing the RRP protocol.

System reliability.

Define, analyze, and quantify quality of service.

To provide a seamless transition of and continuous access to .org registry data and applications, NeuStar utilizes redundant SRS data centers, geographically separated and continuously on-line. Each data center incorporates redundancy and high-availability features in their hardware, software, and network configurations. We offer a service-level availability of 99.9% for the SRS services and 99.999% for the DNS-query services. NeuStar has already implemented this solution which delivers reliable registry operations with negligible unplanned downtime for its existing registry systems. This solution ensures ICANN that NeuStar will maintain and/or exceed the system reliability performance of the current .org registry.

NeuStar recognizes that ICANN requires that the .org registry go through a seamless transition without degraded performance and system reliability. Users of the .org community cannot afford to lose access to mission-critical applications, nor can they tolerate system failures that lead to excessive downtime and denial of service because of a new, possibly unqualified registry operator. They demand the same or better service quality when and after the .org registry is transitioned from the current operator to another operator.

NeuStar is fully committed to deliver unparalleled system reliability and availability for the .org registry using state-of-the-art technologies. We propose redundant data centers for the .org registry operations and a network of nameservers for DNS queries.  These facilities are geographically dispersed to minimize the possibility of outages caused by natural or man-made disasters. The nameservers are interconnected to each data center via a Virtual Private network (VPN) backhaul link. As previously shown in Exhibit C17-2 indicates, the two data centers are interconnected by a redundant, high speed VPN.

The two .org databases are synchronized in near-real time. At any time, only the active .org database is processing transactions for the registry. All transactions are logged on the active site. The transaction log is periodically pushed to the backup data center via the VPN if either of the following two conditions is met:

• The lapsed time has reached a predefined value (e.g., 3 minutes) since the last push; or

• The transaction log size has reached a predefined value (e.g., 10 Mbytes) since the last push.

Upon receipt of the log, the .org database on the backup site applies the log to synchronize with that of the primary site. So the .org databases on the two sites only differ in the latest transaction log on the active SRS site.

Each data center will have redundant network components, high-availability server clusters, and fault-tolerant database servers to eliminate single points of failure. All critical telecommunications access links and network components – e.g., routers, firewalls, LAN switches, and server NIC cards will be redundant. Anything less would be inadequate to provide the service levels that ICANN and the industry require.

Defining and quantifying quality of service

NeuStar defines quality of service as high-availability of all registry functions as perceived by the registrars, registrants, and end users. In this context, system availability is a function of both reliability (hardware and software components) and performance (response time, throughput, etc.). Other related factors include system management, diagnostics, maintenance; quality certified software; and database backup and recovery procedures. 

NeuStar currently commits to the following service levels for its existing registry services:

Service availability, SRS—The amount of time in a month that registrars are able to initiate sessions with the registry and perform standard daily functions such as adding a domain name, transferring a domain name, etc.  NeuStar commits to SRS service availability of 99.9%.

Service availability, Nameserver—The amount of time in a month that Internet users are able to resolve DNS queries to the TLD nameserver network.  NeuStar has engineered the nameserver service for 99.999% availability.

Service availability, Whois—The amount of time in a month that Internet users are able to initiate a Whois query to the .org Whois service and receive a successful response.  NeuStar has engineered the Whois service for 99.95% availability.

Update frequency, Zone file—The amount of time it takes for a successful change to zone file data to be propagated throughout the .org nameserver network.  NeuStar has engineered the updates to take place in near real-time and no longer than 10 minutes.  Our committed service levels is 15 minutes or less for 95% of the updates.  

Update frequency, Whois—The amount of time it takes for a successful change to Whois data to be propagated throughout the .org Whois Databases.  NeuStar has engineered the updates to take place in near real-time and no longer than 10 minutes.  Our committed service levels: 15 minutes or less for 95% of the updates.

Processing time; add, modify, delete—The time from when the registry receives an add, modify or delete action to when it acknowledges the action.  NeuStar has engineered for 3 seconds or less for 95% of the time. 

Processing time; query a name—The time from when a registry receives a query to when it returns a response.  NeuStar has engineered for 1.5 seconds or less for 95% of the time. 

Processing time; Whois—The time from when the registry receives a Whois query to when it returns a response.  NeuStar has engineered for 1.5 seconds or less for 95% of the time. 

In addition to these service level agreements (SLAs), there should also be SLAs for administrative functions such as scheduled service unavailability notification, unscheduled service unavailability notification, etc. 

We are confident that our experience, engineering and operational expertise will deliver the highest reasonable level of service attainable.  We will commit to the same high service level as our other registry services.  For more detail on our service levels please see Proposal Section C28.

Analyzing quality of service

NeuStar uses system/network-monitoring capabilities and cluster-management fault-detection services to gather systems and network performance statistics and to track device/process/interface availabilities.  The system stores this data in a local database, then generates a wide variety of pre-programmed and custom reports that enable us to:

• Track system compliance with SLAs;

• Perform performance management and track system performance and resource utilization;

• Perform trend analyses; and

• Perform capacity planning. 

We generate detailed reports on component availability, circuit-utilization levels, and CPU loads at the servers and routers. We summarize performance data and compare it to SLAs.  We will make performance statistics for the previous year available online; statistics from earlier years will be available from data backup files.

For the .org registry service, NeuStar will also employ the statistics-generating and statistics-reporting capabilities inherent in BIND version 8.3.1.  BIND 8.3.1’s statistics-logging function reports, at selected intervals, the number of queries processed by each server, categorized by query type.  We will automatically collect and generate online reports, detailing DNS query/response loads both on individual servers and the entire system.  By deploying application-, systems-, and network-level statistics-collection and capacity-planning tools, NeuStar can provide comprehensive reporting and trending information to ICANN, if requested.

System outage prevention.

Procedures for problem detection, redundancy of all systems, back up power supply, facility security, technical security, availability of back up software, operating system, and hardware, system monitoring, technical maintenance staff, server locations.

NeuStar’s redundant data centers and high-availability server cluster architecture will maintain continuous operations with no disruptions in service. The benefit to ICANN and the .org community will be a seamless transition and stable registry operations with improved system availability, minimum downtime, and high user confidence.

The .org Internet community supporting over two million registrants and millions of DNS queries daily requires outage prevention measures specifically designed to minimize system downtime. Downtime can be categorized as either unplanned or planned:

• Unplanned downtime is caused by failures (e.g., external telecommunications failures, power failures, or internal-network or computer-equipment failures).

• Planned downtime occurs when the system is unavailable due to scheduled maintenance (e.g., software or hardware upgrades and system backups).  Planned downtime is normally minimized in two ways:

  • By performing backups, maintenance, and upgrades while the system remains operational; and

  • By reducing the time required to perform tasks that can be performed only while the system is down. 

In addition to employing the preceding measures for minimizing planned downtime, NeuStar has deployed redundancy and high-availability system architectures designed to minimize unplanned outages.

NeuStar’s existing service level commitments are designed for critical infrastructure registry services such as those required for .org.  We have designed a high-availability architecture that combines the following approaches to satisfy the service level requirements:

• Redundant data centers with near real-time one-way transaction replication;

• High availability server cluster architecture;

• Hot backup and recovery; and

• Automated disaster recovery provisions.

Procedures for problem detection and resolution
To best meet data center requirements for availability, flexibility, and scalability, NeuStar has designed a high-availability architecture that will combine multiple computers into a cluster. Nodes in the cluster will be loosely coupled, with each node maintaining its own processor, memory, operating system, and network connectivity. Our system/network-management and cluster management tools will automatically detect and compensate for system and network faults and notify system operators.

At five minute intervals, the network management system “pings” network devices using the Simple Network Management Protocol (SNMP) for availability and for performance statistics.  Event threshold violations or error conditions will initiate a sequence of alerting events, including visual notifications via a topology map, an entry into a log of event records, e-mails to a bulletin board, and notices to technical support staff. The goal is to detect and repair potential problems before services are disrupted.

An SNMP daemon is configured to periodically check the status and health of vital server processes.  In the event of a critical process failure, the SNMP agent will send a trap to the network management system, initiating an alert to the technical support staff.  Our network management software will include remote monitoring and management of operations, so technical support staff can easily diagnose and troubleshoot network faults, either from the Network Operations Center or remotely. Once a problem is detected, it is resolved using our proven problem management process. In conjunction with this problem management process, we will employ proactive performance management and trend analysis processes to conduct root cause analysis and discover performance and utilization trends that could lead to potential problems.

Our cluster management software, monitors the health of each node and quickly responds to failures to eliminate application downtime, in the following components:

• System processors;

• System memory;

• LAN media and adapters;

• System processes;

• Applications processes; and

• Disk drives.

Since high availability is a primary design goal, a cluster cannot have a single point of failure; accordingly, NeuStar employs RAID mirrored disk drives and multiple LAN connections. The cluster management software monitors these hardware and software components and responds by allocating new resources when necessary to support applications processing. The process of detecting failures and restoring the applications service is completely automated; no operator intervention is required.

Redundancy of data centers and systems
NeuStar uses redundant data centers one in Sterling, VA; USA, the other, in Chicago IL, USA.  These data centers are interconnected by redundant, high-speed, and secure telecommunications links to provide one-way replication of all registry database transactions from the primary site to the back-up site.

Within each data center, the system is redundantly configured so that failure of any system component will leave a configuration of surviving system components capable of executing the entire workload within 95 percent of the previous performance for 100 percent of users.  To achieve “no single point-of-failure” architecture, NeuStar replicates all components and configures the system for automatic failover.

The following table describes system architecture redundancy employed at each SRS data center to meet 99.9% service availability.

Hot repair of system components
Another advantage of system redundancy is that it will enable our maintenance staff to use hot repair replacement of system components. Keeping the system in full operation while we perform such common system-administration tasks as upgrading the hardware or software will reduce NeuStar’s overall Mean Time To Failure (MTTF) while minimizing the Mean Time to Recovery (MTTR).  Hot repair is only possible when major system components are redundant, as in the NeuStar solution.

Backup power supply
Each SRS data center and nameserver site is provided with UPS power in the event of brief electrical transients and outages.  For more than brief outages, the primary data center has a 1,250 KVA motor-generator capable of running the entire data center in the event of a lengthier electrical blackout.  Service agreements are in place with diesel fuel providers for extended power outages

Facility security
As discussed in Proposal Section C17.9, NeuStar vigorously enforces physical security measures, controlling all access to our facilities.  Throughout normal working hours, security personnel stationed at each building entrance verify that employees are displaying proper identification badges and control access by non-employees.  Non-employees must sign in to gain entrance; the sign-in books are stored for a period of one year.  If the purpose of a non-employee’s visit is found to be valid, he or she will be issued a temporary badge; otherwise, entrance will be denied. At all times while they are in the facility, visitors must display their badges and must be escorted by a NeuStar employee.  We will also strictly enforce the policy that employees wear their badges prominently displayed at all times while in the facility. During off-hours (6:30pm to 6:30am and all day on weekends and major holidays), individuals must use the proper-electronic key cards to gain access to the building.  We issue electronic key cards only to employees who need access for business purposes.

In addition to being stationed at building entrances during normal working hours, on site security personnel are on duty 24x7x365 to monitor the images from closed-circuit television cameras placed strategically throughout the facilities.  Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only by individuals who activate a hand geometry reader.  Senior managers establish the rights of employees to access individual rooms, and ensure that each reader is programmed to pass only those authorized individuals.  We grant access rights only to individuals whose duties require them to have hands-on contact with the equipment housed in the controlled space; administrative and customer-service staffs normally do not require such access.  The hand geometry readers compile and maintain a record of those individuals who enter controlled rooms. 

The following table lists our physical security mechanisms.

Technical security
Proposal Section C17.9 also describes the technical security measures that NeuStar uses.  We use the underlying userID and password security features of the RRP, supplemented by system-based Public Key Infrastructure (PKI) services to provide additional security. The following table lists the systems, protocols, and devices to prevent system hacks, break-ins, data tampering, and denial-of-service attacks. 

Availability of backup software, operating system, and hardware
Proposal Section C17.7 describes NeuStar’s zero-downtime/zero-impact backup process, which uses backup servers, disk array, and a DLT robotic-tape library.  The dedicated backup system is independent of the registry server clusters that run the applications.

System monitoring
The subsection entitled “Procedures for Problem Detection and Resolution” describes system-monitoring capabilities and procedures.  Our network management system and specialized element managers monitor specific routers, LAN switches, servers cluster, firewalls, applications, and the backup servers.  In addition, the cluster-management software monitors the status and health of processor, memory, disk, and LAN components in the high-availability cluster.

Technical maintenance staff
The three-tiered NeuStar customer service approach ensures that all problems are resolved by the appropriate party in a timely manner. 

The Technical Support Group will operate out of the Help Desk Network Operations Center (NOC) within the data centers.  The group will be comprised of system administrators, network administrators, database administrators, security managers, and functional experts in the .org registry IT systems and applications infrastructure.  Registrars access the Technical Support Group through the Tier-1 Help Desk.  This group will resolve trouble tickets and technical problems that have been escalated to them by the Help Desk Customer Service Agents. If the problem involves a hardware failure, the Technical Support Group will escalate the problem to our Tier-3 on-site maintenance technicians, third-party maintenance providers, or our hardware vendors, depending on the nature of the problem.  For more detail, please see Proposal Section C17.11

Server locations
NeuStar’s registry servers will be located in the SRS data centers in Sterling, VA, USA, and Chicago, IL, USA.  Two nameserver sites will be co-located with the registry data centers; the remaining nameserver sites will be geographically dispersed connected to the data center high-speed VPN links.  Please see Proposal Section C17.1 for more detail.

System recovery procedures.

Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures, the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation, the availability of the hardware needed to restore and run the system, backup electrical power systems, the projected time for restoring the system, the procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.

NeuStar is proposing two redundant SRS data centers and a network of six nameserver sites geographically dispersed to provide redundancy and to enable us to responsibly recover from unplanned system outages, natural disasters, and disruptions caused by human error or interference with minimal or no loss of services.

To maintain public confidence in the Internet, ICANN requires a high level of system-recovery capabilities.  Proven industry solutions to the problems of outages and disaster recovery incorporate high-availability system architectures and fast failover from the primary data center to a mirrored-backup.  High-availability solutions minimize downtime, with availability of 99.9 percent or greater. Continuously available solutions go a step further, with virtually zero downtime creating an availability of approximately 99.999 percent (five nines).

Possible system-recovery architectures include:

• Symmetric replication—The database replicate (on the backup or failover system) is identical to the primary database on the production system because any change made to the primary database is “replicated” in real time on the backup database. Since this is not a “two-phase commit” process, a small window of vulnerability exists, during which changes made to the primary system could be lost in transit.  Replication may increase transaction times, but switching from the primary database to the backup can be very fast and essentially transparent to end-users.

• Active/hot-standby databases—This is a special case of replication.  A standby database at a backup site originates as an identical copy of the primary database. Changes (updates, inserts, deletes) to the primary database are recorded in transaction logs that are periodically archived. Archived logs are delivered to the backup site and applied to the standby database.

• Remote data mirroring—This is the classic disk-mirroring procedure, except conducted at a long distance. Depending on whether hardware or software mirroring is used, the performance impact can vary from minimal to significant. Switchover to the backup site can be quick and virtually transparent to end-users. The loss of data is zero, although a “system crash” type of database recovery is needed.

NeuStar’s system-recovery solution is based on running mission-critical SRS applications at two active/hot-standby data centers that are geographically dispersed, with database replication technology that maintains database synchronization between the two centers near real-time. To provide backup for DNS queries, we are implementing multiple nameserver sites, also physically separated by long distances. We recognize that system management and recovery are more difficult when the system spreads over a large geographical area; however, active/hot-standby SRS data centers will keep the registry master databases synchronized up to the latest transaction log. 

Restoring SRS operations in the event of a system outage

Believing that prevention of failure is better than restoring after failure, to maximize availability and eliminate the possibility that a single-point failure could shut down operations, we implemented each of the two SRS data centers and six nameservers with:

• Redundant components with no single point of failure;

• High-availability cluster architecture;

• Load balancers, which are used primarily to distribute the processing load across multiple servers, will defend against common denial-of-service attacks that can precipitate outages caused by processor overloads;

• Fault-tolerant hardware; and

• Data backup/restore systems that work together to avoid unplanned outages.  (Naturally, the primary function of these systems remains quick recovery, should such an outage occur.)

The recovery mechanisms we will implement include:

• Full backup and continuous, incremental backup CD-ROMs and DLT Tapes are maintained at the data center and at the secure escrow facility.  These backups enable us to recover, rebuild, and return to operation the operating system, application software, and databases.

• Processor nodes in the cluster are monitored and controlled by cluster-management software to facilitate recovery of software applications in the event of a processor failure.

• In the event of a database failure, fault-tolerant database software fails over to the replicated backup database, enabling applications using database services to recover operations seamlessly.

• Processors in high-availability clusters have dual attach ports to network devices and RAID disk arrays, enabling them to recover from a failure in a single port or disk drive.

• Our high-availability clusters are sized to run at peak load. If a processor fails, the excess capacity in the cluster handles the full processing workload while the failed node is repaired or replaced.  In essence, this is instantaneous recovery.

The remainder of this subsection describes how we would recover from a system-wide disaster (e.g., one that disables an entire data center). Proposal Subsection C17.15.3 discusses recovery from various types of component failures. 

System-wide disaster recovery
Each of the SRS data centers is sized to take over the entire load of the SRS operations, and each nameserver is dual-homed to each data center.  With this architecture, recovery in the event of a disaster is nearly instantaneous. Sessions that were dropped by the active data center that suffered the disaster are simply restarted on the hot-standby data center within seconds. The main issues that our disaster-recovery strategy solves include:

• Data and applications are kept carried out by two-phase commit replication.  Because the RRP servers are configured to retry failed transactions, neither registrars nor users submitting queries will perceive any degradation in service. 

• If the active data center goes off-line, the workload is transparently switched to the hot-standby data center.  The transaction latency is limited to the brief time needed to replicate the last transaction to the surviving data center.

• Replication of transactions for the active site to the hot-standby site keeps each site’s databases synchronized up to the last exchanged transaction log. The standby database can fully recover all missing transactions by applying the current transaction log from the active site (if available).

The use of active/hot-standby data centers provides fast, simple disaster recovery that maintains continuity of operations with minimum to zero downtime–even in the event of a major disaster. The following are the procedures that are followed to restore operations if an SRS or nameserver site experiences a natural or man-made disaster:

• SRS or nameserver operations are immediately failed over to the hot-standby data center; registry operations proceed uninterrupted, except for those completed transactions recorded in the current transaction log and those that are in transit between the two centers. If the current transaction log is available, it can be applied to the standby .org database to bring it fully synchronized with the previously active .org database.

• We implement the disaster recovery plan for the failed data center and place the disaster recovery team on alert.

• Within eight hours, the disaster recovery team is assembled and dispatched to the failed data center to help the local data center personnel stabilize the situation, protect the assets, and resume operations.

• The disaster recovery team assesses whether the building housing the data center can be used to recover operations.

  • If so, the team contacts disaster recovery specialist firms under contract to NeuStar to secure the facility and begin recovery operations.

  • If not, the team salvages equipment and software assets to the extent possible and procures an alternate data-center facility. NeuStar initiates its contingency plan to reconstruct the data center in the new location, repair and test the salvaged equipment and software, and procure the remaining required components with quick-reaction procedures.

• Once the disaster recovery team has stabilized and tested the SRS or nameserver equipment, it retrieves the system and application software CD ROMs and the database backup tapes from the secure escrow.  It then rebuilds the data center using the same recovery procedures that are used restoring components lost in a more limited failure. (Proposal Subsection C17.15.3 describes these procedures.)

Redundant/diverse systems for providing service in the event of an outage

NeuStar is proposing two active/hot-standby SRS data centers and multiple nameserver sites with high availability clusters and cluster management software that enables multiple node processors, in conjunction with RAID storage arrays, to quickly recover from failures.  The server load balancer and the cluster manager software monitor the health of system processors, system memory, RAID disk arrays, LAN media and adapters, system processes, and application processes.  They detect failures and promptly respond by reallocating resources.

Dual fault-tolerant database servers are coupled to a primary and a backup database and RAID configuration to ensure data integrity and access to the database. The database system uses synchronous replication, with two-way commits to replicate every transaction to the backup database. The process of detecting failures and restoring service is completely automated and occurs within 30 seconds with no operator intervention required. 

Process for recovery from various types of failures

The following table lists the possible types of failures and describes the process for recovery.  In all cases of component failure, system recovery is automatic, with zero downtime and zero impact on system users.  The remainder of this subsection, C17.15.3, provides additional information about failure recovery considerations for individual components.

Recovery from a cluster processor failure
If one processor in a cluster fails, the cluster manager software logically disconnects that processor. While technicians repair or replace it, applications and user sessions continue on the remaining cluster processors. After the failed processor is off-line, the following procedures are used to recover it:

1. Testing and troubleshooting with diagnostic hardware and software to determine the root cause (e.g., hardware [CPU, memory, network adapter] or software [system or application subsystem]) 

2. Repairing hardware failures and, if necessary, rebuilding system and applications software from the backup CD ROM

3. Testing the repaired processor and documenting the repairs in the trouble ticket

4. Logging the processor back into the cluster.

Database system recovery
Our database-management system supports continuous operation, including online backup and management utilities, schema evolution, and disk space management. All routine database maintenance is performed while the database is online.

NeuStar’s fault-tolerant database server software solution will provide distributed redundancy by implementing synchronous replication from a primary database server to a backup database server. This solution includes automatic and transparent database failover to the replicated database without any changes to application code or the operating system.

If a database system node experiences a hardware failure or database corruption, NeuStar technicians use the following recovery procedures:

1. Test and troubleshoot with diagnostic hardware and software to determine the root cause (e.g., hardware [CPU, memory, network adapter, RAID disk array] or software [operating system, database system, monitoring software]).

2. Repair hardware failures and, if necessary, rebuild operating system and applications software from the backup CD-ROM.

3. Test the repaired processor and document the repairs in the trouble ticket.

4. Restore the data files by applying (in the correct sequence) the full backup DLT tapes and the incremental backup DLT tapes maintained in the data center.

5. Log the processor node back into the fault-tolerant server configuration and synchronize the database by applying the after-image journal files until the primary and replicate database are fully synchronized. The procedure is as follows:

   • Recreate the database directories and supporting file structure

   • Insert the full backup tape from the escrow facility and restore the base level backup.

   • Insert incremental backup tapes in the correct order to ensure they are correctly applied to the base level backup.

   • Using the log roll forward recovery, mount the roll forward recovery tapes and apply them to the database.

Training of technical staff who will perform recovery procedures

NeuStar technical personnel have an average of five years of data center operations experience, encompassing the high-availability cluster technology, distributed database management systems, and LAN/WAN network management systems that are employed in the recovery process. New hires and transfers to NeuStar’s .org registry operations will be given the following training:

• A one-week “.org Registry Overview” course;

• Vendor-offered courses for certification in backup/recovery, cluster management, system management, and network management; and

• On-the-job training on registry operations, including high availability cluster management, system backup/recovery, database backup/recovery, and system/network management.
  

Software and operating systems for restoring system operations

NeuStar will use commercially available Unix operating systems, cluster management software, and backup/recovery software to restore the SRS and nameserver systems to operation.  In addition to providing synchronous replication of registry transactions to the backup server, our database-management system will provide data recovery services using the DLT tape backup system.  Backup/recovery hardware and software at the SRS data center will remotely back up and restore the nameservers over the VPN.

All static applications software and operating systems are backed up to DLT tape volumes and converted to CD-ROM for quick restoration in the event of operating system or application software failures. Backup copies are maintained in the data center for quick access, with additional copies in the secure escrow facility.

Hardware needed to restore and run the system

The two active/hot-standby data centers will house the commercial off-the-shelf, fault-tolerant cluster servers and dedicated backup/recovery servers that are needed to restore the system to operation.

Backup electrical power systems

Each of the two data centers is configured with a UPS battery-backup system that provides sufficient power for 30 minutes of operation.  They also have a transfer switch connected to 1,000-KVA motor generators that are capable of powering the entire data center for many days without commercial power.

Projected time for restoring the system

Two active/hot-standby data centers, each with high-availability clusters sized to handle the full projected registry load, provide the SRS services.

If an individual cluster experiences a processor failure, that processor’s applications are transferred to another processor within approximately 30 seconds; however, the remaining processor nodes in the cluster continue applications processing without interruption.

Since the hot-standby database maintains synchronization with the active one up to the current transaction log, even if a natural or man-made disaster eliminates one data center, registry services can continue with minimum downtime and minimum impact on users.  The only impact is transitional, with dropped sessions to the RP server, Whois Server, and Name Servers, and potentially, those completed transactions on the current transaction log if the log is also lost in the crash.  Because the protocols reinitiate a failed transaction, even these operations are fully restored in less than 30 seconds with no loss of data or transactions.

Testing the system-restoration process

NeuStar will test disaster recovery plans and outage restoration procedures annually to ensure that they can effectively restore system operations.

Documenting system outages

System-problem documentation includes the following:

• The system manager and network manager systems collect performance and utilization statistics on system processors, system memory, LAN media and adapters, routers, switches, system processes, and applications processes. 

• The automated help desk database contains documentation on trouble tickets, whether system generated or generated by the Help Desk.

• The trouble ticket database contains the documentation of the steps taken to resolve trouble tickets.

• The data center manager collates, analyzes, and reports monthly statistics on help desk activities, system utilization and performance, and outages.

Documenting system problems that could result in outages

NeuStar’s proactive systems management processes include performance management, trend analysis, and capacity planning. These processes analyze system performance and utilization data to detect bottlenecks and resource utilization issues that could develop into outages. Monthly reports on the three processes keep the data center manager appraised of our performance against service level agreements and raise awareness of potential problems that could result in outages.

In addition, NeuStar performs root cause analysis of hardware and software failures to determine and analyze the reason for any failure. Based on our findings, we work with vendors to generate hardware service bulletins and software maintenance releases to prevent reoccurrence of these failures.

Registry failure provisions.

Please describe in detail your plans for dealing with the possibility of a registry failure due to insolvency or other factors that preclude restored operation.

NeuStar has developed a sound registry transition plan that, in combination with the data escrow requirements established by ICANN, provides a highly-effective solution for the recovery of any registry following a catastrophic failure.

Internet domain names are an important public resource.  The functions provided by the registry; zone file, Whois, domain database, and the change management associated with those functions are critical to the effective and efficient operation of the .org domain.  Domain name holders, registrars, and Internet users around the world have grown to expect, and depend upon, uninterrupted service.  The existing registry providers and ICANN need to work together to minimize any disruption to the TLD in the event that a registry provider fails. 

Registry services form the core of critical Internet functionality.  Domain name holders, registrants, rely on a registry’s nameservers for name resolution.  Without a reliably functioning nameserver infrastructure, e-mails would not be received, websites could not be viewed, systems that use domain names for addressing would not be able to interface with each other, etc.  Registrars rely on the registry’s SRS to manage the domain names for their customer – the registrants.  The registrars manage nameserver updates and changes, account renewals, name expirations, among other functions; through the registry.  The Internet community relies on the registry Whois for maintenance and administration in the domain.   Therefore, any disruption of a registry’s services can have catastrophic impacts on the users of a domain.

The critical functions that must be rapidly and accurately restored in the event of failure are:

• The SRS to manage change to the .org database zone file and Whois on behalf of the registrars;

• Zone file generation, propagation, and hosting; and

• Whois hosting.

One method of providing for restoration in the event of a catastrophic registry failure is to identify one or more entities to act as secondary nameservers for the domain and freeze all changes.  It is likely that there would be volunteers, such as universities and existing registries, that would act as secondary nameservers for the failing domain’s zone file for some reasonable period of time.  However, this solution would mean that Whois and change management would not be supported during the time that it takes to transition to a new registry.  This could be a significant amount of time. 

It has been NeuStar’s experience as a registry provider that change management is a very important function to the registrants.  A significant number of nameserver changes are managed through the registry.  That is, a person changing a nameserver address will port their applications; e-mail website, etc.; to a new nameserver and then change the nameserver address at the registry.  When they do this they are expecting a short period of downtime.  The downtime could be as short as fifteen minutes for a registry such as NeuStar’s internet registry that performs near real-time updates to the zone file.  Or it could be as much as 12 hours for registries such as the current .org registry that performs updates twice a day.  To add weeks if not months to nameserver changes would be completely unacceptable to registrants.  Another problem exacerbating this situation is the fact that many companies in the business of hosting websites and e-mail are affected by the recent downturn in the economy.  Registrants have to find a new host for their services quickly.  A delay in changing the nameserver addresses could put them out of service for an unacceptable period of time.  Such a scenario would effect the registrant’s own operations. 

NeuStar believes that the transition plan we have detailed in Proposal Section C18 of this RFP can be used as a template for any transition of a domain from one registry to another.  That is, this transition plan can be used in the event of a registry failure, as well as, in the event of an RFP award such as the one for .org. 

Exhibit C17-19 summarizes the transition plan which lays out a six week timeline beginning with adding the successor registry’s nameservers as secondaries and ending when the last nameserver of the incumbent registry is removed as a secondary.  This plan assumes that ICANN has selected a successor registry with a functioning SRS registry database, nameservers, and Whois.  The second and third week of the plan places a moratorium on registrar transfers, and the third week places a moratorium on adds, modifies, and deletes.  The third week is the only week that would affect the registrants trying to initiate nameserver changes.  There is also an allowance for emergency modifications, but these are to be kept to a minimum to avoid the possibility of having the database, the zone file, and the Whois out of synch.  Four of the six weeks are in place for a gradual ramp down of the incumbent registry provider’s nameservers. 

Given the devastating effects of a registry failure on the users of a TLD and the Internet as a whole, NeuStar, of course, seeks to avoid ever having to execute a recovery plan.  NeuStar’s first line of defense against failure is its highly secure, redundant registry infrastructure.  Moreover, NeuStar’s strong financial health and significant investor support further ensures that failure due to insolvency or similar factors will never happen.  Sound and responsible registry operations, however, require an effective failure recovery plan.

If NeuStar were to experience a failure we would propose the transition plan we have provided in Proposal Section C18 to transfer the .org domain to a successor.  We would agree to follow all of the guidelines we are proposing in Proposal Section C18 for the incumbent operators of .org.  A very important additional function of an operating registry in this regard is the data escrow requirement outlined in the ICANN contract. These escrow data requirements ensure that necessary data is available to support the proposal transition plan. We will also notify ICANN at the earliest time possible to provide sufficient time to transfer the zone files and other key data to a successor operator, and assist them with that transition.  NeuStar would also stand ready, at ICANN’s request, to implement this transition for other ICANN sanctioned registries that may fail.

Transition Plan. This should present a detailed plan for the transition of the Registry Function from the current facilities and services provided by VeriSign, Inc., to the facilities and services you propose. Issues that should be discussed in this detailed plan include:

NeuStar’s transition approach, borne from unique experience successfully transitioning a TLD from VeriSign, ensures the highest levels of stability, service, and integrity.

Exchanging ownership of the .org registry must be done in a manner that secures a seamless transition into a proven, stable, and robust registry.  A seamless transition entails meeting the needs of each .org stakeholder where:

• End user DNS and Whois resolution remains accurate and uninterrupted;

• Registrant nameserver changes that require immediate attention can be immediately corrected;

• Registrars are provided the necessary time and support for equal registry access; and

• The Internet community is not damaged by any perceptions of instability, under-engineering, or lack of data integrity.

The risks associated with transitioning an active, mission-critical resource like .org cannot be overemphasized.  Imperfect navigation through the complexities of a TLD transition will lead to resolution outages, inaccurate or non-reconciled data in and between the .org zone, Whois, and SRS databases, and extended or costly interruptions to registrant and registrar activities.  The impacts of these unacceptable risks reach far beyond the over two (2) million .org domain owners.  Many noncommercial registrants rely upon their .org domains to offer essential communication services to their supporters.  These services often represent the single information or administrative processing medium to conduct daily activities and would, therefore, halt critical activities in the .org community.  If data transition is not effectively and aggressively managed, it is likely that in-flight or incomplete domain requests (such as registrar transfers or deletes) will be lost or processed in error, billing transactions will be inappropriately billed or applied, and active names will be sold to new parties.  Further, when registrars are not provided the same and appropriate level of time and technical support to execute their transition activities, .org registrants with different registrars will be treated unfairly, calling into question the integrity of the .org TLD.

Whenever data and services are moved from one entity to another, there are a multitude of risks inherent in the transition. When that transition is between two different and unrelated entities, those risks, and their likelihood of occurring, are even greater based on differences in approach, expertise, culture, and agenda.  Beyond the need to effectively manage these inter-registry complexities, there are many technical challenges that must be combated to avoid negatively impacting the .org space and its stakeholders.  These technical challenges include:

• Preparing a solid, robust, well-tested, and proven registry infrastructure within 2-3 months of contract award (to include DNS, Whois, SRS database, SRS online and batch interfaces, CRM, and Billing);

• Offering a registrar Toolkit, interactive test environment, technical support team, and detailed documentation for registrars within 1-2 months of contract award;

• Collecting and empowering a team of seasoned TLD transition experts immediately upon contract award;

• Arriving at and executing against a prudent and attainable DNS zone management transition plan that guarantees absolutely no interruption of DNS or Whois resolution;

• Defining and executing against a detailed transition plan that addresses the needs of end users, registrants, and registrars with:

  • Uninterrupted critical services;

  • Sustained data integrity;

  • Integration of immediate roll-back capabilities; and

  • Expert technical support.

To address the aforementioned transition challenges, eliminate success risks, and mitigate negative outcomes, a contractor must (1) intimately understand each risk and its impact on the various stakeholders, (2) have practical experience with the various approaches, (3) arrive at a sound and attainable plan, and (3) have direct control over a scalable infrastructure that can meet the demands of a data, service, and user transition. 

NeuStar offers a comprehensive transition package based on practical, not theoretical, experience.  Our detailed, technically sound, and attainable plan can be flawlessly executed because we already possess (1) the scalable registry infrastructure which has proven to accept a transitioned TLD, (2) an accomplished TLD transition team with successful TLD transition experience, (3) a technically sound data transition approach that guarantees no interruption in critical .org services, and (4) an effective program management approach that identifies and addresses obstacles and issues quickly.  The following transition plan proposal sections clearly illustrate that NeuStar is proficient not only in registry management, but also in registry transitions These sections contain:

• Detailed steps of our transition plan, addressing the needs of each .org stakeholder for each registry application and transition category;

• A review of the duration and extent of registry function interruptions, highlighting NeuStar’s stability criteria and specific activity impacts;

• An overview of risks and the associated contingency plans, illustrating NeuStar’s proven sense of priority, risk mitigation, and understanding of TLD transition components;

• Identification of service impacts by stakeholder, demonstrating the critical services that will not be interrupted during the transition and the administrative services that will be temporarily halted to ensure data integrity and accuracy;

• Specifics regarding the cooperation required of the .org registry incumbent, listing the activities and deliverables that require VeriSign participation or completion;

• A summary of NeuStar’s relevant experience in performing similar transitions where our accomplishments in transitioning mission-critical resources, including the .us TLD, are explained; and

• A listing of transition success criteria against which NeuStar and the .org community can measure a flawless transition.

NeuStar’s recent experience in transitioning the .us TLD was utilized to arrive at a detailed, practical, and proven transition plan for the .org TLD.

NeuStar has developed a comprehensive phased transition plan that will be initiated within weeks of contract award. We will immediately begin discussions with VeriSign regarding the details of our plan, coordinate meeting schedules and deliverables, and identify their internal resources. The transition period is scheduled for competition prior to the end of the year to ensure all resources will be available.

NeuStar has already achieved success in managing the complexity of creating, maintaining, and enhancing TLD spaces.  Additionally, NeuStar has navigated through the intricacies of transitioning mission critical services between unrelated entities.  NeuStar’s recent experience in transitioning the .us namespace was utilized to arrive at a detailed, practical, and proven transition plan for .org.  This directly relevant experience, coupled with our unparalleled resources, makes NeuStar distinctly qualified to offer a seamless and stable transition.

Although the competition introduced by a separation of .org from the .com and net registries will benefit the Internet community at large, transitioning an existing, mission-critical public resource introduces concerns about degradations in service and availability.  These concerns cannot be ignored and should not be underestimated, since they represent risks inherent in any service, data, and system migration.  The complexity and probability of these risks are further exacerbated when the migration is between unrelated entities.  Clearly a contractor’s ability to maintain the stability and security of the .org registry during and after the transition is of paramount importance in the selection of a new .org registry.

NeuStar will ensure stability and security with a well-balanced offering that includes experienced staff, an existing robust and scalable registry system, a proven program management methodology, and a comprehensive plan.  Furthermore, contractors who need to (1) introduce new registry software, hardware, or network elements, (2) implement new competitive registrar relationships, or (3) solicit assistance from an external vendor will significantly increase the risk of interrupting or otherwise degrading this mission-critical resource as further outlined in Proposal Section C18.6.

NeuStar’s experienced staff has been leveraged in the creation of our .org transition and contingency plans and shall be further tasked during the actual service, data, and system transition.  Details can be found throughout Proposal Section C18 and specific details about staff and transition experience can be found in Proposal Section C18.6.

NeuStar’s shared registry system, DNS, Whois, registrar extranet, informational websites, billing process, and reporting applications also have proven to be reliable, sustainable, stable, and scalable.  Each supported the introduction of the .biz TLD in late 2001 and later in the unprecedented real-time “landrush” of .us in April of 2002.  The .us launch proved that NeuStar’s systems were able to handle large concurrent volumes without any degradation in service or access.  It is, in fact, the existence of a proven and scalable registry infrastructure that allows NeuStar to guarantee a stable and on-time transition.   Specific details are further explained in Proposal Section C18.6.

NeuStar considered several different transition approaches.  Each was evaluated against the stakeholder impacts discussed in Proposal Section C18.4 to arrive at a solution which best balanced the needs of all .org stakeholders including end users, registrants, registrars, and the Internet community at large.  NeuStar’s plan was additionally evaluated against the risks defined in Proposal Section C18.3 to revise or augment activities where such risks could be mitigated or eliminated.

A transition plan can be successful only if complemented by a structured and effective program management approach.  NeuStar employs a program management methodology built upon standards set forth by the Project Management Institute (PMI).  This program methodology is far more than a documented process.  NeuStar employees at every level participate in customized and certified project management training.  The approach and its associated deliverables, processes, and documentation are considered the responsibility of every program team member.  Program performance reviews are provided to executive management and program sponsors on a regular basis and are then shared with impacted stakeholders.

When NeuStar’s program management methodology is coupled with our unmatched resources and experience, plans become reality.  The .org transition plan was created with involvement from all disciplines as listed below.  Execution of the activities within NeuStar’s transition plan will leverage these world-class, on-staff resources.

NeuStar’s transition plan is divided into seven delivery categories (listed in the following table).  Exhibit C18-1 depicts the timing of each of these transition items.  The critical deliverables defined under each category are the criteria against which a flawless NeuStar execution will be managed and measured.

Each transition delivery category has an associated sequence of activities and schedules.  Flawless execution requires activity and schedule adherence in each transition.

Domain name system transition
Domain Name System (DNS) transition is the most critical and visible component of the overall .org transition.  Any interruptions in the DNS service will immediately affect the more than 2 million domain name owners and all users who rely on these names in their daily lives.  Furthermore, a contractor who proposes a hasty or quick transition places the .org community at risk of experiencing degradation in service or, in the worst case, a service outage without quick recovery.

The .org community would be best served with a phased migration where problems are transparent to the .org stakeholders.  Any proposed approach that does not support the following selection criteria is at risk of not protecting the security and stability of the .org domain space. 

DNS transition selection criteria

• Full testing of zone file hosting and transfer functionality before implemented in the .org zone file start of authority (SOA) record.

• A complete plan for IANA changes to the root servers for the entire transition timeline.

• A gradual transition of geographically dispersed secondary nameservers with full operational testing before the primary nameserver change is implemented.

• A gradual removal of incumbent nameservers with two weeks of continued updating and availability.

NeuStar’s proposed transition plan, as depicted in Exhibit C18-2, guarantees a smooth transition without interruption to existing DNS resolution service.  Our plan supports 100% availability of .org DNS resolution through the utilization of a phased DNS nameserver move between registries. 

To begin the process, NeuStar will populate a nameserver using a current copy of the .org zone file provided by the incumbent.  This nameserver will be configured to pull zone data as an authoritative secondary nameserver.  Once the secondary nameserver is proven stable and accurate, the incumbent will remove a specified incumbent nameserver.  This process will be repeated several days later for five incremental nameservers.  VeriSign will need to maintain their removed nameservers for a period of two weeks (after removal) to allow for cache expiration.  Having the removed nameservers updated and available for this two-week stability period will eliminate any delayed remote caching issues.

Once NeuStar’s six secondary nameservers have proven operational for a period of one week, the incumbent will replace the VeriSign primary nameserver with a NeuStar primary nameserver.  Again, these removed Incumbent nameservers will be kept updated and available for a period of two weeks to support any cache expiration delays.  NeuStar will then gradually replace all additional secondary incumbent nameservers with NeuStar nameservers over a period of four weeks. 

Nameserver replacements and removals will be conducted in a geographically balanced sequence to maintain current geographic distribution to avoid location-based points of failure.  Additionally, this sequencing supports removal of servers with lower volumes/loads early in the process to demonstrate the capacity and functionality of the NeuStar TLD cluster architecture.

NeuStar’s plan includes full testing and quality assurance checks before each DNS modification, as well as continuous monitoring after a DNS modification has been completed.  This well-orchestrated, prudent approach allows for the identification of issues where immediate corrective action can take place, thus eliminating any end user or registrant interruptions.  In the event any unforeseen capacity issues are identified during our quality assurance checks or post-implementation monitoring, NeuStar can leverage its horizontally scalable infrastructure to add more nameservers.  We do not believe the NeuStar architecture requires more than six nameservers at the time of transition.  After the transition, NeuStar plans to add two additional nameserver sites, one in Europe and one in Asia.

NeuStar will not implement its dynamic DNS updating feature (near real-time versus twice-daily updates) until all incumbent nameservers are decommissioned for a period of 90 days.  Delay of this enhanced feature eliminates risks caused by synchronization issues for incumbent servers not prepared to accept dynamic updating.

To avoid any misunderstandings about sequence, deadlines, and required activities, NeuStar will present very clear requirements and documentation to include illustrations, such as Exhibit C18-3, which depicts the timing and relationship of DNS migration events. 

The following calendar, depicted in Exhibit C18-4, lays out a list of activities required for a smooth transition of the zone file from VeriSign to NeuStar. The primary activities take place every Monday and Saturday beginning on Monday, November 11 and ending on Monday December 23, 2002.  The activities include:

• Weekly project planning meetings between NeuStar and VeriSign (every Monday).

• Weekly submissions of a TLD Modification template to IANA (every Monday).  IANA will implement the submitted changes on the following Monday Copies of each of the six IANA templates are included at the end of this section.

• Weekly updates of the root servers by IANA (every Monday).

• Weekly modifications of the .org SOA record to reflect the addition of NeuStar servers, change of the primary nameserver, and removal of VeriSign nameservers (every Saturday).

• Detailed testing of each change and preparing for the upcoming change.

Modifications of the nameservers are first implemented in the .org SOA record on Saturday and then implemented in the root servers the following Monday.  This will allow for time to monitor the nameserver performance and zone transfer functionality.

Shared registry system and .org database description

Summary
The most difficult aspect of the .org registry transition will be the transition of the existing .org database and the SRS that acts as the interface between the registrars and the .org database Changes initiated by the registrars generate changes to the .org database Many changes to the .org database will generate changes to the zone file and the Whois The .org database is the core of the registry.

Transitioning the database from VeriSign to NeuStar will require a significant amount of scrutiny and data validation. During this transition it will be necessary to place a temporary moratorium on some services provided by the registry as depicted previously in Exhibit C18-3.  The functions affected are:

• Registrar transfers—Since a registrar transfer can take five days from the initial transfer request to when the transfer is complete it is necessary to have VeriSign deny registrar transfers for a week before the transition That way we can ensure that there are no registrar transfers in process at the time of transition.  There will be a moratorium on registrar transfers beginning 24 November 2002. This will ensure that the .org database is static and stable with no pending activity when it is transitioned to NeuStar on 30 November 2002.

• Add, modify, delete, check, and registrar transfers—Once NeuStar takes over the .org database, it will take one week to get it stable and operational.  During this week, there will be no access to the .org database Therefore, there will be no add, modify, delete, check or registrar transfer activity during this week There will be no changes to the zone file or the Whois, in addition to the database itself NeuStar will allow emergency nameserver changes because we realize that can be a critical need of a .org registrant.  This moratorium will last from 30 November 2002 to 7 December 2002.  Once the database is stabilized, tested, and accepted on 8 December 2002 by NeuStar engineering and operations personnel we will begin accepting those transactions.

The details
An SRS transition plan must appropriately balance the needs of all .org stakeholders.  A transition plan that purports to migrate the back-end Shared Registry System (SRS) database without a system stability period or the host of SRS interfaces without a supportable transition window should be met with serious reservation.  Maintaining SRS integrity during a database transition requires a prudent conversion of data where time is allotted to (1) perform quality assurance checks and (2) support “in flight” or extended, non-real-time transactions.  SRS interfaces must support equal, concurrent access to all registrars, thus requiring a predefined window of time that allows registrars to technically switch and test their transition from one registry to another. 

An acceptable transition solution will weigh the registrants’ desire for administrative convenience against the registrars’ needs for testing and technical migration time.  The right transition plan also will ensure fair, equitable, and truly competitive access (a level playing field) to all .org registrars, avoiding unfair burdens on smaller, less-resourced registrars.

The SRS acts as the authoritative hub or data source for the .org domain.  The SRS database and network infrastructure feed the DNS nameservers and Whois servers with updated resolution and ownership information.  It is the SRS that interacts with online registrar interfaces and back-office billing systems to support domain name requests, queries, adds, renewals, modifies, transfers, and deletes. 

The situations that cause registrants to request transactions from the registrar that require interface with the SRS can be categorized in one of two ways:

• Service interrupting—where, for example, a renewal is past due or a nameserver change is required due to an “out of service” condition; or

• Administrative/convenience—where a registrant is adding a nameserver for future installation, wishes to transfer their domain to another registrar, or wants to request a new .org domain.

The successor .org registry will require delivery of a frozen incumbent SRS database which must then be quality-checked, archived, scrubbed, audited, archived again, converted, audited, archived again, tested, and then stabilized before it should be used to generate the production DNS zone file and Whois query responses.   These critical steps are necessary to ensure full database integrity and later .org zone file and Whois accuracy.  In addition to the necessary database moratorium to support these critical database transition activities, .org registrars also require a pre-defined window of time to modify, reconfigure, and test their interfaces against the new registry.  This pre-defined period of time must fairly support all registrars to ensure concurrent equal access at the exact time administrative services are restored.

NeuStar’s SRS transition plan calls for a conservative, yet necessary, seven-day moratorium on administrative SRS activities.  This will impact registrar turnaround for the addition of registrant nameservers, registrar transfers, domain deletions, and new .org domain names However, weighed against the possibility of inconveniencing stakeholders with unplanned and extended outages, delayed response to critical “out of service” conditions, or supporting larger registrars while smaller registrars are attempting to modify their interface, it is clearly the most prudent and stable approach. 

Although administrative services will be halted for a short period of time, the moratorium will not interrupt critical domain services such as DNS resolution, Whois queries, and emergency nameserver changes.  The SRS, nameserver, and Whois server availability can be temporarily separated from their data source without any interruption in external zone file or Whois service.  This means that a registry can upgrade or, in this case, transition the SRS and .org database without negatively impacting the zone file or Whois. 

In doing so, however, provisions must be made to control changes in either the .org database or, more importantly, to the DNS and Whois services to avoid mismatches in data and subsequent data reconciliation issues.  This means that stringent controls must be enforced to ensure data integrity to include restricting incumbent transactions that are not expected to be complete prior to the moratorium, such as registrar transfers.  Additionally, the incumbent registry must be very careful to accurately reflect any and all domain renewals and payment processing prior to the moratorium to avoid deleting and or reallocating an incomplete domain name transfer or incorrectly debiting a registrar account. 

NeuStar’s SRS transition plan calls for the full administrative moratorium to begin several hours before the .org zone file SOA record is modified to reflect the primary nameserver change from the incumbent to NeuStar which, if conducted as proposed in the DNS migration, will be on 30 November 2002.  This moratorium will end seven days later on 7 December 2002.  Although it is likely that the incumbent and NeuStar transition activities can be completed well before the December 8^th moratorium end-date, early service return of the .org administrative activities would be unfair to registrars who are planning their resources and activities in the later part of this database stability and registrar transition window.   The table below lists both the critical and administrative SRS service activities and their availability during the most critical database transition weeks.

Whois service
The .org Whois service offers vital information to registrants, end users, and registrars alike.  The transition of this information, although not as complex as other registry components, must be executed in a manner that avoids both interruption and the possibility of populating outdated or non-current information to the registry Whois servers. 

NeuStar’s plan supports a transition that avoids any interruption to Whois service and, with the required moratorium of SRS non-emergency administrative functions, also mitigates risks to presented outdated information.  Our plan calls for a transition where the incumbent registry continues to maintain pre-moratorium Whois service for one week until NeuStar certifies accurate completion of the .org database transition from the incumbent.  That is, VeriSign will continue to provide Whois service from November 30, 2002 to December 7, 2002.  NeuStar will begin providing Whois service on December 8, 2002 NeuStar and VeriSign will have to coordinate the cutover of Whois service to ensure no downtime.

Registrar Relaions
The .org registry must be committed to offering equivalent service and access across all ICANN-accredited .org registrars.  Service offerings include communication, tools, outreach programs, documentation, training, technical assistance, and similar value-added services which should be universally offered in a manner that avoids giving an advantage to one registrar over another.  The registry operator also must take into account the needs of geographically dispersed registrars, smaller less-resourced registrars, and those registrars seeking accreditation A strong transition plan will additionally support the varying degrees of technical know-how, staffing, industry participation, interface tool scalability, hardware and network capabilities, and experience among and between registrars.

NeuStar’s neutral business model, by its very nature, encourages registrar competition, globalization, and focus on service improvement.  It is, in fact, this business model that keeps NeuStar aggressively committed, without distraction or conflicting agendas, to the following registry goals:

• Fair, equal, and affordable service across all accredited registrars.

• Widespread and new registrar participation.

• State-of-the-art registry business.

• Registrations for domain spaces from the appropriate end user community.

• Customized services.

• Sponsorship and participation in specific policy councils and like forums to understand and balance the applicable TLD stakeholder needs.

NeuStar has a solid reputation in the registrar community as an experienced registry.  Our recent migration of the .us legacy space from VeriSign in November of 2002 proved our ability to successfully migrate an existing TLD while simultaneously improving service levels.

As an example of our improved service, many .us Delegated Managers were pleased to find VeriSign’s four- to five- week wait period for zone file changes, in many cases, immediately reduced to no more than 48 hours upon transition to NeuStar’s registry. 

There were several lessons learned throughout the launch of .biz as well as during the transition and launch of .us These lessons were invaluable to NeuStar in creating the following registrar relations transition plan:

• Provide details about contract award and NeuStar proposal to registrar community;

• Begin outreach program eliciting registrar concerns and ideas about .org transition activities, schedule, and risks as well as any requirements related to ongoing maintenance;

• Provide regular migration status report with updated schedule and registrar-related issues and risks;

• Work with registrar financial contacts to walk through and establish such deliverables as billing processes, reports and accounts;

• Work with registrars to obtain Digital Certificates and other registry credentials;

• Work with registrars to ensure compliance and support of existing .org registry Toolkit making improvements as required;

• Offer full connectivity and an online test environment with technical support staff;

• Clearly and regularly communicate deadlines, moratorium details to include transaction types and dates; and

• Facilitate a transition forum where registrars can raise concerns about existing service transition.

NeuStar will utilize the existing RRP.org registrar toolkit to avoid confusion and minimize preparation time to begin conducting transactions with NeuStar.  NeuStar also shall offer an interactive test environment for those registrars who wish to confirm their interoperability with the new registry system.  We will work with registrars to offer an additional launch connection period prior to launching service on December 8, 2002, when registrars can test credentials, digital certificate installation, and operational readiness of registrar systems and networks.  This connectivity support period will take place during a pre-defined period of time where 24x7 technical support will be available to support all time zones and staffing levels.  Such an approach proved valuable to registrars during NeuStar’s .us launch and supported universally, concurrent, equivalent access for the FCFS launch.  NeuStar connections shall be allocated in a fair and equitable manner to avoid any registrar transactions delays.  Our proprietary network grooming capabilities shall be leveraged to ensure fair and uninterrupted service across all .org registrars. 

Moreover, NeuStar shall offer a full complement of registrar support services, including:

• Customer support staff available 24x7x365 via toll-free phone or e-mail;

• Global outreach and education activities conducted by senior registrar relations staff with participation by technical development or maintenance personnel as needed;

• Technical tools and documentation to include registry toolkit and credential creation;

• Registrar service interface via a personalized .org registrar website;

• Interactive test environment with full functionality and test script documentation;

• Pre-launch connectivity environment with 24x7 technical support staff; and

• Marketing and media relations staff.

Transition management
The .org registry contractor must have a very structured and proven transition management approach to successfully navigate through the intricacies of a mission-critical resource migration.

A successful .org transition will require system migration experts working in an open, constructive, and mission-focused manner with the incumbent A comprehensive plan without the oversight of focused and proven transition management will not lead the incumbent and new registry staff to a smooth, seamless, and successful transition.

NeuStar’s transition management approach is based on the assumption that things can go wrong without the proper planning and preparation.  We have learned the best way to mitigate the negative impact of “things that possibly can go wrong” and navigate through complex activities is to clearly discern the most critical deliverables and impacts from the outset for ongoing focus and decision-making.  NeuStar’s transition management approach places heavy emphasis on risk assessment and contingency planning to facilitate making (or at least mapping) decisions before an event happens.  Since our technical staff will be managing the many concurrent issues that often arise with any large data, service, and user transition, NeuStar’s program managers shall regularly compare progress against the most critical deliverables to make daily decisions about priorities and issue resolution. 

The critical transition deliverables introduced in Proposal Section C18.1 have been prioritized based on their immediate impact if compromised and their execution complexity.  This list helps NeuStar understand which categories require heightened focus or stronger contingency plans. 

Poor communication can easily doom a good transition plan to failure.  This includes internal communication within teams, across project leads, and with other lines of business, but more importantly between the successor registry, the incumbent registry and the geographically dispersed registrars.  NeuStar believes it is the successor operator’s primary mission to keep all stakeholders informed of upcoming events, educated on possible risks, and abreast of current progress.  This is why our plan includes focus on transition management as an independent category with unique critical deliverables. 

• These unique transition management deliverables are:

• Regular and clear communication of status, upcoming events, and issues across registries and registrars;

• Face-to-face planning and key milestone hand-off meetings with incumbent to clearly define expectations, identify and resolve issues, assess performance, and confirm progress;

• Scheduling of activities in a manner that focuses on the accomplishment of minimum success deliverables in each category;

• Concentration on all stakeholder impacts, and mitigation of risks of unplanned or negative impacts, by

  • Quickly communicating and resolving issues; and

  • Educating stakeholders through the use of.  (1) regular registry meetings (between incumbent and gaining registrar), (2) weekly registrar newsletters, (3) one-on-one registrar communication, (4) informational web sites and (5) interface applications;

• Strictly managing compliance with all external milestones and delivery dates working toward early delivery of items that most impact stakeholders;

• Regular progress, risk, and issue assessments to proactively adopt a contingency approach or resolve unforeseen problems;

• Working with geographically dispersed registrars utilizing one-on-one registrar relations staff, Customer Service staff, and established electronic communication mediums;

• Creation of test approaches, managing of test plans, and communication of testing results with the incumbent registry and with each participating registrar; and

• Internal and external dry runs of every technical migration or implementation to ensure smooth and seamless transitions between Registries with both the incumbent registry and each registrar.

To help program team members and TLD transition experts appropriately focus their communication efforts, NeuStar’s .org program management communication model (please see Exhibit C18-5) helps to illustrate the relationship between various program efforts.  This model includes activities beyond the initial .org transition (such as registry maintenance and EPP conversion) and helps to illustrate how our transition management approach offers focus and clarity to team members who are accountable for interdependent, complex, mission-critical activities. 

Information Websites
A user-focused registry operator offers informational web sites to facilitate the needs of end users, would-be registrants, current registrants, and registrars.  VeriSign does not currently provide such a web interface specifically for the .org community.  NeuStar’s effective .org transition proposal includes the implementation of expanded information, services, and tools for the .org community.

Our plan additionally calls for dramatic improvements in the offering of informational web sites focused exclusively on the .org noncommercial space.  These will include an enhanced, user-friendly Whois interface to both end users and registrars, landing pages that describe the intended purpose namespace, processes, planned .org events, and a list of accredited registrars.  Additionally, the website will be designed to keep the noncommercial community informed and involved in .org-related issues. Through membership, end users may elect to receive updates and information about the .org domain name space and participate in .org discussion for a. Furthermore, end users can use the websites to participate in and follow the activities of the Global Policy Council (GPC) as described in Section C.35 These web sites will be offered on November 30 when NeuStar takes over as the .org registry.

Based on our experience with the .us transition and our appreciation for the importance of maintaining stability while providing minimal service disruption, NeuStar will not require any type of outage for the DNS name service or Whois services during transition However, NeuStar does propose a brief interruption in service during the transition period of the .org TLD to ensure the integrity of all registry data and a seamless transition of registry services.  The section describing SRS and .org database transition in Proposal Section C18.1 provides more detail about service interruptions.

This transition period will entail a moratorium lasting seven days, commencing the week prior to the final transition for the SRS on additions, deletions or modifications for domains and SRS-related data. During this period, NeuStar will provide customer service support for registrars Updates to domains for registrants will only be completed on an emergency basis through a manual process. Updates will not be able to take place through a provisioning protocol; instead, updates will be handled through our existing registry customer staff.

The purpose for the outage is to provide a smooth transition from the incumbent while maintaining data consistency. We believe that this interruption will provide ample time to migrate and verify data between the incumbent provider and NeuStar.

A detailed review of the transition impacts on each .org stakeholder is contained in Proposal Section C18.4 and also includes details about the duration and extent of the administrative moratorium.

NeuStar critically evaluates all program implementations to improve upon our systems, processes, education, and approach. Our recent evaluation of the .us transition was used to build a realistic and in-depth risk analysis that has contingency factors for each phase and milestone in the .org transition plan.

As previously mentioned, the complexity of navigating through the intricacies of a mission-critical service migration between unrelated entities cannot be overlooked in the selection of the .org registry provider.  To assure a seamless registry transition, the winning registry must not only understand the tasks involved in transitioning a TLD, but moreover, the problems they will likely encounter when doing so.  A successful transition will require a plan that mitigates or eliminates risk where possible or at least, minimally supports quick fallback to a pre-planned contingency.  Incorporating effective risk mitigation or elimination and contingency planning requires leveraging relevant experience. 

NeuStar has direct, recent, and relevant experience upon which risks and contingency plans were built.  We critically evaluate all programs subsequent to transition or launch completion to improve upon our systems, processes, education, and approach.  The .biz launch supported dramatic changes and improvement in our registry implementation approach that were effectively employed in our .us transition this year.

The .org transition contingency matrix provides a record of the iterative risk identification and mitigation items as well as contingency criteria and plans.  Any contingency plan and risk matrix, however, will have to be flexible, and will be continuously evaluated and updated as the transition progresses, new information is gleaned, or a new issue presents itself. 

NeuStar’s transition plan acknowledges the unique needs of each .org stakeholder and balances those needs in a manner that results in no interruption to critical registry services, full data integrity, and equal registrar access.

As previously stated in Proposal Section C18.1, there will be absolutely no interruption to DNS resolution or Whois during the transition of the .org registry to NeuStar.  To assess other possible transition impacts, however, we have identified four distinct stakeholders, external to the registry operator, who could be impacted by the transition of the .org domain space.  Each stakeholder has unique needs related to the stability of the space as well as the services offered, or not offered, during a transition.

NeuStar has built a comprehensive transition plan that identifies the elements of service requiring transition and then acknowledges the unique needs of each stakeholder against those elements.  Before exploring the elements of a registry transition we have defined the stakeholder community and their high-level needs. 

By extrapolating the needs of each stakeholder, six transition factors were identified in the transition of the zone file, Whois, and the .org database.

• Security

• Access

• Equal/Competitive Access

• Accuracy

• Currency (up-to-date information)

• Services (such as administrative support)

Although each stakeholder is indirectly impacted by the extent to which the needs of other stakeholders are met, the table below highlights the direct needs of each stakeholder community.

This matrix helped us arrive at the most stable and effective DNS transition solution by highlighting the most critical stakeholder requirements (reviewed in Proposal Section C18.1). 

While evaluating the viability of other transition approaches, NeuStar added an additional success factor to consider.  Although not exclusive to a particular stakeholder, we felt it was prudent and necessary to measure the likelihood of successfully executing the approach.  We call this factor “risk”.   In weighted scorecards, a high-risk approach reduced the positive score of other stakeholder factors.

Stakeholders will be impacted by the NeuStar transition approach in the following ways.

NeuStar knows that setting clear expectations, closely managing critical and interdependent deliverables, and promoting full disclosure of issues with the incumbent is necessary to combat inevitable disparities in systems, cultures, approaches, and agendas.

Incumbent cooperation
A smooth, seamless, and stable transition of the .org domain space between the incumbent and the successor registry requires a great deal of cooperation and focus on the part of VeriSign.  The selected registry operator must be very clear and complete in defining and communicating their expectations of the incumbent registry.  If the registry is not able to gain a mutual understanding of each deliverable, activity and deadline transition interruptions to DNS resolution, Whois service response, and SRS database accuracy would be unavoidable. 

NeuStar understands the complexity of transitioning data, services, and users between unrelated entities and, therefore, knows that disparate systems, cultures, and agendas will undoubtedly introduce transition issues between the incumbent registry and any new registry.  For that reason, NeuStar’s incumbent registry communication plan includes several planning exercises between registries soon after contract award to gain concurrence on plan details, risks, and dates.

Additionally, NeuStar’s program management approach shall be leveraged to clearly document exactly what activities are required of each entity and when such activities must begin and conclude.  As with NeuStar’s internal approach, critical deliverables by transition category and stakeholder segment shall be regularly reviewed across unrelated entities to guide decision-making and issue resolution efforts. 

Incumbent planning meeting

Schedule:	Within seven days of contract award.
Participants:	Key transition staff from VeriSign and NeuStar to minimally include technical representation and representation from a schedule decision-maker.
Key Objectives:	Review entire transition plan to ensure mutual understanding, capability required, and agreement.  Such must minimally include: Critical success deliverables by category Zone file migration approach and schedule Whois migration approach and schedule .org database migration approach and schedule Website migration approach and schedule Moratorium approach and schedule List of .org transition contacts by discipline Risks, mitigation approaches, and warning signs Ongoing meeting schedule and status methods Implementation of issue resolution process with escalation contacts and time-frames Measures for successful .org transition List of concerns and issues with follow-up actions
Required Information:	The incumbent must minimally provide the following information in the first planning session: List of all .org registrars (with contact information). List of all .org related websites and information forums with existing content to avoid degradation in service. Data dump of .org registry data to include all data elements, data schema information, etc. The successor operator should minimally present: Transition deliverables and schedule. Description of deliverables were pre-defined. Transition gating factors with risk and contingency matrices. List of .org transition contact(s) by discipline.

This list will undoubtedly grow and evolve before contract award, but provides an early indication of the types of incumbent activities required for a smooth and seamless transition.

More specifically, NeuStar and the incumbent must define exact migration times based on the high-level ownership and support plan, previously outlined in Exhibit C18-1.

Incumbent Deliverables & Requirements
A successful transition requires the timely and accurate delivery of many items as listed in the following list. 

NeuStar’s transition plan is reinforced with an exceptional package of resources to include on-staff TLD transition experts, practiced mission-critical resource migration approaches, and a proven robust and ready scalable registry infrastructure.

NeuStar has an impeccable record of managing and transitioning mission critical public resources.  NeuStar has proven able to manage the complexity of creating, maintaining, and enhancing TLDs by offering stable and reliable service to the .biz and us communities.  In addition, the award of the .us TLD provided NeuStar with the unique experience of transitioning an existing domain space from the VeriSign registry to the NeuStar registry. 

We learned many lessons about what is effective and what is not effective in the transition of an existing TLD.  As a result of this experience, our staff has gained the ability and knowledge to:

• Work cooperatively with VeriSign in the successful transition of a TLD;

• Forge positive relationships with a diverse registrar community;

• Manage policy and standards issues that spread far beyond the .biz and .us TLDs;

• Build a highly reliable, scalable, and robust registry system and associated tools/applications; and

• Positively respond to changes in requirements, policy specifications, registrar requirements, and lessons-learned through other TLD launches.

It was the experience taken from the .biz launch that supported the unprecedented transition and launch of .us.  NeuStar migrated the .us legacy space shortly after contract award.  Since this award included the migration of an existing zone file between VeriSign and NeuStar, we were able to glean many lessons learned about how a larger, more expansive migration would be successful.  We also learned the critical issues involved in an inter-company transition. 

NeuStar launched the expanded .us space in less than six months after contract award, and realized several highly unique results. 

First, NeuStar was able to successfully meet United States Department of Commerce requirements for a diverse registrar community by accrediting 58 registrars; 21 of who were not previous ICANN-accredited registrars.  Additionally, NeuStar’s relationships and international presence helped to solicit the active participation of four European, three Asian-Pacific, and two Middle Eastern registrars.  NeuStar offered the value-added services identified in the following table, to support a stable, smooth transition and launch.

Second, NeuStar was able to offer an unprecedented online first come first served (FCFS) “landrush” of the expanded .us space.  Other Registries have supported such periods with a batch process to mitigate concerns about system capacity and general stability.  NeuStar, however, gained enough experience testing the robustness of our system to comfortably offer a real-time launch without delay between the selection of Sunrise trademark owners and an open .us offering.  NeuStar successfully supported this landrush with more than 100 concurrent connections where 5 million transactions were flawless executed in the first 24 hours. 

NeuStar has implemented a TLD with and without an existing registry infrastructure—and we intimately understand the added complexity and real risks involved in executing a plan that includes the addition of new registry software, hardware, and or network components.  Flawless execution can only be guaranteed by a contractor who is able to utilize an existing infrastructure—and NeuStar is that operator. The following table highlights certain risk scenarios and their respective possibilities.

Since NeuStar currently supports a very robust, scalable system with internal resources we are able to eliminate the significant program risks of introducing a new infrastructure.  Without these risks identified in the above table, NeuStar can comfortably guarantee a timely, fair, and stable transition.  The benefits of implementing a TLD atop an existing, proven infrastructure is clearly illustrated in the .us transition and launch summary included at the end of Proposal Section C18.

NeuStar is able to additionally leverage the experience of managing and transitioning other public resources in our other lines of business as highlighted in the following table.

In the final analysis, it is NeuStar’s ability to effectively leverage our unmatched core competencies (registry expertise, seasoned corporate infrastructure in mission-critical database businesses, matured registrar relationships, stable and scalable technical architecture) that will ensure a smooth and stable .org transition.  The leaders of NeuStar’s transition team are identified in section C15, but are complemented by a host of seasoned staff who have all already proven able to flawlessly execute. 

An effective plan includes clear and measurable success factors against which a smooth and seamless transition can be measured, and against which future migration or enhancement plans can be built. 

NeuStar’s experience with mission-critical data migrations has been exploited to arrive at a solid transition plan.  The plan was designed around key deliverable categories, priorities were built upon stakeholder needs, and risks were evaluated based on their probability and impact.  This strong planning lays the foundation for clear definitions and measures of success.

C18 Attachment 1: IANA Templates (pdf 508 kb)

C18 Attachment 2: ".us Transition and Launch" (pdf 678 kb)

Please describe in detail mechanisms that you propose to implement to ensure compliance with ICANN-developed policies and the requirements of the registry agreement.

NeuStar has already successfully implemented, and will continue to refine, mechanisms that ensure compliance with ICANN-developed policies and requirements of registry agreements.

Because of ICANN’s unique mandate to preserve the operational stability of the Internet, it is incumbent that the .org registry operator implement mechanisms for assuring compliance with the various policies and contractual requirements that arise by virtue of its unique relationship with ICANN.  In proposing such mechanisms, a prospective registry operator cannot merely recite its intention to abide by the requirements of the registry agreement with ICANN.  Instead, the successful applicant must identify discrete mechanisms that demonstrate to ICANN that, as the registry operator, it understands policy and contractual requirements, and can immediately comply with both on an ongoing basis.

NeuStar’s business, technical, and policy operations have successfully implemented mechanisms for ensuring compliance with ICANN-developed policies and requirements of registry agreements.  These mechanisms, described below, include active participation in ICANN policy-making processes, as well as internal review of TLD business decisions for legal and policy compliance.  NeuStar proposes to maintain and continue to refine such mechanisms.  With these mechanisms in place, NeuStar ensures that policy compliance is fully integrated into all operations in an efficient and streamlined fashion.

Participation in ICANN policy-making process
NeuStar considers it a basic principle of .org TLD administration that the operator of the registry is a trustee of a valuable and important global public resource. Therefore, NeuStar proposes to continue working with ICANN in the development and enhancement of policies affecting the noncommercial community and the Internet at large.  Examples of such participation include:

• Attending ICANN’s regular meetings.

• Leveraging and continuing our legacy of active participation in the development of Internet governance policies. 

• Serving as leaders in ICANN’s policy bodies.  For example, a member of the NeuStar team currently serves as the chairman of gTLD Registry Constituency, while another represents the .us TLD before the ccTLD Constituency. 

NeuStar also commits to comply with the Consensus Policy procedures set forth in Section 4 of the draft registry agreement for the .org TLD.  However, unlike many other applicants, NeuStar has successfully operated under the Consensus Policy procedures by virtue of its agreement with ICANN for the .biz TLD.  By continuing such participation, NeuStar is positioned to understand and properly implement ICANN-developed policies.

Legal and policy review
From our registry experience, NeuStar has learned that the most effective method for ensuring policy and contractual compliance is for the TLD registry operator to rigorously review operational plans and programs prior to implementation.  NeuStar ensures that such review is accomplished in accordance with the following processes:

• Requiring managers to submit operational plans and programs, such as the deployment of new services, for a compliance review. 

• Conducting compliance reviews through a dedicated staff with significant experience in Internet governance, operations, and contract compliance and reporting on those findings.

• Maintaining constant contact with ICANN staff regarding proposed activities and compliance issues.

With respect to ICANN, NeuStar has already successfully incorporated the above mechanisms under its registry agreement for the .biz TLD.  For example, in accordance with Appendix H of the .biz Registry Agreement, there is a compliance officer that ensures that ICANN’s requirement of “Equal Access and Nondiscrimination” is followed and strictly enforced.  NeuStar has demonstrated its ability to provide equal access to all ICANN-accredited registrars time and time again in its operation of .biz.

Moreover, unlike many other applicants, NeuStar manages both the
policy-making body and registry in its operation of the .usTLD.  As such, NeuStar has had a great deal of success in not only ensuring that policies are carried out, but also in facilitating the policy body that is able to set such important policies in order to meet the Internet community’s needs. Thus, NeuStar stands ready to continue operating such mechanisms for ensuring policy and contractual compliance in the .org TLD space.

Exhibit C19-1 shows the process for integration of new requirements from an oversight authority into NeuStar’s global registry operations.  Exhibit C19-1 also shows NeuStar’s participation and continued compliance processes.