Introduction

The Organic Names registry facility is based on CentralNic's own registry system. This system is the result of 6 years of successful real-life registry experience and systems management. It incorporates processes that CentralNic has developed to ease and automate the interaction between the registry and registrars, accounts departments, customer service representatives, call centre operators, ISPs and registrants.

It has been Organic Names experience that attention to the administrative aspects of registry operation allows it to minimise costs and outsource much of the administration to the registrars. This not only benefits Organic Names, but takes data changes direct from the source and so minimises errors.

The Organic Names registry hardware will be a complete stand-alone new system, running CentralNics software, but with some differences. Firstly the CentralNic system currently runs about 1.5 million names. The Organic Names system is configured to have a capacity of around 10 million. The experience gained at Nominet UK - a registry roughly 150% the size of .org, is that there are some unusual file size scalability issues at the level of about 2 million registrations. Organic Names has specified software capable of handling these problems.

Organic Names, in conjunction with CentralNic has also developed RFC2832-compliant RRP front end software which mimics the VeriSign interface to ensure a seamless transition from the VeriSign registry and Organic Names hopes that VeriSign will be forthcoming with high volume live test data to enable Organic Names to reassure the registrar community in this regard. In addition Organic Names already has a development version of EPP running on this software on its test servers.

Organic Names is proposing a large number of improvements to the interaction between registrars and registry this is what this application is about. Organic Names will make these available to registrars as quickly as possible but will not enforce system changes on the registrars. They will be able to choose enhanced services in their own timescales.

It is worth noting that the registry design described herein allows Organic Names to escrow all data pertaining to registrations centrally. Organic Names will encourage registrars to adopt this approach which not only allows it to provide a seamless Whois (one of the problem areas of the VeriSign "thin" registry structure), but also gives registrants a significant extra level of confidence - especially in relation to the possible business failure of a registrar.

Two main design philosophies have been adopted. Firstly, the requirement for continuity and stability of operations has led Organic Names to pay a great deal of attention to ensuring there is no disruption to services during the transition from VeriSign to Organic Names; hence Organic Names has provided roll-back procedures, as well as back-compatibility of all interfaces. Secondly, on an ongoing basis, service levels must be maintained, and, where possible, improved. For this reason, Organic Names has designed a system which is both redundant and resilient to ensure that services are not disrupted in the event of a failure of a single component. Organic Names will rely on certain key suppliers to operate its service for instance, key telecommunications suppliers, data centre suppliers, etc. In the current environment for technology and telecommunications, unfortunately business failures are common. Thus Organic Names will both investigate, and maintain vigilance on the financial stability of its suppliers, as well as, wherever possible, using a strategy of adopting multiple suppliers, for instance in respect of telecommunications services.

The system software described herein is, in the majority, the software on which a system serving 1,500,000 domain names, to 1,000 resellers (similar to registrars) currently runs. The modifications described relate to scalability, and are running in Organic Names labs already, at full scale, and under test load. They have been developed by engineers who have worked on such systems for six years. Organic Names thus has a very high degree of confidence that these systems will not only perform in a manner superior to the current VeriSign systems, but will be delivered on time.

Organic Names trusts that the pedigree of those involved in this application will enable this confidence to be transmitted to ICANN.

The Organic Names registry will provide a content-managed website system as used by CentralNic and recently adopted by Nominet UK. This provides a site which is easy to update and provide information and interfaces in multiple languages. The site will not be a loud commercial selling machine but a sober central resource of information about the operations and policies of the registry. Organic Names will not be selling T-shirts or adopting commercial postures that tend to distract from the prime function of the site as a resource for the Internet community in general and registrars in particular.

Facility hardware and software can be separated into the following sections:

Core registry facilities will be operated in two geographic locations, allowing for redundancy and fault tolerance. A series 13 of satellite clusters will provide for secondary nameserving and Whois service.

Location choice is based on a strategy balanced between neutral data centres and non-neutral data centres, and chosen on the basis of security, facilities and diverse communications links. Satellite locations will be located in both neutral and non-neutral data centres. Organic Names current preferred choices for the main registry facilities are as follows:

• The primary registry facility will be operated in London, UK - Telehouse Europe, Coriander Avenue, London E14, UK. The facility is manned 24 hours a day by trained, uniformed security staff to stop unauthorised access. CCTV, with time-lapse video, both internally and externally provides information on possible intrusion to a security control centre. Frequent vehicle searches are carried out. Proximity cards control access within the facility. Telehouse has a sophisticated power distribution system for resilience. Multiple diverse mains electricity feeds are supported by a UPS (uninterruptible power supply) system with diesel generator backup giving 10 days running fuel on-site. Telehouse provides VESDA fire detection and suppression.

• The secondary registry facility will be operated in Redbus Interhouse, Amsterdam, NL. This facility incorporates N+1 backed-up power and air conditioning, CCTV system covering all entrances/exits and main areas together with 24-hour digital recording; full perimeter alarm; PAC security card access system; VESDA fire detection and suppression.

There will be a small stock of pre-configured x86 servers as an immediate replacement for critical servers that fail. The Incident Response Team will change any failed server with one from the stock where possible. There will be 2 spare servers per core site, together with 1 spare server per satellite cluster.

Where possible Organic Names will ensure equipment will contain redundant components including multiple power supplies, multiple network connections, etc. for fail-over protection.

The following figure is a schematic diagram of the proposed primary core network infrastructure:

The following hardware will also be required at the primary location:

• Storagetek L180 Library with 6 x SDLT Drives (primary backup)
• Sun DLT8000 DLTIV tape drive (loghost)
• 5 x Cisco PIX 515 hardware firewalls

The following software will be required at the primary location:

• Veritas Volume Replicator
• Solaris licences for each V880

The following hardware will also be required at the secondary location:

• Sun DLT8000 DLTIV tape drive (generic backup)

Core / Backup Hardware Configuration:

This does not include office equipment and servers, such as the Windows-based x86 servers that will service the accountancy software.

Connectivity to each network facility will be diverse gigabit ethernet links on an open Gigabit port, using BGP4 as a routing protocol on an Extreme Networks Black Diamond router with dual PSU and dual processing backplanes. Border routing to each provider will be via Juniper M5-series routers.

