C18.1. Steps of the proposed transition, including sequencing and scheduling.

Project Plan

Work Stream tasks

Legal

 - We will have established the standard registrar contract before registry migration begins.

 - Registrars will be required and assisted to enter into those contracts before they can add registrations in the new registry,

 - Data protection registrations (plus meet with commissioner) will be put in place.

 - Complete ICANN contact.

Management, Administrative & financial

Registrar accounts with the necessary financial facilities will be in place before the registry migration starts.

Appropriate insurance policies

Create a VeriSign liaison process

Create a transition project team.

Support

The preparation described in C15.11 will be in place before the registry migration starts.

Specifically:

 ·  the registrars are contacted and given details of the registry changeover plan.

 · The SSL keys and certificates used by to secure the RRP sessions will be issued by Unity Registry.

 · the and C++/Java/Perl toolkits will be made available

 · The scheduled down time will be indicated if we cannot provide seamless migration (see later)

Technical

Creation of org registry specific functionality

We write an RRP interface, in addition to the current EPP and XML-RPC interfaces to its registry. This will be used initially by VeriSign during the data transition, and later by registrars when the changeover is made.

In addition to the functionality provided for normal operation or the registry the RRP interface will additionally have the ability to log all requests to a specific change log. This will facilitate the registry migration described below.

Creation of real-time registry to registry message bridge (if possible)

Unity Registry/VeriSign implement an RRP “splitter”
We write a lightweight daemon which:

a) Decrypts the RRP request using VeriSign’s private key, checks if the request is .ORG related and if so encrypts it using Unity Registry’s certificate and sends the request to the AusRegistry RRP server.
The Unity Registry RRP server will queue updates until the main data load is complete, at which time they will be applied to the Unity Registry database.

b) Tunnels the original encrypted request and its response to/from the VeriSign RRP server.

The RRP splitter will ensure that registrars experience minimal downtime as the main data dump is generated and imported into the AusRegistry system.

To place the RRP splitter in production mode, it should be run at VeriSign on the standard RRP port, TCP 648 and the original RRP servers should be run on a different port, to which the RRP splitter will tunnel.

If this is not desirable, VeriSign may wish to alter its RRP servers to send a copy of the request to Unity Registry.

If the migration to EPP for org registrations has commenced we have two options

a) create an EPP splitter in a similar fashion

b) Agree a business object to business object level message interface which would be independent of the protocol arriving at the SRS system.

As a last resort we should have some form of live access to logs of VeriSign registry updates.

Trial connections of registrar systems to Unity Registry

To enable registrars to be confident that their systems connect and interact correctly with the new registry, a test environment will be made available 30 days before the new registry is due to go live.

This will have the added advantage that it will allow registrars to confirm that their systems are capable of routing org messages to a different registry to that for com and net

Trial Conversion of “thin” VeriSign data

Importing the current .ORG data into our database should be a straightforward procedure; we already have code written to import data from various sources such as BIND zone files, SQL databases and delimited text files, and configuring new data sources is trivial.

We will develop specific scripts for quickly reading, verifying and loading the data into the new registry system. The data transferred will include

Registrar details, domain delegation details, domain expiry dates and nameserver details are all available from VeriSign’s registry system. Domain delegation details comprise a minimum of two and a maximum of 13 nameservers. Nameserver details comprise a minimum of one and a maximum of 13 IP addresses.

Several trial runs will be performed on the data migration processes outlined below, followed by as much testing as possible before the live registry changeover is executed.

We will develop specific scripts for quickly reading, verifying and loading the data into the new registry system. The data transferred will include:

 · Registrar details

 · Domain delegation details

 · Domain expiry dates

 · Nameserver details

All of these are available from VeriSign’s registry system.  Domain delegation details comprise a minimum of two and a maximum of 13 nameservers.  Nameserver details comprise a minimum of one and a maximum of 13 IP addresses.

Trial propagation of zone files to VeriSign

Prior to live date we will test zone file propagation from the new registry to test VeriSign Name servers.

This will involve making zone file transfers from the new stealth primary name server to the VeriSign main secondary or staging server.

These tests must be performed at the volume and frequency expected in the live system.

To facilitate this TSIG keys will be exchanged at this time

Migration of the live registry function

The availability of registrar access to the VeriSign registry during this migration will depend on the ability of VeriSign to forward registrar updates to our system during and after the data extract and import procedure. (see Creation of real-time registry to registry message bridge above)

We therefore have two options for the migration of the registry function:

a) Seamless migration of the live registry function

 ·  The registry to registry message bridge is installed and activated on the live systems

 · The live data base is exported, the last applied transaction is noted NB it must be implemented in this way because you dump the database and install the splitter at exactly the same time. Unless this coincides with an SRS upgrade where he system is taken off line.

 · The data is imported into the new registry

 · During this period the message bridge is logging all differences between the two systems

 · Queued requests are then applied to the database starting from the transaction after the last applied to the database.

 · When the all the queued requests have been processed, the message bridge servers on the new registry are set to update the database rather than queue

 · The new registry database is now live and is an authoritative source for the generation of WHOIS and zone file information

