C18.5. The specifics of cooperation required from VeriSign, Inc

As described in the introduction to this section we believe that it is vital to the success of the transition that VeriSign play an active and fully co-operative role in the migration of the org domain.

Unity Registry has created a Registry Advisory Committee (RAC) and we expect VeriSign to provide a member of their staff (with the appropriate level of expertise and authority within VeriSign) to sit on that committee (part time) for the duration of the transition.

The VeriSign RAC member would act as a single point of contact within VeriSign for the purpose of the transition and would be responsible and accountable for the successful and timely completion of tasks assigned to VeriSign.

That person should take a proactive role in the transition and advise (under NDA) of any material changes in the operation of the current registry which may impact on its smooth migration.

There are many technical tasks (many small, some larger) that VeriSign must perform as part of the transition. The key areas are listed below.

The timescale for this project is well known and therefore VeriSign have enough time to assure that the appropriate staff will be available, such that the project can be adequately staffed at the appropriate time

The transition plan is not rocket science, however it must work smoothly and without defect, to help ensure this, VeriSign will apply the quality standards and practices to this project as they do to other registry critical projects.

There are several tasks that we will repeat several times in a test environment, until the process is efficient, reliable and flawless. VeriSign must commit to supporting this iterative process until zero defects have been achieved. This would include data migration and zone file propagation

In order to investigate possible migration issues for registrars and other related matters it will be necessary to have access to the VeriSign test systems to conduct joint tests.

It may become apparent during these tests that registrars will face difficulties in easily and effectively separating RRP / EPP messages for dot org from those for com/net, as this has not been a requirement before and all new gTLDs are EPP based.

In this case VeriSign will work closely with Unity registry to create and implement any facilities that would minimise this problem.

From published material on SRS release schedules, it is apparent that VeriSign are possibly preparing to start migration to EPP before the migration of org has commenced. If this is the case VeriSign will fully share it’s plans for this Migration with Unity Registry. If commercially reasonable, VeriSign will either delay to escalate this migration to avoid the need to migrate a hybrid system, with the additional complexity and risk that would entail.

Since RRP is specific and restricted to the COM/NET/ORG domain space VeriSign will supply what system design material they may have for the protocol implementation.

In order to ensure a seamless migration, it is essential that the new registry operates in an identical way. To ensure this VeriSign will provide all operational parameters for the registry, e.g. grace periods

While much information about the org domain was supplied under NDA as part of the tender process, addition information will be required to allow further capacity planning to be complete.

VeriSign will need to cooperate in establishing a robust messaging channel with the new registry. It will also need to keep its WHOIS servers operating as long as necessary to serve the interested public and thereafter to cooperate to redirect messages to the Unity Registry WHOIS servers.

Minimum required VeriSign data

It is expected that VeriSign can produce the following delimited text files of registry data, for easy importing into our system:

Registrar details

Registrar Name | Password | Public key | etc… (unique records)

Nameserver details

Nameserver |IP Address (one to many)

Domain details

Domain | Nameserver (one to many)

End of section