Connectivity to each satellite cluster will be via local gigabit point-to-point links with dedicated open gigabit ports, with a dialup facility for remote engineering as required.

Connectivity and associated equipment has been specified in order to minimise the effect of possible denial-of-service attacks.

Each satellite location consists of a small cluster of servers in the following configuration:

Connectivity to each satellite location will be via open gigabit IP ports.

Flexible swap-out service and on-site support contracts will be negotiated with all manufacturers and suppliers in order to guarantee fast reactions in the event of a hardware outage requiring intervention.

RRP will be implemented in line with the current VeriSign system, as described in RFC2832. This will ensure that current registrars are left unimpacted by the transition to Organic Names.

The current CentralNic system uses the EPP specification given in draft-ietf-provreg-epp-06.txt, using the domain/host/contact details given in the following drafts:

• draft-ietf-provreg-epp-domain-04.txt
• draft-ietf-provreg-epp-host-04.txt
• draft-ietf-provreg-epp-contact-04.txt

Together with the TCP transport method described in:

• draft-ietf-provreg-epp-tcp-04.txt

It is anticipated that this will be moved from the test-bed stage within 28 days of the EPP protocol moving to a Proposed Standard. Registrars will be provided access to the system prior to the full deployment in order to test their own registration mechanisms.

In line with ICANNs requirements unless ICANN and Organic Names agree otherwise, RRP support will be deactivated 180 days from EPP reaching proposed standard stage.

The databases will each run on a Sun V880 Server with 4 processors, 8Gb RAM, 6 x 36.4-GB/10000-rpm FC-AL disks, DVD, 3 x power supplies and redundant cooling fan trays, running the Solaris 8 64-bit operating system and an Oracle 8i database. The specific version will be based on current software availability from Oracle.

Equipment within the database network is connected with dual homed 100Mbit connections.

There are four separate database units:

• Core database unit. (primary location)
• Query-only database unit, for Whois and zonefile generation. (primary location)
• Backup replication database unit, sited separately to the core and query units. (primary location)
• Remote replication database unit. (secondary location)

The Organic Names system components interact with the database systems as follows:

Key features of Oracle include:

• High-end data warehousing capabilities
• Sophisticated query optimisation
• Rich variety of integrated indexing schemes, join methods, and summary management features
• Very large database support
• Partitioned tables and indexes based on range, hash or composite partitioning
• Scalable parallel architecture for SMP and MPP platforms
• Unlimited database size
• Architecture supports thousands of simultaneous requests
• Online backups allows backups to be made without interrupting transaction processing
• Extended backup/recovery subsystem
• XML parsers
• User authentication and security
• Various indexing schemes: B-tree indexes, clustered tables, hash clusters and bitmapped indexes
• Parallel index creation and support for automatic index maintenance
• Sophisticated SQL optimiser
• Advanced resource management
• Full multilingual support, including Unicode UTF-8
• Database event triggers
• Logging and archiving

The database will initially be allocated approximately 70 gigabytes (GB) of storage, with approximately 140 GB additional storage available. This environment will support at least 10 million .org domain names, which is somewhat greater than Organic Names five-year projected registrations. Additional storage is easily added to this environment - not only does the hardware support the addition of significant additional space, but Oracle accommodates multiple storage systems.

It should be noted that the .org database size at the time of writing was estimated to be 10GB. Organic Names will be providing for growth of the database (including all related objects) of 75GB per annum based on CentralNics own database model, mostly relating to historical log entries.

Organic Names databases will easily provide adequate transaction processing for the .org registry. Using Oracle Performance Monitor, similar database configurations on equivalent Sun E4000 hardware have been observed to support up to 2,000 transactions per second. This substantially exceeds the projected maximum required to support the .org registry. In the event that additional processing is required, the initial Sun V880 configuration can be significantly upgraded through the addition of CPUs and memory. Finally, due to the continuous operation of multiple database servers, the addition of more powerful servers, such as Sun F6800 or Sun Enterprise 10000, is easily accomplished.

Organic Names will operate a total of four Sun V880 database servers in two locations: three at Organic Names primary location in London and one at Organic Names secondary location in Amsterdam, NL. 

The four V880 database servers will run in the following configuration:

Data is replicated between the active and backup sites using Veritas Volume Replicator. Veritas Global Cluster Manager continuously monitors the database at the active site, and in the event of a failure at the active site, either lon-db-3 or ams-db-4 will be selected as the new active database in that order. A database instance will be activated on the chosen database server, and the new active server will take over all database functions. In the event of an issue arising at the core site, registry-registrar services and master DNS services will also be moved to servers at the new active site. When service is restored at the primary site, a transition will be made back to the primary facility.

Additionally periodic snapshots of the database will be transmitted to Organic Names remote facility in Perth, Western Australia see section C17.7 for further information.

Extensive written procedures will guide all database operations, including schema changes, database changes, database fail-over, database backup, and disaster recovery. Although this database infrastructure allows for an extensive data warehouse with impressive reporting capabilities, Organic Names is not currently planning to build a full data warehouse as part of the initial .org registry implementation, given the anticipated size of the .org registry database. Reporting features that are required to provide ongoing customer support and billing functions will be provided from the inception of the registry.

Multilingual Support

For the past several years, the IETFs Internationalised Domain Names (IDN) working group has been attempting to create standards to enable support for domain names that incorporate non-ASCII characters. Organic Names intends to track the progress of the IDN working group carefully and to ensure that the .org registry supports multilingual domain names in a manner consistent with the conclusions of the working group.

Initially the .org registry will not support the registrations of new standard multilingual domain names until IETFs standards process has evolved. However, the registry-registrar protocol will use UTF-8 character encoding scheme for all transmission of data between the registry and registrars. UTF-8 is an encoding scheme used to transmit information in the Universal Character Set (UCS), which is intended to represent characters from all languages. UTF-8 has the characteristic of preserving the full US-ASCII range, so that non-multilingual characters are readable by software that relies on ASCII character values. The use of UTF-8 in the registry-registrar protocol allows Organic Names to easily add support for multilingual domain names as the standards process evolves.

Although not currently defined as a standard, Organic Names system will support VeriSigns current method of character folding in order to maintain compatibility through the registry transition.

Database Objects

