The transition of the .org Registry function from VeriSign, Inc. (“VeriSign”) to The Global Name Registry, Limited (“GNR”) (the “Transition”) does not only involve moving the authoritative database from VeriSign to GNR, but also involves transitioning all user APIs towards the Registry, including Registrars, services and websites accessing any of the .org services, including SRS, Whois, OT&E, DNS, billing, www, zone file access, etc.

In fact, the .org Registry has a multitude of facets and interfaces toward the exterior, and this compounds the Transition challenge (the “Transition Challenge”). Some of the interfaces to the .org Registry are shown in the following figure to illustrate the depth of the Transition Challenge:

Figure 1: Overview of the Transition Challenge

In analyzing the Transition Challenge, GNR has considered all of the interfaces above, all of which must be migrated to GNR before the Transition is complete. The following discussions and descriptions focus on how to make this Transition complete in a stable, efficient and responsible manner.

Discussion on transitioning the Multiple Registry interfaces

Some of the interfaces shown in the figure above are not of a real-time critical nature, some are manual interfaces (like Policy), while others are unique one-way interfaces (like Escrow). These differences also mark a difference in how the transitioning is handled. Certain of these interfaces can be migrated without high risk, and the following discussion is about these.

The policy interface transition (DNSO participation, compliance with the ICANN Agreement, ICANN reports, UDRP arbitration interface) will continue be handled by the GNR policy team, which oversees all of these issues with respect to .name. The policy team will likely be enlarged upon GNR’s selection to operate .org. GNR already has extensive experience in this areas as a result of setting up, building, launching and operating .name. The GNR policy team participates actively in the DNSO (including on task forces, working groups, and recently on the ICANN restructuring), the Registry Constituency and other community forums. Additional people to be added to the GNR policy team would ensure that .org is properly served in this area. Also, the community input as described in other parts of this .org application ensures that GNR can properly handle feedback and responsibilities in this area. Therefore, GNR believes that it will be capable of transitioning this interface in a stable, responsible and efficient manner.

The Escrow interface is used mostly one-way, by moving data to a dedicated Escrow agent, which can be retrieved by ICANN alone. GNR’s dedicated Escrow agent will take over the Escrow interface, and ICANN will have another location to retrieve the Escrow data, but according to similar or identical procedures and principles. GNR currently creates Escrow files which are brought off-site by IronMountain. GNR believes that it will be capable of transitioning this interface in a stable, responsible and efficient manner.

Customer Services and Billing (the process where Registrars transfer money to the Registry and retrieve reports) can be handled by the GNR Customer Services Teams and Account Management Teams, for which GNR will add additional resources upon its selection to operate .org. Crucial in this process is communication with Registrars that account numbers and Helpdesk numbers will change, to instigate this change into their manual and semi-automatic processes. Retrieval of billing reports, which previously have been automated by the Registrar, is a function that will be taken over by GNR after the Transition. GNR will make such reports available in the same fashion as done by VeriSign; however, formats may change. Registrars will be assisted in this part of the transition by the Customer Support and Account Management teams. Therefore, GNR believes that it will be capable of transitioning this interface in a stable, responsible and efficient manner.

The Zone File Access FTP service will be assumed by GNR after the Transition. Due to the format of the contracts used to give third parties access to the zone file via a FTP server, the third parties which currently have contracts with VeriSign for .org zone file access will be required to re-enter into a virtually identical contract with GNR (e.g. governing law may change). To the extent that such third parties use the zone file in automated processes, such processes/APIs will have to be re-pointed to the GNR FTP zone file access server(s). However, this change of IP number will be made clear and apparent in the GNR zone file access agreement, and given the non-real time nature of the zone file (only updated every 12 hours), third parties will have sufficient time to change their APIs to point to GNR FTP server(s). Therefore, GNR believes that it will be capable of transitioning this interface in a stable, responsible and efficient manner.

