HIGHLIGHTS u Flexible, scalable, high availability system architecture to virtually eliminate SRS downtime while providing for smooth growth u Coactive, redundant Shared Registration System Data Centers for high service availability u Geographically dispersed Zone nameservers for DNS query workload distribution |
JVTeam brings together the experience and technical capabilities to implement a TLD Registry that will provide significant benefits to the Internet community.
The NeuStar/Melbourne IT Joint Venture�s (henceforth the JVTeam) proposed technical solution provides two co-active data centers in Sterling, Virginia and Chicago, Illinois�each of which is capable of processing the full SRS data-center workload�plus multiple nameserver sites dispersed globally to protect against natural or man-made disasters. The benefit to ICANN and the Internet community is a solid architecture designed to maintain the stability of the Internet and promote user confidence.
Section III is organized in three subsections as required in the ICANN RFP:
� III.1 describes JVTeam technical capabilities and expertise.
� III.2 and subparagraphs III.2.1 through III.2.14 is our detailed plan for providing the SRS data-center operator�s technical services.� This plan builds on the resources and successful experience described in Paragraph III.1.
� Since no significant amount of work will be performed by subcontractors, no response is necessary for III.3.�
ICANN�s criteria for accessing TLD Proposals considers several technical issues that will be extensively reviewed. The following table summarizes ICANN�s technical issues and JVTeam�s response.
TECHNICAL COMPONENTS OF SUCCESS |
||
Issue |
JVTeam Response |
Benefit to ICANN |
Maintain the Internet�s Stability |
||
Continued and Unimpaired Operation throughout the delegation period worldwide |
� A world-class SRS system architecture with co-active redundant data centers and nameserver data centers located worldwide |
The architecture provides the flexibility, scalability, and reliability to meet stringent service levels and workloads. |
Minimize unscheduled outages for registry or registration systems due to technical failures or malicious activity of hackers |
� Co-active redundant data centers with two-way replication and dual-homed telecommunications links to nameserver data centers � High-availability cluster architecture in each center � Internet firewall with intrusion detection, and stringent security authentication processes |
Architecture seamlessly handles hardware failures and natural and man-made disasters with near zero downtime and zero impact on Registrars |
Ensure consistent compliance with technical requirements in TLD registry operation. |
� Institute stringent Service Level Agreements (SLAs) covering performance. � Network and cluster-management software monitors and reports on these service levels. |
ICANN and the Internet community are kept continuously informed of our status in meeting the SLAs. |
Effects of the new TLD on the operation and performance of the DNS in general and the root-server system in particular. |
� Multiple new nameserver data centers dispersed globally and implemented with high-availability clusters, load balancers, and redundant components for �lights-out� operation. |
� Provides the Internet community additional DNS assets. � Enhances acceptance of the new TLD. � Provides resilience and disaster recovery. |
Rapid correction of technical difficulties and expansion of Whois information. |
� The Whois database is configured as a data mart off the master database with a high-availability cluster of Whois servers with load balancers to handle high query volumes. |
� Whois data is replicated from the master database to ensure accurate, consistent, and helpful domain-name information consistent with privacy rights. |
Protection of domain-name holders from the effects of registry or registration-system failure. |
� The co-active Shared Registry System data centers and the DNS nameserver data centers are configured to eliminate any possible single point of failure. � The database is two-way replicated between the SRS data centers. |
� Recovery from outages� and disasters with near zero downtime and therefore zero impact on users. |
Provisions for orderly and reliable assignment of domain names during the initial period of the TLD registry�s operations. |
� Via FTP, each registrar submits a file of domain-name-registration transactions to the SRS data center each day for a 12-hour round-robin batch-processing cycle. At the end of the 12-hour period, the system informs each registrar of the status of the submitted domain names. The following day, the registrar submits a new list with resubmitted and new domain names. |
� Enables the SRS data center to manage the vast volume of domain-name registrations during the �Land Rush� phase. � Ensures fairness. |
The Enhancement of the Utility of the DNS |
||
Different operational models for registry � registrar functions. |
JVTeam proposes: � A new �fat registry� (thin registrar) model. � A new registry-registrar-protocol called eXtensible Registry Protocol (XRP) that offers expanded functionality and improved security and authentication services. |
Provides a greater level of functionality than the current Registry Registrar Protocol (RRP). |
Appropriateness of adding new TLDs to the existing DNS hierarchy. |
� Technical impact is minimal since new nameserver data centers are added to handle the increased workload. |
� Expands the utility of the Internet � Encourages competition � Provides consumers with alternatives to .com. |