• Registrars are the basic account building blocks. Each registrar consists of a name, company name, address, post/zip code, email address, telephone and fax number. Registrars have a credit accounts and may have extra marketing data stored.

• Domains are registered by Organic Names. Each domain contains a domain name and three handles a client/administrative handle, a technical handle, and a billing handle.

• Hosts are DNS servers. Several hosts may be linked to one domain, but are not exclusive to that domain.

• Invoices are requests for payment as issued to Registrars. Invoices may contain many different invoice items.

• Authentication objects are used for registrar authentication to the registrar console, etc. These may be client-side x509 certificates, PGP keys, passwords, or simple mail-from.

• History is comprehensive data about each transaction, modification, etc. which will be visible to administration staff, and assist in resolution of issues with any of the above objects.

Objects interact as per the following simplified schema:

The detailed attributes of each core object are as follows, with the exception of financial objects. Underlined attributes are primary keys, italicised attributes are foreign keys:

A domain may have one of the following statuses:

• Live: The domain is in the DNS zone files and active.
• On Hold: Due to non-payment or some other incident, the domain is still active but is not placed in the DNS zone files.
• Deleted: The domain has been deleted and may be re-registered by another party.
• Prohibited: The domain is not available for registration by a registrar or registrant.
• Evergreen: The domain is registered in perpetuity, and no bills will be raised nor the status automatically changed.

Database Integrity

A constant referential integrity check will be carried out as a daemon on the database cluster to detect dereferenced data. Checkpoints will also be used within the transaction log.

Object deletion will be covered later, but throughout the deletion procedure strict checks will be made for the purposes of preventing dereferenced data from entering the database, for example by deleting a host object which is referenced by a domain object thus creating potentially invalid data.

In the extremely unlikely event of database corruption, data recovery will be possible through Oracle's automated use of transaction logging and rollbacks.

Object Creation

Objects may be created at any time, with normal data validation being carried out prior to insertion of the object within the database.

The following rules apply to object creation:

Object Editing

The following rules apply to object editing:

Object Deletion

The deletion of objects must be handled with the utmost care, and indeed domain objects are not designed to be deleted: rather they are designed to be "disconnected" through the more temporary "on-hold" status.

The status of objects and the systems ability to delete them are:

The strict nature of the deletion status is to preserve referential integrity throughout the database, as mentioned earlier.

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

Registrars and registrants will not be able to edit the zone file directly. The building of zone files will take place automatically at an interval either established by technical staff as the optimum, or at a set interval defined by Organic Names management. In any event, zone files will be generated and published no less frequently than every three hours.

New versions of the zone files will only be published after successfully applying consistency and integrity checks on them. In order to prevent failures of major impact (eg. corrupted zone files on the master nameserver), the following consistency checks will be carried out after generation and before installing the new zones on the master:

• The transfer of the zone files to the primary nameserver will be verified by checksums.
• Installation of the new zone will be refused if it is significantly smaller than the last installed zone. Manual intervention will then be required. (This problem may arise if the zone file generation breaks, e.g. prematurely, or because of disk space or database errors.)
• Independent lexical analysis error check of the zone file.
• Regularly checking that all secondary nameservers report a serial number within one update of the primary nameserver.

Each zone file serial number will be in the format:

So for instance for an 11^th June 2002, 3am (GMT) update, the serial number would be:

Serial number calculation will be performed as per RFC1982.

A program will be used to query the database at the given intervals, and to build the zone file based on data it finds from all zones contained within. This script has been proven to be reliable, as it has been running on the CentralNic systems over a long time period. The code is stable, and can be run at any time to generate a new zone file.

The .ORG zonefile will use the following SOA values:

Exact copies of the zone files will be kept for up to 3 months. Notes of differences between versions of the zone files will be kept in perpetuity.

The eventual aim is to have real-time updates of the published zone file, so that registrations and modifications take effect immediately. Organic Names will be researching new DNS techniques in order to provide a faster service to registrars and registrants.

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.

Two servers, dedicated for the purpose, are used as the machine which builds all of the zone files periodically, as described in section C17.4, referred to as "lon-zonehost-1" and "lon-zonehost-2". Generation is split over the two machines equally, and logged remotely to the monitoring and logging host, before transmitting to remote nameservers. Zone publication occurs immediately following zone generation.

Refresh times in the zone file will then allow Organic Names core servers to update the zone file in any secondary server. Following on from this, the core DNS servers will not be impacted by the work of having to rebuild the zone file from the database, as this will be done periodically on a separate server.

It is imperative that visible zone files are maintained at all times. It is for this reason that the worldwide network has been specified.

During the transition period Organic Names will require use of the VeriSign constellation of gTLD servers as specified in section C18.5.

Secondary nameservers are located in:

Zone files are published over an IPSEC secure point-to-point virtual private network (VPN) to each location using the capabilities of the border PIX firewall as shown in the core network diagram, and verified through a periodic independent checksum utilising a tripwire-style approach. Connection requests generate a one-time 128-bit key utilised over an SSL link to circumvent network scanning. Refreshing of zone files and DNS reload are initiated by the core zone file generation machines every 24 hours maximum.

Each nameserver will be able to take on the role of the primary nameserver if required.

Nameservers will initially use version 9 of the Berkeley Internet Name Daemon (BIND), and Organic Names will be evaluating the progress of NSD authoritative nameserver software as it becomes more readily available from the publisher, NLNet Labs.

BGP routing procedures combined with an anycast load balancing mechanism will allow the advertising of only two DNS name server names and addresses while the BGP routing ensures that either the nearest or second-nearest DNS server, independent of where the requester is geographically located, will service the requester.

Access to zone transfers from any primary server is restricted to approved secondaries only. Host count mechanisms as performed by RIPE, UKERNA, etc. will be supported through a separate server set aside for this purpose.

For access to zone transfers to be approved, it is envisaged that the requesting body must agree to a contract restricting use of the data in order to prevent usage such as unsolicited commercial email, etc.

Transfers of zone data to secondary servers will be accomplished via a full zone transfer (AXFR) or incremental zone transfers (IXFR). Additionally, transaction signatures (TSIG) will be supported, as defined in RFC2845 for the transfer of zone data for the secondary service.

As the zonefile grows to above 4GB in size, the satellite services will be gradually replaced by 64-bit systems in order to deal with the memory and filing requirements. It is anticipated that this will happen within 2 years of the award of .org to Organic Names.