The Registrar Accreditation and OT&E environment will be assumed by GNR after the Transition. All ICANN-Accredited Registrars currently approved to do registrations in the .org top-level domain will be required to become accredited with GNR and execute the appropriate contracts (Similar to Appendix F to the .name contract). Accreditation is a largely manual process, and by virtue of its operation of .name, GNR possesses extensive experience .name with accrediting Registrars. In fact, GNR has undergone two accreditation processes: first, GNR accredited Registrars to execute Landrush registrations on .name, and then subsequently, accredited Registrars to execute the more complex live registrations on .name. Therefore, there will be a natural migration of the accreditation environment from VeriSign to GNR as Registrars re-accredit for .org. The GNR Customer Service and Account management teams would ensure that this migration goes smoothly and that Registrars are smoothly re-approved for operations in the .org top-level domain after the Transition. The OT&E environment is a similar transitional challenge; however, this environment is continuously available to all ICANN Accredited Registrars to test and phase in their systems and APIs for use on the Production System (the real SRS). Again, this would be handled by the GNR Customer Service and Account Management teams, with significant experience from .name. The OT&E environment will be available to all Registrars 60 days prior to the Transition from VeriSign to GNR is effected. Registrars will switch over to this environment when they are ready and in a natural, non-time critical manner. Therefore, GNR believes that it will be capable of transitioning this interface in a stable, responsible and efficient manner.

Given the above, GNR has focused the chapters C18.1-7 on transitioning the Shared Registry System (SRS) (including the authoritative database for .org), Whois and RRP interfaces to the Registry and finally, but perhaps most importantly, the DNS. These transition challenges will be analyzed and described in the following.

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

In the following chapters C18.1-7, GNR analyzes the Transition of (1) the database of .org registrations and the history of operations in the database (hereafter called the “SRS database”); and (2) the RRP interface that the Registrars use currently; and (3) the Whois interface on Port 43 of VeriSign Whois servers.

Transitioning DNS

The DNS is deliberately made to be redundant and support changing servers and network downtime. This helps to ensure that the DNS will be 100% operative during the transition.

The current DNS servers operated for .org by VRSN are the following:

;; ANSWERS:

org. 86400 SOA A.GTLD-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. (

2002060901 serial

1800 refresh (30 mins)

900 retry (15 mins)

604800 expire (7 days)

86400 ) minimum (1 day)

;; AUTHORITY RECORDS:

org. 518400 NS A.GTLD-SERVERS.NET.

org. 518400 NS G.GTLD-SERVERS.NET.

org. 518400 NS H.GTLD-SERVERS.NET.

org. 518400 NS C.GTLD-SERVERS.NET.

org. 518400 NS I.GTLD-SERVERS.NET.

org. 518400 NS B.GTLD-SERVERS.NET.

org. 518400 NS D.GTLD-SERVERS.NET.

org. 518400 NS L.GTLD-SERVERS.NET.

org. 518400 NS F.GTLD-SERVERS.NET.

org. 518400 NS J.GTLD-SERVERS.NET.

org. 518400 NS K.GTLD-SERVERS.NET.

org. 518400 NS E.GTLD-SERVERS.NET.

org. 518400 NS M.GTLD-SERVERS.NET.

Since these 13 nameservers are updated by VeriSign from their authoritative database according to VeriSign’s update procedures, they would cease to be authoritative for the .org zone one the authoritative database is Transitioned.

The DNS migration from VeriSign to GNR would be performed by IANA/ICANN, by re-pointing the root servers to the set of nameservers provided by GNR for .org. These nameservers would all be in-zone name servers, or a mix of in-zone nameservers and out of zone nameservers.

GNR would propose to do the DNS transition in the following steps:

Transition Step	Status after step made
1. GNR receives a full zone file from VeriSign (as a process where zone files are received every time VeriSign updates their zone files)	All DNS servers (currently 13) operated by VeriSign.
2. GNR loads the zone file on one DNS site (“ns1”) (a DNS cluster with one exposed IP)	All DNS servers (currently 13) operated by VeriSign. GNR has one DNS site with a zonefile identical to VeriSigns zonefile
3. ICANN changes the root servers to replace one VeriSign DNS server with GNR’s ns1.	Root contains 12 of VeriSign’s DNS servers, and one of GNR’s nameservers (ns1)
4. GNR, VeriSign and ICANN evaluates performance, stability and operations of the DNS	Root contains 12 of VeriSign’s DNS servers, and one of GNR’s nameservers (ns1)
5. GNR repeats step 2, with another DNS cluster with one exposed IP (“ns2”)	Root contains 12 of VeriSign’s DNS servers, and one of GNR’s nameservers (ns1) GNR has two DNS sites with a zonefile identical to VeriSigns zonefile
6. GNR, ICANN and VeriSign repeat steps 3 and 4	Root contains 11 of VeriSign’s DNS servers, and two of GNR’s nameservers (ns1 and ns2)
7. Once three of GNR DNS sites are listed in the root servers, the Transition of the authorative database from VeriSign to GNR will be completed.	Root contains several of VeriSign’s DNS servers, and three of GNR’s DNS sites (ns1. ns2, ns3) GNR holds the authorative database for .org
8. GNR starts the process of transferring zone files to VeriSign on regular intervals, which can be installed on the remaining DNS servers in the .org zone operated by VeriSign	GNR is authorative for the .org zone, but regularly (every 12 hours) sends updates to VeriSign to update the DNS servers still in operation by VeriSign
9. GNR activates a total of 8 to 10 DNS sites for .org (depending on analysis of need)
10. Steps 3 and 4 are repeated until VeriSign no longer has any DNS servers in the .org zone	Root zone migrates from having some VeriSign DNS servers to having none. VeriSign is completely merged out of the .org DNS operations.
11. After all VeriSign DNS servers are phased out, GNR recommends waiting one to two months prior to taking them out of service for .org, to ensure that “buggy” resolvers will have time to transition to the GNR DNS