b) Seamless migration of the live registry function not possible

If the registry to registry message bridge is not feasible, and VeriSign are unable to provide details of registry updates during the data migration process, we could resort to the following plan which involves registry downtime:

 · VeriSign removes registrars’ write access to the registry. This would be essential to ensure no loss of data during the data transfer.

 · VeriSign dumps the registry data into text files and transfers them to Unity Registry.

 · The new registry database is now live and is an authoritative source for the generation of WHOIS and zone file information

Zone file creation from new registry

The new primary .ORG primary stealth nameserver is then loaded, and reloaded periodically as the live VeriSign primary .ORG nameserver is reloaded.

Primary Nameserver switchover

VeriSign and Unity Registry’s .ORG zone files should contain duplicate information. Checks will be made on two zones before the VeriSign.org name servers are switched to using the new .org primary stealth name server.

At this point org name resolutions are still being handled by VeriSign name servers but from a zone file originated in the new registry.

Registrar Transition to new registry

The new registry database is active.

 · A final email confirmation of switchover notification is sent to the registrars

 · VeriSign are instructed to stop accepting RRP requests for .dot org Simultaneously the new registry starts to accept online RRP requests.

This is the only stage in the entire process which must be time synchronised. Even here perfect synchronisation is not absolutely necessary as long as the VeriSign registry is shut down before new registry is enabled. This will guarantee that no registrar is interacting with a stale database.

 · Registrars now reconfigure their systems to the new registry

 · VeriSign can now remove the registry message bridge and org data from SRS.

Registrars will be actively supported during transfer to new registry.

Migration new Nameservers

Once the registry migration is complete, after a contingency period the migration of name servers will commence. At this stage the new registry primary stealth name server is transferring zone files to the VeriSign name servers.

The following steps will now be taken

 · Primary stealth server will now start transferring zone file to Nominum name servers, these will be synced to transfers to VeriSign servers

 · Extensive testing , including ICANN gTLD name server tests will be performed to ensure correct operation of the new servers

 · Over a period of 3 months the root server delegation, currently

 · org.      157431   IN   NS   A.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   G.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   H.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   C.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   I.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   B.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   D.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   L.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   F.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   J.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   K.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   E.GTLD-SERVERS.NET.

 · org.      157431   IN   NS   M.GTLD-SERVERS.NET.

will be replaced with the Nominum servers

ns1.unityregistry.org

ns2.unityregistry.org

etc

 ·  When the final VeriSign name server has been removed, zone replications to VeriSign will be terminated

Conversion of “thick” registrar data

Registrant details, domain details and domain/hostname “registry keys” are available from registrars. Each registrar will have this information stored in their own proprietary systems. Registrant details comprise name, address and contact details. Domain details comprise technical, administrative and billing contacts.

It is expected that registrars are able to dump their current data into delimited text files for easy importing into our database. Assistance will be provided if necessary. Seamless upgrade plans for registrar data migration, similar to the VeriSign-Unity Registry registry data migration plan, will be drafted for each registrar.

Registrars will initially use RRP to communicate with the new registry, operating in “thin mode”, and migrate to EPP-based communication. AusRegistry’s well-established and tested C++, Java and Perl toolkits, and well as a registrar-side XMLRPC-to-EPP gateway and registry-side EPP test servers should make the transition to EPP as painless as possible. Technical support will be available from the AusRegistry development team.

With multiple registrars converting from RRP to EPP in parallel, Unity Registry estimates the maximum time for registrar conversion would be one week. Also, Unity Registry estimates that all registrars will be converted to EPP in 18 months, during which time Unity Registry will run both RRP and EPP.

The process for each registrar can be summarised as:

 · Ask for test data dump from Registrar

 · Develop dump script, verifications scripts etc

 · When confident of conversion process, convert registrar over to "thick" EPP for all new registrations, and updates (no RRP to be used any more)

 · Once registrar is running comfortably in EPP request full data dump

 · Import data "updating" objects in the database with their relevant details.
During this time, for any discrepancies in the name server data between registrar and registry, the registry will be assumed the authorities. Any discrepancies will be logged and investigated

 · Verification of data is preformed, and the process is completed.

Broad community backward compatibility

There are several activities which would fall outside a strict definition of a registry migration plan. However our experience of creating a new gTLD have heightened our awareness of this. Examples of these are listed below

 · We will arrange for all common domain name related sites to migrate to the new WHOIS servers WHOIS.unityregistry.org at the time of transition

 · We will request VeriSign to delegate WHOIS queries to WHOIS.unityregistry.org for a period of time while systems are realigned.