IPv6 Support

The zonefile generator has the ability to generate AAAA and A6 records within zonefiles, and therefore include IPv6 glue records. Once the AAAA/A6 argument has been fully resolved Organic Names will fully support domain names within the IPv6 space.

Billing and collection systems. Technical characteristics, system security, accessibility.

Many registries are run from a technical standpoint, with little quality-of-service for the accounting departments. With 6 years of experience in this industry CentralNic has built a highly flexible accounting system, which provides registrars with unique multi-currency accounting facilities through the registrar console.

The core database system will be linked closely with the financials system using Sage Line-500 Enterprise Edition. This enables the staff and registrar console systems to link in and provide instant statements of account, the ability to receive payment online and seamlessly tie in with the general ledger. Payment will be triggered by the Domain Expiry value.

The reporting structure of the Organic Names system is provided through a web interface - therefore the reporting can be integrated within the Console system, supplying live key performance indicators to management, and optimising project execution.

The core servers for the billing system will be two highly-specified Intel-based application servers. They will be secured behind the Cisco PIX firewall, and any reporting/manipulation will only be permissible through the VPN to authorised personnel, administered via a username/password arrangement.

Email Billing & Reminders

The Organic Names system allows for an automated setup of invoicing, reminders after a preset period, withholding of domains, and subsequent deletion.

The following boundary timescales apply within this process:

If at any stage a renewal request is generated by the registrar typically via the EPP system an invoice is generated immediately and the expiry date e is altered to reflect the payment.

The system will email "Low Account Balance", "Insufficient Funds", and "Balance Forecasting" notifications to all customers as an account management service. The system will also provide emailed monthly account summaries and online transaction reporting tools.

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.

The goal of the Escrow Process is to periodically encapsulate all Registrar-specific information into a single Escrow File and to make this file available to a third party for escrow storage. Existing Daily and Weekly reports as detailed below will be used to construct the Escrow File because these reports, when taken together, describe completely the entire set of domains, nameservers, and registrars.

Organic Names will select a suitable escrow agent within the United Kingdom through a tendering process.

Organic Names will deposit a complete set of Registry Data into escrow on a weekly basis by electronically and securely transmitting a snapshot of each operational Registrar's data. The snapshot captures the state of each Registrar's data at the time the snapshot was created.

On a daily basis, Organic Names will securely and electronically deposit a transaction log for each operational Registrar representing transactions that occurred over the previous 24 hour period. This will act as incremental updates to the Weekly Deposit Materials and will include all Registrar activity, such as add, delete, and transfer of a domain name.

Backup Methods

Both physical and electronic escrow transport methods will be used.

Escrow data will be in a format to be agreed between Organic Names and ICANN.

Escrowed backups will be made in plain TAR (for portability) to DLT tapes. A DLT drive at the central Organic Names office will be used for escrow backups, which will be stored offsite.

Rebuild Procedures

In the event of a serious database failure, registrations will be stalled until such a time as data integrity can be confirmed. In such circumstances registrations will be queued to complete registration at a later stage to be no less than 6 hours after the issue has been resolved.

Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.

Every domain name registry should operate a Whois service conforming to RFC954 to allow open and clear access to domain objects within a database (subject to local data jurisdiction laws), and Organic Names is no exception.

Whois queries are handled by 13 separate Whois servers sited in the same locations as the nameservers, and load-balanced using DNS technologies. Each Whois server is a high-specification Intel application server which queries the secondary retrieval database (lon-db-2) directly.

During normal operation, all registration and information updates sent from a Registrar to the Registry are stored in the primary database (lon-db-1). The information in lon-db-1 is replicated to a backup database (lon-db-2) at regular intervals, normally within five minutes. The Whois service uses database B as its source of information. The time lag in the Whois information update is determined by the database replication interval. Organic Names will notify Registrars in advance when changes to the Whois service update schedule occur.

The Whois daemon software is a multithreaded daemon application written in C. Unlike most other Whois daemons, it is stand-alone (i.e. not spawned from inetd).

Responses to Whois queries look like this:

Domain Name: MYDOMAIN.ORG

Registrar: Joe Domains Inc.

Registrant: (I5502)
 Christopher Andrews
 163 New Kings Road
 Fulham
 London SW6 4SN
 United Kingdom
 Email: chris@mailbox.net.uk
 Tel: +44 870 845 9292
 Fax: +44 870 845 9293

Record created on: 8 Sep 2000
Record expires on: 8 Sep 2002
Record last updated on: 28 Sep 2000

Domain servers listed in order:
 DNS.MAILBOX.CO.UK 195.82.96.40
 NS1.MAILBOX.CO.UK 195.82.96.6

>>> Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT <<<

--
This whois service is provided by Organic Names Ltd and only contains information
pertaining to Internet domain names we have registered for our customers. By
using this service you are agreeing (1) not to use any information presented
here for any purpose other than determining ownership of domain names (2) not
to store or reproduce this data in any way.
Organic Names Ltd - www.organicnames.org

Currently many registrars do not maintain their Whois server in a production environment, nor keep it up-to-date for referral through the "Referral Whois" system detailed in RFC2167. Bearing this in mind, the Whois queries will be centralised. This is not to say that referrals will not happen to the centralised Organic Names server, but centralisation will remain the key to a reliable service.

In order to minimise abuse, a constraint will be placed upon the number of queries which may originate from one particular IP address over a single 24-hour period: this method has been implemented by several registries and is an effective way of combating what effectively amounts to a denial-of-service attack. Queries may also be performed from the Organic Names website, and will be similarly limited. An opt-out method will be available for legitimate users who carry out large numbers of queries.

The Registry Whois service will be served via port 43, and will support the following methods of public search (as currently supported by VeriSign):

• For a domain name: whois "domain mysite.org"
• For a registrar name: whois "registrar Bob Domains Inc."
• For a host nameserver: whois "nameserver ns1.mailbox.com" or whois "nameserver 195.82.98.1"

By default, Whois performs a very broad search, looking in all record types for matches to your query in these fields: domain name, nameserver name, nameserver IP address, and registrar names. Use keywords to narrow the search (for example, 'domain root'). Specify only part of the search string to perform a "partial" search on domain. Every domain starting with the string will be found. A trailing dot (or dots) after your text or the partial keyword indicates a partial search. For example, entering mack. will find Mack, Mackall, Mackay, and so on.