When ICANN changes the root zone servers, GNR would be in constant contact with ICANN to know at which time exactly the DNS record change is committed, and when it propagates. The GNR operations team would follow the traffic patterns from the root servers on a second by second basis to ensure that all go forward according to plan.

The soft and gradual transfer of the DNS by pointing more and more of the root zone servers over from VeriSign to GNR ensures that the DNS operations stay stable and consistent during the entire transition, with no “Sudden Death” situations.

Accepting and installing zone files from VeriSign to the GNR DNS clusters is an easy operation. VeriSign is today, in the operations of .name, accepting zone files from GNR to install on their DNS servers and this is a process that both GNR and VeriSign’s teams have great experience with and has done extensively already.

When GNR is authoritative for the .org zone, it would not immediately go to near-real-time updates of the DNS. While VeriSign DNS servers are in operation, GNR would only do updates every 12 hours, to make sure that all DNS servers use the same update methods and therefore keep as consistent in time as possible. When all VeriSign DNS servers are phased out, GNR would start updating the .org zone according to its near real-time process. During this regular update period, GNR would also take additional time to verify the zone files prior to publishing.

Once GNR goes to be authoritative for the zone, GNR would consider asking VeriSign to set the TTL (time to live) parameter on their DNS servers to lower than the current setting. This would ensure that the Internet community, ISPs and others using the VeriSign DNS servers would do quicker updates and more in line with the GNR near-real time updates.

Transitioning WHois

The Whois service operated by VeriSign for .org is used extensively by numerous websites around the world. Some uses of the Whois includes, but is far from limited to:

1. Checking availability of domain names, i.e. in relation to sale of domain names

2. Analyzing ownership of domain names, i.e. for pursuit of intellectual property purposes

3. Analyzing trends and segments of the domain name population, i.e. to create analysis and reports on the domain space growth and usage

4. Matching Whois data with other publicly available databases, i.e. for criminal investigation

Any service using fwhois or similar, connecting to a Whois service operated by VeriSign for .org, will work towards a specific domain name owned by VeriSign (e.g. whois.crsnic.net). Since this address is also used for .com and .net, it cannot be extracted for .org only. Therefore, when GNR commences Whois operations on port 43 of e.g. whois.orgwhois.org, clients like fwhois around the world, in hundreds of thousands, or even millions of clients will continue to point to whois.crsnic.net until changed.

The figure below illustrates the situation today:

Figure 2: whois clients connecting to VeriSign today

That change will take some time.

To remedy this situation of sudden death or inconsistency of whois clients, GNR would propose to use any commercially reasonable efforts to work with VeriSign to implement on their whois servers a server-extension that would filter out queries to .org, and fetch the data for all .org queries from GNR servers. Depending on the chosen implementation, this server-extension would either work closely with the existing Whois server; or be an upgrade of the existing Whois server application on the VeriSign Whois servers, to make sure that Whois queries to whois.crsnic.net and similar current .org whois sources would return the correct data even though the data would be fetched from GNR servers.

GNR would additionally use commercially reasonable efforts to investigate with VeriSign whether it would be acceptable for VeriSign to have GNR place Whois Servers in the close proximity of their Whois servers, to make it easier for the whois server-extension to get the data more rapidly. GNR would then update the Whois servers on VeriSign premises like any other Whois servers.

Keeping the whois.crsnic.net interface alive for .org responses would necessarily have to be for a limited period of time (for the Transition to have any meaning), but it would ensure that web owners and Internet users would not suffer a “sudden death” situation when the .org Registry is transitioned. The period of time needed for a responsible move and shutdown of .org reponses from whois.crsnic.net should in GNR’s opinion be at least 6 months, to allow clients to update. The end of the period should be marked with outreach to web owners and perhaps more intrusive methods, like slowing down queries for .org on whois.crsnic.net compared to the GNR controlled interface (e.g. orgwhois.org).

