Unity Registry Logo               Time to re-organise
The Proposal

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

AusRegistry has recently become the registry for com.au, net.au, org.au, id.au, asn.au, edu.au and gov.au second level ccTLDs. They have successfully imported data from the four previous registries in a variety of text formats.

The most difficult element with which to work with was the AUNIC data, consisting of inconsistently formatted text contained within 270,000 individual files for each domain, along with the associated contact data from in excess of 400,000 loosely formatted data files. In order to deal with this large volume of complex data, AusRegistry developed a number of pre-processing utilities in a variety of languages to build a consistent data set in a format suitable for data load. The data supplied from the other three registries was in a text delimited format .

The next step in the data load was to use Oracle tools to import these delimited data file into temporary tables within the database, then a suite of plsql tools were developed to convert this data into the usable registry format through a system of multiple passes.

Finally a multitude of data consistency and verifications tools were developed to check the consistency of the data, verify that no orphaned objects were created and that each object had associated with it the valid number of children objects.

Validation was performed between what was initially supplied to us and the data that ended up in the database. This was done by comparing the new WHOIS output to that of the existing registries, comparing supplied zone files with those generated by the database, and through field consistency checking, mapping new data fields to old data fields.

Registrars were then able to access this information in a “read only” format to be given a chance to perform their own validation of the data and provide any feedback to AusRegistry as required. Redundant historical data, i.e. unallocated contacts were purged from the database to ensure that the integrity of the data load was maintained. Any invalid, or non-compliant (policy) domain information was noted and the existing registry’s were given a chance to rectify the invalid data.

Some important mandatory information such as Email addresses of registrants was not available in the source data for all domains. These domains were allowed to violate internal database validation checks, and will be forced to have the missing information specified when next updated.

AusRegistry had the advantage of being able to negotiate a weekend outage in order to perform this change over. Even so, we are in the unique category of having experience and skill in a live data conversion to be able to perform an incremental conversion as purposed in this transition plan. Our experience has shown us that the major obstacles in performing a transition such as this is involved in getting the existing Registries to supply the information on time and in a usable, consistent format: we spent significant fraction of the conversion time, identifying “bugs” in the extracted data.

We also found that a lot of the information was previously kept in legacy systems that were poorly supported or out of date.

We have also learnt that mutual co-operation between the old and new registries is an essential element to a successful data conversion. This has demonstrated the importance of building a strong relationship between not only the management staff, but the technical staff. We have also learnt the importance of building a strong relationship with registrars through our:

Ø Helpdesk

Ø Technical Staff

Ø Database Administrators

Ø Project Managers

It is essential that people involved at each level are able to communicate efficiently and easily with people of the same level on the other side.

We have experience in assisting registrars to migrate from the multiple existing legacy registration system to the new consolidated EPP Registry we have provided. This has demonstrated to us the importance of running an efficient helpdesk with clearly documented escalation procedures. Access to a knowledge base, containing a large volume of registry specific data, and the importance of educating the staff and providing resource to allow them to efficient deal with registrar requests and not having to rely on only a few “knowledgeable people”.