Organic Names intends to develop and offer a subscription-based interface to the Whois database that will permit interested third parties to conduct enhanced Whois searches using boolean and character string technologies. Enhanced search functions will include the ability to identify (i) registered domain names that incorporate a certain character string, or (ii) all the domain names registered by a certain registrant. This service will be a follow on development project that is not expected to be operational in the first 12 months of operations.

An additional, more restrictive, Whois server will be installed in the future to provide domain object access in XML format.

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

Organic Names will take every reasonable step to ensure the security of its systems. This comprises hardware security for the servers, network security in the form of multiple firewall layers, and also physical security in the form of access restrictions at the facility centres that host its servers.

Hardware Security / Physical Security

Hardware security and physical security tie in together very closely. All of the servers that handle its network are in locked cases - which in turn are in locked cabinets, in a locked cage, within the facility centre. The only people with access to the cage that its equipment is kept in are the facilities staff, and senior technical staff of the company. This rule is very strictly applied. Indeed - many of the colocation providers restrict the access to their own rules - anyone wishing to have access to any of the CentralNic servers needs photographic ID, which has previously been communicated with the facility staff by an authorised contact. Otherwise, the person is not allowed into the facility. In addition to this, most of the machines are in locked cases situated in locked cabinets. The same rules apply here - only senior technical staff and the facility staff have keys for the cabinets and also for the machine cases. This ensures that no-one can just walk into the facility centre, into the cage, open the cabinet, and tamper with the machines.

Closed-circuit television is used to monitor all areas, recorded via a time-lapse system and archived.

Facility centres are fully power protected, and also have fire detection and control systems, in addition to full environmental monitoring and HVAC Air Conditioning Systems. Organic Names has selected data centres which are earthquake-proof - enabled by seismic bracing within the structure of the building itself. This is more prominent in earthquake prone locations, but most centres have this level of protection.

Full audit trails are available from the provider at any time - this ensures that actions taken can be traced. Everything is recorded - date and time of exit and entry, the escort to the cage, what was taken in and out in terms of hardware, and technical staff will keep a record of actions taken and work carried out on systems.

Network Security

Access to machines over the network is the biggest single point of access, and hence, the one that requires the most protection. To this end, Organic Names employs hardware firewalling technology from Cisco Systems, which also provides it with network access control, and another layer of traffic logging.

Servers that cannot entirely be secured on RFC1918 addresses will sit in a demilitarised zone (DMZ) separate from the main registry network. Traffic passing from the Internet or the DMZ to the secure internal network must pass through a firewall enforcing a strict security policy.

Management of servers will only be performed using a management LAN or through console access. Firewall rules will prevent in-band management through other mechanisms.

Cisco Pix Firewall

Organic Names uses Cisco Pix Firewalling units at each location of servers to provide full hardware protection - these units are completely self contained and thus maintenance free. By using multiple units, not only does one get fail-over / redundancy of the firewalling, but one also gets the ability to reroute traffic between machines seamlessly. The units communicate with each other over an encrypted connection - this allows Organic Names to effectively set up a totally private internal network for all of the global servers whereby the firewall hardware handles the address translation and routing of traffic.

Organic Names utilises a minimum of 2 units in each location for redundancy. These units are effectively configured to run in the same state at all times by communicating directly across a local channel so that if one unit loses network connectivity, power, or fails, the other unit will take over with minimal disruption to services.

In combination with managed switches, this provides Organic Names with a fully redundant hardware firewalling solution, and with the VPN features of the PIX hardware, Organic Names has a highly secure method for transferring sensitive network traffic. This is especially useful for network logging facilities, and also transfer of data to a machine dedicated for backup purposes, as all the data is transferred over a secure connection. All traffic that does not originate from a public Internet connection is encrypted, thus protecting the intellectual property within the data, as the database is never transmitted in the clear or revealed to the outside world.

Performance

The Cisco Pix units that Organic Names utilises can handle 125,000 simultaneous connections - given that most Unix and Linux machines can only handle 65,000 connections at once, it is very unlikely that the units will be overloaded. Organic Names is more concerned about other hardware, such as routers, which would probably not withstand such load Organic Names will do everything it can to prevent problems in this area. The PIX product does have "floodguard" technology, however, which is designed to prevent such things as the recently publicised "Distributed Denial Of Service" attacks on high publicity sites.

The main role of the Pix units, however, is not to provide fail-over, but to provide firewalling. To this end, all traffic from the Internet that is not coming over the encrypted link is highly restricted. On the server side, only database ports will remain open to a restricted set of sources. At DNS server level, Pix firewalling in combination with software restrictions will secure the DNS servers from unauthorised access attempts.

Passwords / Access

The primary method of server authentication will be through use of a one-time key. Where server passwords are used, they will be changed not less than once every week. Additional methods of authentication are used - for remote access, SecureID and Cryptocard technology ensures that only authorised senior technical staff have access to the machines, by requiring a hardware based token authentication. Such hardware tokens guarantee that passwords are only valid for 2 minutes at a time, thus greatly reducing any risks in the unlikely event of traffic being intercepted, or of passwords being stolen. In addition to the token code, a user PIN is also required. In the event of a token being lost or stolen it can easily be rendered useless by setting an option on the authentication server. This solution has the added benefit of logging all attempted logins on the authentication server.

All sensitive traffic on the network will be encrypted where it traverses untrusted networks, as described above. This makes it impossible for an intruder to intercept passwords in transit over the network and use them to access machines in an unauthorised manner. Also, machines will be configured to only allow connections from certain sources, so an attacker would have to already be within the management LAN, and have a one-time key, and a password, to move across the network. This allows legitimate access without difficulty, but unauthorised access is nearly impossible.

New passwords are communicated to facility staff on a need-to-know basis. Console logins only require a username and password, as it is impractical to give facility staff hardware tokens to perform remote maintenance if required. Organic Names will be able to do everything remotely, as the combination of a Terminal Server, remote power switch, and network access, ensures that there is effectively nothing that cannot be done remotely that could be done at the machine console, except in the case of hardware or provider connectivity problems.

