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. |