The figure below illustrates how clients would continue to connect to VeriSign locations, with the option of connecting directly to GNR, and how the data would be returned correctly from the VeriSign location either by fetching it from GNR main site(s) or from a replicated dataset that GNR would put and host on the VeriSign location:

Figure 3: Forwarding Whois requests to VeriSign during a transitionary period

This effort is important, GNR believes, to minimize the impact on Internet users due to the Transition of the Whois interface, but will require efforts both from VeriSign and GNR.

Transitioning RRP interface

Transitioning the RRP interface is an important task; in fact, GNR believes that this is the most major task of the entire Transition. There are more than 100 accredited, active Registrars that have some form of RRP interface to the .org Registry.

On the Registry side, GNR will set up RRP servers on one or several exposed IP addresses, which effectively allows Registrars to connect to the SRS. These RRP servers will be active from the moment the SRS is restarted on the GNR side.

However, updating the client side to accommodate the change is the real challenge. Registrars are using various clients to connect to the Registry, some custom-made, some are off-the-shelf solutions, and all of these clients must be updated to reflect that connection now will be made to a GNR domain name and IP, not VeriSign. In some cases, it may be easy for the Registrar to separate the .org interface from the .com/.net interface, in other cases, it may be comprehensive and involve changing complex middleware and business logic.

In the consideration of how to move the server side of the RRP interface, GNR has evaluated the time-dimension of the Transition, and has considered the following options for the RRP transition:

a. “Sudden Death”: At one point in time, most likely coinciding with the time at which the SRS is shut down, VeriSign would shut down its RRP servers. Shortly afterwards, most likely coinciding with the time at which GNR opens its SRS, GNR would open its RRP servers and allow Registrar to resume operations as normal. This is a Sudden Death situation because Registrars would have to transition at one point in time.

b. “Slow Death”: In this scenario, VeriSign would shut down the SRS, but not the RRP servers. Instead, the RRP servers would be set to use standard port-forwarding from VeriSign RRP to GNR. This would forward incoming requests to the VeriSign RRP servers to GNR, GNR would answer them and forward the answer through the VeriSign RRP servers. This would continue for a period of time until Registrars could be assumed to have changed their clients, after which the VeriSign RRP servers would be shut down.

c. “Never Die”: This scenario would involve to keep the port forwarding from VeriSign for ever. In theory, it could mean that Registrars would never have to change their clients to point to GNR.

The advantages and disadvantages with each method is discussed below.

Port Forwarding (“Slow Death” and “Never Die”)

Advantages

1. Would make the transition easier by allowing clients to connect to the same IP as before, which would enable Registrars to move their clients when they feel ready, rather than when they “have to.”

Disadvantages

1. It would require VeriSign to implement port forwarding on their RRP servers.

2. Registrars using certificate based SSL connection will see this certification break down for port forwarding. Some registrars are using certificate validation to check that they have connected to the right system (not only using the IP for validation).

3. Unless GNR uses the same usernames and passwords to connect each Registrar to the SRS, Registrar client may submit VeriSign password, which will not be valid in GNR SRS.

4. When receiving port forwarded requests, GNR would only have in the log the incoming IP address (which would be VeriSign’s IP). Therefore, VeriSign would have to maintain a list of valid originating IP addresses. This list may change from time to time based on accreditation and Registrar systems. This represents an additional effort for VeriSign.

Sudden Death

Advantages

1. Represents a “clean break,” and while efforts may be required on all sides at the moment of migration, it carries with it few legacy problems that the port forwarding method has.

Disadvantages

1. Clients must be changed at a specified point in time or a parallel client must become active at a specified point in time.

One fact is also important in the evaluation of the methods. Before a Registrar can connect to the GNR RRP servers, the Registrar must have been accredited by GNR. The accreditation process of an ICANN Accredited Registrar involves signing a Registry-Registrar agreement, going through the technical accreditation, transferring funds, etc. Therefore, the Registrar must have had clients connecting to the GNR system during the accreditation process and OT&E. This makes the port forwarding argument more diluted.

Additionally, even port forwarding might require some change on the client side, e.g. passwords and SSL certificates, and with the other disadvantages, this method does not seem to add any value to the transition and ease the challenge.

GNR therefore prefers the Sudden Death method and would minimize any problems for the Registrars by specifically requesting and assisting during the accreditation process that clients are re-pointed to the GNR IP and new passwords, usernames and SSL certificates are issued and used by client and server.