Network security issues will be the responsibility of the Abuse Team.

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.

Given current ICANN figures, it is estimated that there will be an average of 50,000 domains registered per month with a peak of 100,000. Given that the current CentralNic system can handle approximately 30 registrations per second this will not pose a problem.

In any case, the CentralNic system is designed so that peak load can be scaled across multiple processors and multiple servers using a load balancing algorithm. Additional servers can be brought into the cluster at very short notice, so scalability will not be a problem.

Organic Names will maintain a 60% capacity threshold for hardware expansion, with an assumption of 25% growth per year in system capacity planning. There will be a planned migration of satellite server hardware to a 64-bit operating system within two years.

Full statistics will be produced and updated daily to assist the technical team in capacity planning. These include, but are not limited to, number of domains registered, methods of payment, monies collected and owing, peak hours, Whois database query volume, automaton volume, methods of registration, etc.

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.

A full ticketing system will be implemented for requests from registrars for assistance, integrating email, telephone and web-initiated queries. A web-based interface will also be provided in order to allow users and registrants to view ticket progress. Auto-responses and priority queuing will be implemented for urgent queries, with customer service representatives able to increase priority for registrars on a case-by-case basis.

24/7 multilingual telephone support will be provided initially in English, French, Spanish and German CentralNic already employs multilingual support staff and translate technical documents into these languages. Further languages will be introduced as and when required. Language support will be mirrored by multilingual versions of help documentation and website information.

The support given on the web site will be of paramount importance. Organic Names will be providing a full list of Frequently-Asked Questions and How-To documents on each aspect of registration and modification of domain names, as well as a series of stock answers to common questions which may be served via email.

Three teams will be responsible for customer interaction:

• Third-line support Team a customer-facing group which will handle complex queries which the outsourced call centre team cannot deal with.
• Abuse Team responsible for IT security management.
• Incident Response Team responsible for internal technical issues, server upgrades, change management.

Support Procedure

Organic Names is dedicated to adherence of Internet standards, and will actively participate in the formulation of new drafts and standards. Past experience with CentralNic has involved participation in the Internationalised Domain Names standards process, the EPP specification, and ENUM test-bed specifications.

Organic Names fully backs adherence to the relevant portions of the DNS standard given in STD0013, and the transport protocol specifications given in STD0005, STD0006 and STD0007.

Specifically Organic Names will also follow:

954: NicName/WHOIS

Organic Names will adhere to the specifications for Whois service given in RFC954, as detailed in section C17.8.

1034: Domain Names Concepts and Facilities

1035: Domain Names Implementation and Specification

2181: Clarifications to the DNS Specification

Organic Names will comply with the requirements for SOA values, type NS RRs and glue records (using type A RRs) given in RFC1034 and RFC1035, and clarified in RFC2181. Typical SOA details for the Organic Names zonefile are given in section C17.4, and will be evaluated on a regular basis by the Advisory Board as per the requirements given in RFC2181.

1101: DNS Encoding of Network Names and Other Types

Organic Names will comply with the requirements for correct reverse name lookup on all its servers, and co-ordinate with RIPE, ARIN and APNIC for correct delegation of IP allocations as per each organisations requirements.

2182: Selection and Operation of Secondary DNS Servers

Location of secondary DNS servers will be regularly reviewed by the Advisory Board to address any reachability issues.

Additionally, Organic Names will commit to evolving standards such as IPv6, ENUM, DNSSEC and Internationalised Domain Names.

System reliability. Define, analyse, and quantify quality of service.

Quality of service definition

Shared registry service (RRP/EPP)

The shared registry service shall be considered to be up during any minute long interval in which 99% of transactions are successfully completed within two seconds.

Email Automaton

The Email automaton shall be considered to be up during any hour-long interval in which 99% of transactions are successfully completed within 10 seconds.

Whois

The Whois service shall be considered to be up during any minute long interval in which 99% of all requests return correct data within two seconds.

DNS (cluster)

An individual DNS cluster shall be considered to be up during any minute long interval in which 99.9% of all requests to the cluster return a correct response within 500 milliseconds.

DNS (service)

The DNS service shall be considered to be up during any interval in which at least half of the total clusters are considered to be up.

Registrar Console

The Registrar Console shall be considered to be up during any hour-long interval in which 99% of all requests to the console return a correct response within 2 seconds.

Maintenance Scheduling

In order to perform periodic maintenance, Organic Names will also schedule maintenance windows for two hours each week. Although this weekly maintenance window will exist, Organic Names recognizes that any downtime can be extremely disruptive to both registrars and end-users. However, due to the extremely resilient nature of its network and systems Organic Names anticipates that the weekly maintenance window will not be disruptive to registrars and end-users.

Disruptive maintenance windows will only be used under the following circumstances:

• Registrars will be notified at least 7 days prior to the maintenance window.
• Organic Names will make reasonable endeavours to ensure that there will be no more than 30 disruptive maintenance windows during any year.

Service Levels

The following service levels will be adhered to in any one calendar month:

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.

The international network exists to provide sensible and fast routing of DNS queries. It also provides multiple redundancy.

It is worth noting that the total, long-term failure of a single node does not, in fact, materially impair Organic Names service. However, each location has full outage prevention systems as described below.

Organic Names will protect the systems it invests in as much as possible. This includes such things as dual power supplies and UPS cover for all parts of its systems, hardware RAID to protect the integrity and availability of its database and its servers, and hardware monitoring to ensure that any potential problems are discovered early and can be resolved before they develop into issues which will affect its customers.

Checking scripts are provided to ensure that referential integrity of the database is maintained at all times, and automatically correct any anomalies while bringing them to operator attention via email or pager. These scripts will include constant SOA verification, dummy registrations through the automaton, checksum-verification of websites, etc.

Organic Names Outage Prevention Measures are described in more detail below:

UPS

In addition to the UPS provisions made by data centre facilities, Organic Names integrate UPS products from APC - a proven leader of high quality UPS equipment - to ensure that its servers keep on running through power failures. These units will be connected in-line to one PSU in the multiple-PSU systems given in section C17.1.

The batteries on the UPS systems will keep its servers running for at least 30 minutes - this is in addition to the power protection systems at each server facility. Organic Names anticipate that the combination of its own UPS units with 30 minutes runtime plus facility systems will mean that Organic Names never suffers a power outage.

