Design of the hardware and software infrastructure is being undertaken internally under the direction of Dan Sokol. The company is creating product proposals to software development companies. We are considering a combination of experienced experts including IBM, DigiPro, and Sapient. Software maintenance will be internally managed.

dotYP is creating a unique registry outside the traditional sense. All .yp URL’s are by definition, valid, thereby obviating the need to sell them.

Hardware

dotYP's servers will be located in Hong Kong (PRC), London (UK), Bombay (India), Sydney (Australia), and Santa Clara (California). They will be hosted at major co-location facilities (Exodus, iAsiaWorks, IBM). Bandwidth limitations at these facilities is a non-issue.

A. Facilities.

All facilities, both presently contracted and those in negotiations include:

Redundant high availability power

Where available, two phases of power from local grid

High-capacity UPS

High velocity air conditioning

Enhanced security

Observed man-trap entry into facility

Gated and guard-monitored access to network operations center

Transparent, fully-enclosed, and locked "cage" for hardware

Monitored walkways

Badge-only access to building

Raised flooring and lowered ceiling

B. Machines.

The machines will be grouped in logical clusters. Multiple clusters may exist in any one YP-Root location. One YP-Root location may serve multiple regions. One YP-Root location will be designated the master back-end server, whose duties will be explained below. Any back-end machine will be able to function permanently or temporarily as a master back-end.

YP Root Locations. Every YP-Root location will contain:

Border/Edge

2 Cisco 7200 series routers (with plans for 12000 series as need expands)

Running BGP4 to the outside

Running HSRP inside

Connectivity via peering arrangements per location.

ATM nodes (where applicable) and AS numbers pending assignment

Extended access control lists for security

YP-Root server cluster (see below)

Two Cisco PIX

Virtual private network on T1 to administrative WAN

Security between back end and rest of network

Minimize loss of response time due to security overhead without compromising security

Responds to DNS queries with business telephone directory IP addresses corresponding to appropriate locations and topics

Collects statistical data for billing

Appropriate publisher(s) associated with each listing as provided

YP-Root server middle layer

IBM RS/6000

4 or more nodes

2 GB RAM per node

Preprocesses regional data

Generates common-use tables keyed on <topic> and <location> fields within each region

Allows a domain "ls" in either zone to show every name entry within that zone in order of regional proximity to query source

Does not require any changes to DNS protocol (only extends its utility using short times-to-live and a robust, high availability root service)

Gathers billing statistics from front-end machines and preprocesses them for delivery to back end

Multiple billing schemes will be in place to support sliding-scale-billing for increased access by developing nations and industrialized developing nations by reducing cost of entry

Database.

The database size is limited by a finite organizational nomenclature set (approximately 4,000 topical subcategories) recognized by existing directory publishers throughout the world, a finite number of geographically distinct regions, and, most importantly, a finite group of businesses. The former two lists are common, public knowledge and freely available, and the latter database will be provided by current publishers as a value-added resource to their paying customers.

Privacy, Security, and Whois.

DNS queries to the .yp gTLD will be forwarded to a YP-Root server. Coordination with Whois has yet to be determined, as the data may differ greatly by region. Network intrusion will be monitored at each location both by software and by network operations staff. Intrusions will be treated as a data integrity failure, so tampered systems will be disconnected from other local machines and backed up with relevant forensic data preserved to the extent possible and rebuilt from last backups, verifying the database as per backup plan (above).

Technical Failure Contingency Plans.

Each location will be devoid of any known single points of failure and all devices will be selected and configured for high availability, ease of replacement, and rapid response (where applicable) as noted above. All on-site network operations staff will have simple, step-by-step instructions for disaster recovery. In the event of any data integrity failure event compounded by loss of connectivity or failure to verify secure connection to other locations, databases will run from a last-known-good model until verification and correction are once again available. Network operations staff will record all disasters, real or otherwise, and record circumstances and response times. After response to disasters is initiated, the dotYP central office will be contacted as quickly as possible for process verification. Recovery as per plan will take precedence over plan verification in all cases. Regional account managers will provide telephone and e-mail support. Each region will maintain language support in the dominant regional language (as available) and English.