^{III TECHNICAL CAPABILITIES AND PLAN (RFP SEction D15)}

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 TLD registrySRS data-center workload plus multipleand six nameserver sites geographical 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 has five 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 registry SRS data-center operator's technical services. This plan builds on the resources and successful experience described in Paragraph III.1.

Since there is no significant amount of work being performedwill be performed by subcontractors, there is no need to answerresponse is necessary for III.3. D15.3 lists any technical functions that will be provided by NeuStar subcontractors, and describes the proposed subcontractors' capabilities and resources

D15.4 describes the special provisions that we have made to accommodate the extraordinary demand that may be anticipated during the early period after a new TLD name becomes available.

D15.5 is a discussion of how our technical proposal satisfies ICANN's  Criteria for Assessing TLD Proposals. 

(NOTE: IS D15.4 AND D15.5 CORRECT. I DON'T SEE IT ON THE MATRIX.)

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.