The UPS systems are complemented by a MasterSwitch solution from APC - this allows Organic Names technical staff to selectively turn the power on and off to any connected socket remotely. This gives Organic Names greater control of its servers and allows it to perform almost all problem resolution remotely.

If a piece of software crashes for whatever reason and hangs the machine, generally it is impossible for the machine to be rebooted remotely - this would involve a call to the facilities management staff to reboot the machine. With this system in place Organic Names can perform this task itself, quickly and easily prior to requiring use of facility staff.

Both the UPS systems and the MasterSwitch systems are fully network connected Organic Names monitoring systems are capable of extracting information from both UPS and MasterSwitch via SNMP (Simple Network Management Protocol), an industry standard method for extracting and using network data. Organic Names can tell at a glance what the power status on a UPS is, it's runtime on batteries, it's temperature, etc - in the event of a battery failure staff will be notified immediately, and as such can schedule replacements / repair work to correct the problem.

Any problems with UPS hardware will not cause outages to the servers that are connected. For example - if a battery in a UPS fails, either due to manufacturing defects or through general use (UPS batteries are quoted as lasting around 2 years) - the UPS will send out an immediate alert, but will continue to power the systems connected to it. Staff will arrange for a resolution to the problem immediately. Even replacing a battery on the UPS systems does not require that the load on the UPS is turned off - this task can be performed quickly and easily by any member of staff to restore the unit to full use as soon as possible.

If the facility of a server loses power for a length of time that requires operation of a UPS, staff will be paged and alerted. If the power remains out for such a length of time that UPS battery power starts to run low, then automatic software will shutdown servers cleanly in turn, which allows Organic Names to keep at least one server running for as long as possible before a power failure. In the event of all power to a facility failing, monitoring systems will control the scheduled transfer of servers.

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.

The ability to restore data to any machine is highly dependent on it having a network connection. If a machine suffers total failure it is possible to do a minimal install to that machine and then to restore from backup in a short period. In the meantime other machines will continue the work of the failed unit, so registrars and registrants will never see any problems. Tasks may take slightly longer to execute, depending on which machine fails, but the end result is hopefully a totally resilient solution.

A jump-start kit will be stored at each remote facility, comprising installation software for each machine. Additionally Organic Names will utilise such technologies as TFTP on separate LAN networks where required.

24 hour paging and support staff will alert the Incident Response Team to any problems as soon as they are noticed - problems are detected within minutes of occurrence by the automatic systems in place.

Senior staff are on call at all times and if support staff cannot resolve a problem in a defined period of time, they will follow procedures to bring senior staff out to resolve the issue. It is not possible to give a guaranteed time of fix for all problems, as the nature of a problem may make it more difficult to solve than at first thought, and may leave issues outside of Organic Names control, such as acquiring replacement hardware.

On the issue of replacement hardware, Organic Names will have backup cluster units at its premises ready to "slot in" in the event of UK problems. Any problems that result in hardware failure or otherwise will be solved as soon as physically possible - if Organic Names establishes that an entire global location has suffered hardware failure (a very unlikely event), the first response will be from support or technical staff, to keep services running on alternate machines in different locations. If the problem is hardware failure, a replacement unit or units will be sent out to the affected location and a member of senior technical staff will go to the location as soon as physically possible, to replace the units and restore service to the area. Due to the resilient nature within Organic Names network and systems, other units will take over the job of the failed units almost immediately. However, there may be a short period of downtime while the backup units take over the job of the failed units, but Organic Names will use reasonable endeavours to ensure that any downtime is kept to an absolute minimum.

System Recovery Procedures

In the unlikely event of a system outage occurring within the Organic Names network, systems monitoring will alert support staff and senior technical staff immediately.

There are four stages in administration of a system recovery:

1. In-band remote administration of the machine.
2. Console access via a terminal server.
3. Use of the remote MasterSwitch (see section C17.14) to power-cycle the unit.
4. Use of technical staff within the facility to power-cycle the unit.

Recovery administration will be carried out by the Incident Response Team.

Procedure for restoring from an unexpected outage

If a catastrophic error occurs on a server which causes failure of that server, the primary aim will firstly be to ensure no loss of service to the customers. Once this has been achieved, restoring the failed unit to a working setup is the next highest concern. If it is discovered that a disk has crashed or failed, the unit will be swapped out and a replacement, pre-configured unit will be swapped in as soon as is physically possible. The failed unit will then either be returned to the vendor on a 48 hour turnaround, or if the problem is small, will be fixed as soon as possible. If a machine can easily be restored to working order, it will be monitored closely by the Incident Response Team to ensure the problem does not recur, then if all tests are OK, the machine will be swapped back into service at a time that is not inconvenient to users. This is the primary logic behind having at least 3 servers in every location.

Redundant / Diverse Systems

This section is covered by section C17.14 - System Outage Prevention.

Recovery Processes

Due to the nature of failures, it is impossible to describe a recovery process for each. As such, recovery from unpredictable outages will be undertaken using reasonable endeavours, with the aim of restoring service as quickly as possible.

Data recovery will be achieved through replay of transactional logs within Oracle, and if necessary through use of backup servers and queue logs.

Training of Technical Staff

Staff will be trained in-house by Senior Technical Management to deal with potential recovery issues as they arise. There will be demonstration systems which will have to be restored by the staff, under supervision, to gain experience in re-installing the OS and performing a restore of files from the backup server. This will enable backups to be undertaken by staff without senior staff supervision, but should a machine fail and backups be required, the company will undertake to have a member of Senior staff present to supervise and oversee the entire recovery process, and to co-ordinate other services, such as fail-over to secondary / backup units, liasing with component manufacturers, etc. If such an event occurs a member of senior staff will be called - there will be a rota of senior staff on call 24/7, to ensure availability.

Availability of software, operating systems, and hardware needed to restore the system

If a server fails for any reason, there is always a copy of the media containing the correct OS of that server within the building. If a remote server fails, the member of staff that travels to deal with the issue will also have a CD copy of the media. Hardware availability is pre-arranged using service contracts with the manufacturers of the server equipment, i.e. Sun and FlexiServ.

Backup Electrical Power Systems