However, the port forwarding method may be further discussed with Registrars, VeriSign and ICANN as a possible crisis solution, should there be identified and demonstrable needs for it.

Transitioning the .org authorative database

In transitioning the .org database, GNR aims to fulfill the following criteria:

1. Minimize downtime of the SRS

2. Retain 100% consistency by rigorous quality control

3. Minimize dependency of VeriSign and effort needed from VeriSign (especially as relates to use of VeriSign intellectual property)

The main parameter in discussing how the database transition is made is the data container format. The following options on the database container have been considered by GNR and will be discussed:

1. Database dump

2. Export of database

3. Custom Export of database

4. Use of Escrow data format

1. Database dump

a. Advantages

i. Can be installed directly on GNR systems

ii. Will ensure an exact replica of the database

iii. Uses an internal Oracle function (Exp) to put database in binary format. This function includes a validator

iv. Includes object history and audit trail (which is used by Registrars and CSR teams)

b. Disadvantages

i. Requires very similar or identical versions of database, also for hardware (e.g. 32 or 64 bit mode (which oracle can run under AIX). 32 bit and 64 bit dumps are not compatible

ii. The dump could include VeriSign intellectual property that VeriSign does not want to share even under NDA, since more structural information is included in the dump

iii. Large size, even when compressed

2. Export

a. Advantages

i. Uses built-in functions to export database

b. Disadvantages

i. Requires knowledge about database schemas

ii. Does not provide more value than a Custom Text Export

3. Custom text export

a. Advantages

i. No need to understand the VeriSign database structure (which may be extremely complex)

ii. It does not contain any VeriSign IP, e.g. VeriSign does not have to give up information on their database schemas

iii. GNR could specify the custom dump format (or in cooperation with VeriSign) to fit own systems

iv. Object history could be included in this custom text export.

v. Can use unique identifiers to identify each data object, all information about object at one point in time

vi. Relatively small data size

vii. Does not include indexes and other large, redundant information structures

Disadvantages

viii. Custom scripts must run on VeriSign servers to make the Custom Export

4. Escrow file

a. Advantages

i. Does not contain VeriSign Intellectual Property

ii. GNR has strong competence on re-generating Registry, Whois, DNS from Escrow files (extensively used for .name)

b. Disadvantages

i. Does not contain object history

ii. Does not contain authentication information

iii. Escrow is useful for disaster reconstruction but not when the original structure is not known in detail

iv. No one has so far recreated a Registry from Escrow

v. More complex migration process because the Escrow format is an incomplete version of the .org Registry

There are advantages with either method, however, GNR would prefer a Custom Text Export as the data container for the Registry data. The data could be exported to a format that would fit the GNR data model, and the export would easily compress to a relatively small size (few gigabytes) since the content would be text and would not include any database index, which is redundant and can be recreated once data is imported into the GNR databases. The Custom Text Export can easily include object history which would remove any need for additional data containers for the history of objects.

Finally, the Custom Text Export does not include any VeriSign intellectual property and should therefore be easier to use also for VeriSign.

GNR would therefore prefer as the if the data transfer container for the Transition were a Custom Text Export, and will base the main argumentation going forward on this assumption. However, GNR is confident that the Transition could also be made using other data containers, including a Database Dump or a Database Export. The Escrow file format is not highly attractive as a source to rebuild the Registry and would only be used in emergency situations.

Steps of the Transition

The Transition steps would be the following steps:

1. Define custom export format

2. "Dress rehearsal" export + Zone file

3. "Dress rehearsal" import

4. "Dress rehearsal" validation

5. Actual export (may be incremental based on "dress rehearsal")

6. Actual import

7. Validation

8. Stop SRS

9. Incremental export

10.Incremental import

11.Validation

12.Start SRS

Each step will be explained in more detail in the following:

Step 1. Define custom export format

The custom export format will be based on clear text data to minimize any problems due to incompatible hardware or software during transport from VeriSign to GNR. The format of the export file(s) will be defined in cooperation between VeriSign and GNR. The files will not include any indexes or data beyond what is needed for registry operation, and are thus very compact. The export should include full object history for the domains, but with the possibility for start and end dates for the export. The use of these parameters will be explained later. The latest entry for the domain will be considered "current."

The files will be encrypted and compressed using GPG before they are transferred on the Internet. GNR will provide the GPG public key needed for encryption.

Example: Data to be exported, size and time estimates:

Domains: [2,500,000] * [128 bytes] * [~20 versions]

Domain ID 4 bytes

       Transaction ID         16 bytes
       Domain Name           2 - 63 (~12) bytes
       Sponsoring Registrar 1 byte
       Creation date          12 bytes

Expiry date 12 bytes

       Modification date     12 bytes
       Transfer date          12 bytes
       Status                     8 bytes

Field separators 10 bytes
[…]

Nameservers: [1,500,000] * [90 bytes] * [~5 versions]

Name Server ID 4 bytes

Name Server Name 9 – 80 (~20) bytes
IP-addresses 15 bytes * 0 – 13 (~2)

       Sponsoring Registrar 1 byte
       Modification date     12 bytes
       Status                     8 bytes

Field separators 10 bytes
[…]

Domain-Name Server lookups: [5,500,000] * [8 bytes]

       Domain ID                4 bytes
       Name Server ID         4 bytes
       […]

Estimated file size of full export: [7.5 GB], [1 GB] compressed

Estimated time to generate export: [4 hours]

Estimated time to encrypt/compress export: [30 minutes]

Estimated time to transfer export: [30 minutes]

Estimated time to decrypt/uncompress export: [20 minutes]

Estimated time to import: [7 hours]

VeriSign involvement: VeriSign must agree upon the export format with GNR. GNR can specify the desired details if needed.

Time estimate: 7 days, no SRS downtime

Step 2. "Dress rehearsal" export + Zone file

To validate the procedure and the programs used for the transferring the .org database, we suggest a "dress rehearsal.” Doing a full export import and validation would dramatically reduce the possibilities of problems or delays during the actual transfer of the data. This includes a full export of the .org namespace with a following import and validation of the data in the GNR transition environment.

We will first take a copy of the DNS zone file, with a specified "current as of" date. Then a full export of the data in the database with no start date, but the date of the zone file as end date is performed. The data file(s) will be encrypted and transferred as if it was the actual export, and every step will be timed to give an accurate time schedule for the actual transfer to be done at a later stage.

The times chosen for DNS zone file and end date do not have to match exactly (on an atomic level), as will be explained later.

The export files will be transferred to GNR over the Internet using FTP. Since all files are encrypted using GPG there are no risks involved in using an unencrypted transfer mechanism. Estimated transfer time of a 1GB export is less than 30 minutes using GNRs 200 Mbit/s Internet connection at medium load.

VeriSign involvement: VeriSign will perform the actual export, since this is done internally on VeriSign’s business critical servers. The export will be transferred to a secure idle server for encryption and transfer to GNR.

Time estimate: 1 day, no SRS downtime

Step 3. "Dress rehearsal" import

When the data file(s) arrive at GNR data center, they will be transferred to a secure transition environment. The data will then be decrypted and imported into the GNR table structure in Oracle 8i. Indexes will be created in the database after the import to speed the data transfer into the database.

VeriSign involvement: None

Time estimate: 1 day, no SRS downtime

Step 4. "Dress rehearsal" validation

After import, GNR will do a standard zone file generation out of the database. This file is then compared to the VerioSign zone file that was backed up as part of the "Dress rehearsal" procedure. Some discrepancies should be anticipated, but these should be few and possible to track down to modifications around the time of transfer using the VeriSign object history. A successful test would show that:

1. The data can be transferred using the method specified.

2. No data is lost or corrupted during transfer.

3. GNR zone file generation completed successfully.

4. The detailed time schedule of the actual transfer will be confirmed. The time schedule should allow room for any possible hurdles (e.g. retransmission of the export in case of data transfer problems) even though such problems did not arise during "Dress rehearsal".

VeriSign involvement: None

Time estimate: 1 day, no SRS downtime

Step 5. Actual export

This will be a carbon copy of the "Dress rehearsal" export. A zone file is backed up, followed by a clear text export of the database according to the date of the zone file. In addition a bulk whois file and a DNS zone file is created at the time of export. This will enable validation of the database following transfer to GNR.

Optional: If we want to further reduce the gap between export and final incremental update of the GNR table space (to reduce the amount of data transferred during SRS downtime), this export may be an incremental export based on the "Dress rehearsal" copy already made. Since most of the VeriSign data are already in the GNR system, this will reduce the amount of exported, encrypted and transferred data, as well as the amount needed for import into the GNR system.

However, we think that a full export at this stage will be no problem performance-wise, and that a complete set of data simplifies the validation efforts at this stage. The benefits of an incremental export would be to have tested this form of export/import with a live working environment before our final transition (including SRS downtime) in steps [8-12].

VeriSign involvement: As "Dress rehearsal" export

Time estimate: 1 day, no SRS downtime

Step 6. Actual import

Using the exact same utilities used to import during "Dress rehearsal", the actual export file is imported to the GNR .org database server.

VeriSign involvement: None

Time estimate: 1 day, no SRS downtime

Step 7. Validation

Validation of the imported data will be done using GNR zone file generation as well as a comparison of the database of current objects against the copy of the VeriSign whois database from the time of export. Any discrepancies should be checked, and verified to be due to changes in the database that were not yet part of VeriSign resolving services at the time of export.

VeriSign involvement: None

Time estimate: 1 day, no SRS downtime

Populating whois database: At this point we will also do the base population of the whois database. Since the Update Handler is streamlined to handle incremental updates, all changes and additions to the database imported during step 10 will be easily transferred to the whois system after GNR has received the full authorative database. This will enable a transition of whois services soon after transition of the SRS itself.

VeriSign involvement: None

Time estimate: 1 day, no SRS downtime

Step 8. Stop SRS

When we are comfortable with the bulk export of objects to the GNR database, we will decide a time for SRS transfer. Even though it is still not "the point of no return", this is the decisive step during VeriSign to GNR transition. This is a point where SRS downtime is inevitable, and all the proceeding steps are tuned towards this final step being as streamlined as possible. The VeriSign SRS will be shut down, and all transactions flushed in the database.

The time slot chosen for the downtime would be either Sunday January 12 or January 19 from 0000AM to 1200 AM EST.

Global Name Registry would prefer to the above days since people are available. Transferring on new year’s eve is likely to make it extremely difficult to make all the necessary people available considering the involvement from both ICANN, VeriSign and Global Name Registry.

VeriSign involvement: Stop the SRS service

Time estimate: Immediate, start of SRS downtime

Step 9. Incremental export

When all transactions are committed in the VRSN database, it is time for a final export. This will be all object additions and modifications done since the actual export earlier. To put in some margin of safety, we will also include all object modifications from the two days preceding the export. Since we always use the same code for all exports, the risks of anything unexpected happening at this stage in the process are minimal. The same goes for the import of the transferred data into the GNR table space.

VeriSign involvement: As "Dress rehearsal" export

Time estimate: 4 hours, SRS downtime

Step 10. Incremental import

Since all records are tagged with a transaction ID, we will disregard the records (duplicates) that are already in the GNR database.

VeriSign involvement: None

Time estimate: 4 hours, SRS downtime

Changes to database after import: After import all grace periods will be extended with 7 days to reflect the period of SRS downtime. In addition to giving the Registrars more time to connect and renew any domains up for deletion, it will also ensure that no domains expire during SRS downtime.

Statuses on the objects will be kept unchanged. Any Registry assigned status flags will need to be discussed with VeriSign after transfer, and resolved on a case by case basis.

Step 11. Validation

Since the VeriSign resolving services now will be completely up to date with the GNR database, the validation of the database will be much simpler than that during the preceding steps. Using GNR DNS zone file generation, a zone file containing the exact same data as the VeriSign zone file should be produced. All the data in the VeriSign whois database should also be present in the GNR database and vice versa. A successful transfer would consist of a database with no discrepancies compared to the working current resolving services.

VeriSign involvement: None

Time estimate: 4 hours, SRS downtime

Step 12. Start SRS

After successful validation of the GNR database, SRS services should be started at GNR, and the Registrars can all point their clients to the GNR ip-address. This would happen at a predefined time, and additionally, a notification would go out to all Registrars at the time of opening. Details of Registrar transition are explained in section C 18.1 (under “Transitioning RRP interface”)

VeriSign involvement: None

Time estimate: Immediate, end of SRS downtime

Other elements to consider before or during the transition

Operational Test & Evaluation (OT&E)

The GNR OT&E environment for RRP accreditation will be operational at least 60 days before .org transition. All registrars currently accredited for registration in the .org namespace will be invited to re-certify with GNR for uninterrupted service to their clients. GNR will allow Registrars to be sponsoring objects in the .org namespace past the transition from VeriSign, but no access to the SRS will be given until the Registrar is accredited.

The RRP accreditation procedure will prove the Registrars ability to:

· Connect to the GNR .org SRS using RRP

· Domain Name operations

o Create domain with maximum number of Name Servers

o Create domain without Name Servers

o Create domain with invalid name

o Create domain with maximum registration period

o Renew domain

o Renew domain past maximum registration period

o Delete domain with children Name Servers

o Delete domain without children Name Servers

o Check domain, domain available

o Check domain, domain not available

o Status of domain

o Add Name Server

o Delete Name Server

· Name Server operations

o Create in-zone Name Server with IP-addresses

o Create out-of-zone Name Server without IP-addresses

o Delete

o Check

o Change Name Server, add IP-address

o Change Name Server, remove IP-address

Internationalized Domain Names

Since the current registry operator has previously accommodated certain types of internationalized domain name (IDN) registrations in the .org TLD, Global Name Registry will grandfather in the existing registrations as made with a specific RACE encoding and keep these in the registry. However, depending on the standards emerging for IDNs, the existing IDN registrations maintained by the current registry operator may or may not be compatible with the new standards. Global Name Registry will work to ensure a smooth migration to any new standard.

All internationalized domain names existing in the .org name space will be transferred along with the other objects from the database. GNR will however not take any special steps to make them resolve in DNS or whois, although the objects will be visible as-is (RACE encoded UTF-8). No additional IDNs will be allowed registered, and no OT&E environment for IDN registration will be created until a standard concerning IDNs has been established.

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

As described above, there will be no interruption of the DNS resolution services and Whois services. The only service that will have any downtime is the Registrar access to the SRS.

There will be an interruption of the SRS services for the time it takes to re-populate and validate the database. The total SRS downtime is estimated to 12 hours, but GNR would in this exceptional case ask for a total downtime maintenance window of 24 hours to plan for contingencies.

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

Use of DNS zonefiles and Bulk Whois for validation and correction of SRS inconsistencies

To detect any case of mis-population or incomplete population of SRS, GNR will thoroughly validate that the database transfer is accomplished with no errors to the data. By validating the database against both the zonefile transferred from VeriSign and the full set of Whois data held by the Registry (“bulk whois”) from VeriSign, errors can be detected. Any discrepancies will be manually investigated and corrected prior to opening of the SRS.

Use of Global Name Registry consistency and validation mechanisms to correct Whois and DNS inconsistencies.

DNS and Whois services will be populated using GNR’s Update Handler subsystem. The Update Handler mechanism will be validated through extensive QA well ahead of the transition to GNR. The resolving services will also be constantly monitored by the GNR Quality Assurance and Consistency Validation (ACV) system which will quickly find any discrepancies, and issue update messages to fix the defects.

Root server changes and disaster roll back

When the root server zones are changed, it is extremely important that both Global Name Registry, ICANN and VeriSign are prepared for contingency events.

The following errors may occur when re-pointing the root zone:

· Pointing to Global Name Registry DNS sites that are not yet populated or active

· Pointing back to VeriSign servers that are no longer consistent or active

· Other errors on servers that start receiving traffic from the root

The most major contingency event in the case of problems surrounding a root server update would be a roll-back of the root to its previous state. Global Name Registry would establish a totally clear plan for how root server changes and “roll-backs” would be made. This would be an extremely detailed plan for how such changes should be made. The contingency procedure would include the following:

· Preparations of the root change requests must be done with both ICANN, VeriSign and IANA to establish which servers, which IP addresses, which people, and which time(s) will be involved in the change.

· Global Name Registry and VeriSign send root server change request to ICANN/IANA. This request must include timing for the change, complete and accurate details for the change, contact persons both in GNR and VeriSign teams at any time until and after root server change is made, etc.

· ICANN/IANA would process the request, which would go to VeriSign, which physically controls the change of the root server.

· Before, during and after the exact time for the root server change, GNR teams and VeriSign operation teams would be monitoring the traffic to the root servers, the servers that were put into operation and the servers that went out of operation.

· If a catastrophic error is discovered, particularly on the servers that have gone into operation, the teams both in GNR, VeriSign and ICANN need to make a real-time decision on whether to roll back to the previous root server state. If yes, IANA/ICANN should already have approved roll back under catastrophic circumstances, and VeriSign would make the change back to the state it previously was, as soon as possible, before more resolving clients started caching the new servers and increasing the traffic.

While this scenario is extremely unrealistic, DNS is the most important service in operation for .org, and must never be down.

Problems in the OT&E environment for .org

The OT&E environment offered by Global Name Registry may not be identical to VeriSign’s OT&E, and small changes may lead to confusion among Registrars.

To minimize this risk, the OT&E environment will be made available to the Registrars 60 days prior to SRS transfer. This will give some headroom for adjusting Registrar clients and Global Name Registry SRS interfaces as appropriate.