All facility centres have redundant power supplies and UPS, which are supplemented by generators. This provides a guaranteed service at all times. Servers are also protected by their own UPS which will be in addition to any facility power protection, and will provide a runtime of 2 hours on the core Database servers, and 30 minutes for the global clusters.

Projected time for restoring the system

Organic Names estimates, based on its own experience, that after a machine is restored to a working state, it will take no more than 45 minutes to restore it to it's original status. This time is obviously in addition to any hardware problems that occur, but redundant machines will continue the work of the original machines while maintenance takes place. If a problem occurs with a core database server, the projected time could be a lot higher than this. As such, estimated recovery times are to be confirmed.

Procedures for testing the process of restoring the system to operation in the event of an outage

Backup tapes and procedures will be tested every month under supervision of a member of Senior Technical Staff. This is to ensure that staff are kept up to date on any changes in procedure that take place, and also any new technologies that may have been implemented. This will also ensure validity of backup tapes and offsite backups.

Documentation kept on system outages and potential system problems that could result in outages

In combination with monitoring software, every outage is recorded into a database. Resolutions, notes, comments, etc are all entered into this database also via a web based administrative form - this allows management and/or technical staff to pull out reports in real-time on any given service or host. In a similar fashion, printed and typed documentation is stored containing details of potential problems that could result in outages, how to check for them, how to fix them, and what to do if the described method doesn't fix them.

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.

Recent examples of corporate insolvency in the telecommunications carrier market have shown that the descent into creditor protection has often been very swift. Nevertheless, insolvency leading to creditor protection filing has in most cases provided an opportunity for clients to make alternative technical arrangements to maintain uninterrupted service, with administrators looking to preserve normal operations until a buyer for the assets as a whole or in part can be found. Organic Names has, in addition, looked into the possibility of taking out insurance to protect against this eventuality.

Organic Names will investigate, and maintain vigilance on the financial stability of its suppliers, as well as, wherever possible, use a strategy of adopting multiple suppliers, for instance in respect of telecommunications services.

Organic Names will also use provider-independent IP space for both primary and secondary core networks.

On the question of other factors that preclude restored operation, these are covered by the recovery procedures as detailed in section C17.15.

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:

Steps of the proposed transition, including sequencing and scheduling.

The proposed transition to the new system will be a transparent mechanism, documented regularly on a publicly-accessible website. This will enable both Registrars and Internet users to follow the progress of the transition. Users will be encouraged to participate in test stages and report back on problems via the mechanisms given in C18.7.

The initial milestones for the transition will be:

Each stage will be monitored closely by the Advisory Board Technical Group, and will include:

• Regular reviews of performance, speed and accessibility of test systems.
• Periodic climate audits of chosen data centres, responsiveness, etc.

The technical progress on the transition project will be assessed relative to the technical or contractual requirements as set by ICANN and Organic Names. The formal reviews will be conducted at logical transition points in the development effort to identify and correct problems resulting from the work completed thus far before the problem can disrupt or delay the technical progress. The reviews will provide a method for all parties to determine that the development of the Organic Names system has met contract requirements.

The duration and extent of any interruption of any part of the Registry Function.

Planned outages will be carried out on a case-by-case basis as per the timescales and durations given in section C17.13. It is not anticipated that there will be any interruption to the existing registry service other than to alter root DNS records for .org, which will result in a 12-hour cessation of updates reflected in the zone files to the .org servers, as a result of DNS propagation delay.

In the event that unforeseen interruptions occur, registration requests will be queued and processed to the timescales given in C17.7.

Contingency plans in the event any part of the proposed transition does not proceed as planned.

Every transition milestone in section C18.1 will be monitored closely, and database software will allow for data rollback if there are any unanticipated issues.

The effect of the transition on (a) .org registrants and (b) Internet users seeking to resolve .org domain names.

The effect of the transition on .org registrants will be minimal, as Organic Names will be requiring VeriSign to forward .org requests to Organic Names as specified in part 5 of section C18.5.

There will be no effect on the .org DNS resolution. It is of the utmost importance that the changeover is invisible to the average Internet user.

The specifics of co-operation required from VeriSign, Inc.

There will be various levels of co-operation required from VeriSign.

1. Initially VeriSign will be required to regularly escrow the current .org database in order to accurately work on database capabilities and sizes, together with several time-stamped registration and change requests covering 1-month periods in order to assess the load of the current VeriSign system.

2. Organic Names will require access to the current specification and source-code for the VeriSign GRS software in order to ensure that functionality is maintained throughout the transition and into the new Organic Names system.

3. During the dual-operation stage (milestone 6) VeriSign will be required to forward copies of all .org registration and change requests to the Organic Names system in order to ensure identical registry requests are being processed, resulting in identical data.

4. VeriSign will be required to maintain the root zonefile of .org using its global network of nameservers until milestone 7 is reached.

5. Additionally, VeriSign will be required to forward future .org requests to Organic Names for a period not less than 6 months after milestone 8 is reached.

6. VeriSign will place an appropriate message on its Whois, and forward requests for an appropriate period from milestone 8 onwards.

Any relevant experience of the applicant and the entities identified in item C13 in performing similar transitions.

During CentralNics 6 years of operations, there have been 2 major rewrites of the registry software. Both rewrites have been carefully managed to provide for seamless transitions of the kind required for the .org gTLD. Each rewrite has caused minimal disruption to existing users.

Additionally, CentralNic has assisted its own registrars in porting domain registration software to register domain names with other ccTLD registries.

Nominet UK has carried out three major system rewrites in order to address loading issues and system flexibility.

Any proposed criteria for the evaluation of the success of the transition.

The following pro-active steps will be taken to ensure an accurate evaluation of the transition:

• The Advisory Board Technical Group will evaluate outage frequencies (if any) at weekly periods, reviewing progress and plans.
• The general Internet population will be invited to participate in an online survey to gauge end-user reaction and satisfaction with the transition.

In the end, the ultimate gauge of success will be ensuring that those registrars who do not choose to take advantage of the new registry services do not notice the registry transition, or have to make as few alterations to their internal systems as possible.

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

The Advisory Board technical co-ordination function will review regularly (no less than every six months) and advise on necessary policy changes in order to comply with future ICANN-developed policies. The Vice President of Policy has the specific remit of ensuring compliance with all agreed policies.