Sections C18 and C22

 

 

Table of contents. 2

Table of Figures. 4

C18. Transition Plan.5

Defining the Transition challenge. 5

Discussion on transitioning the Multiple Registry interfaces6

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

Transitioning DNS8

Transitioning WHois10

Transitioning RRP interface. 12

Transitioning the .org authorative database. 14

Steps of the Transition. 16

Other elements to consider before or during the transition. 22

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

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

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

Effect on .org registrants25

Effect on Internet users seeking to resolve .org domain names26

Effect on Registrars26

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

Servers and software. 26

Data and data access27

Personnel  and Planning. 27

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

Global Name Registry is perhaps the only Registry in the world (aside from VeriSign) with relevant experience. 27

Major Registry Transition Performed by Global Name Registry in May 2002. 28

Registry Launch of .name and 100% Uptime. 29

Operations of Large-Scale Email Solution – Nameplanet.com. 29

Product Development30

Demonstrated Best-of-Breed Technical Results30

Relationships with ICANN-Accredited Registrars31

Demonstrated Experience to Work within ICANN Guidelines31

C18.7. Any proposed criteria for the evaluation of the success of the transition  31

C22. RRP to EPP migration. 33

Introduction to the Transition from RRP to EPP. 33

The protocol specific layer - Differentiating between RRP and EPP commands and functionality34

The Protocol independent layer35

Mapping RULES35

Protocol specific rules36

Command mapping RRP ® EPP. 36

Object status mapping RRP/EPP ® internal API39

Resultcode mapping EPP ® RRP. 40

Conclusion. 44

 

Figure 1: Overview of the Transition Challenge  5

Figure 2: whois clients connecting to VeriSign today11

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

Figure 4: Illustration of layered architecture from EPP/RRP to database  34

Figure 5: Timeline for protocol transition and thin/thick transition  43

 

Defining the Transition challenge

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.

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

 

Effect on .org registrants

·         The .org Registrants will not be able to do modifications of their registered names in the period that the SRS is down. However, the effect of this should be minimal due to short timeframe and a chosen time that will be during the night when Internet traffic is generally low. This will be a planned outage and will be announced to all Registrars in good time prior to the Transition.

·         No names will expire during the downtime, therefore Registrants whose name originally expired in this timeslot will not be at risk.

·         .org registered names will after the Transition have a lower renewal price due to the proposed price reductions.

·         .org Registrants will enjoy quicker updates of Whois and DNS once GNR takes over the .org TLD.

 

 

Effect on Internet users seeking to resolve .org domain names

·         There will be no effect on Internet users seeking to resolve .org domain names.

·         DNS will be active and consistent at all times during the transition.

·         Some disruptions to Whois services all over the world may happen since web site owners will have to repoint their scripts to the new whois services offered by Global Name Registry. Even though the exact same query method will be offered, it may be a matter

·         So it is a matter of changing URL from [whois.internic.com] to [whois.gnr.com].

Effect on Registrars

Additionally, there will be an impact on Registrars before, during and after the Transition:

 

·         The Registrars must be re-accredited by Global Name Registry for operations on .org, which includes establishing an account with GNR and transferring of funds to GNR. However, many Registrars already have accounts with GNR and know the procedure for working with GNR.

·         Registrars must complete a new OT&E procedure for .org, although Registrars will find the operations familiar since GNR will offer to the extent possible the same functionality and syntax as VeriSign.

·         The online www tool used by Registrars for reporting will not be the exact same, except GNR will aim to minimize any differences, should this be desired by Registrars.

·         Registrar’s Whois clients will have to change if they are using the Whois interface and not the RRP interface to query domains for status.

 

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

The cooperation needed from VeriSign is specified in each of the steps above. 

 

Servers and software

·         Whois servers – As described in the chapter above, GNR proposes to find a solution where VeriSign Whois servers would run modified software to fetch Whois data from the GNR system, to ensure minimal disruption on services using Whois worldwide.

·         DNS servers – As described in the DNS section above, VeriSign would be asked to run DNS servers for the .org zone for at least one to two months after the transition is complete, to ensure that as many resolving clients as possible have a chance to update.

·         RRP servers – As described above in the chapter on Transitioning RRP, as a possible option, forwarding RRP requests from VeriSign to GNR during a period would require VeriSign to change software on their RRP frontends.

Data and data access

·         Whois data – As described above in more detail, GNR would like to have whois data from VeriSign created simultaneously as the database exports, for validation and verification purposes.

·         DNS zonefile – As described above in more detail, GNR would like to have DNS zonefiles from VeriSign created simultaneously as the database exports, for validation and verification purposes.

Personnel  and Planning

·         Cooperation during SRS transfers – As described above in more detail, VeriSign’s cooperation is required during the SRS transfer to ensure a stable and efficient transition.  This will involve VeriSign personnel and a tight cooperation between GNR and VeriSign teams.

·         Cooperation on roll back of root servers – As described above in more detail, any changes to the root servers should be preceded by, and followed by, a period of tight cooperation and planning between both GNR, VeriSign and ICANN teams.

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

Global Name Registry is perhaps the only Registry in the world (aside from VeriSign) with relevant experience

Global Name Registry is likely to be one of the few companies in the world which has actually transferred a gTLD Registry in cooperation with VeriSign.  As described in Sections C33, Global Name Registry has transferred a part of the .name Registry function to VeriSign under an agreement to operate part of the .name TLD, at the same time as Global Name Registry maintains and operates a mirrored Registry in the United Kingdom.

Global Name Registry and VeriSign therefore run similar and redundant services on each side of the Atlantic and have thereby created the world’s first inter-continental registry.  This gives rise to higher robustness and reliability for the .name registry.

The creation of this redundant and replicated registry involved processes and steps similar to the transition procedure described in Section C18.

Without close cooperation with VeriSign, transferring the .org Registry is likely to be extremely risky.  It is extremely important for the .org Transition that the teams both in VeriSign and GNR cooperate closely and with a good knowledge of each other’s systems and procedures.  GNR has had extensive experience with VeriSign as the only generic gTLD operator in the world to have transitioned portions of its .name registry.

The experience gained in this set-up will contribute immensely to the ease of transition in connection with the .org registry.   Both Global Name Registry’s and VeriSign’s comprehension of and experience with the other company’s development process, system designs and software are likely to contribute significantly to the ability of both parties to effect a smooth transition. 

Global Name Registry believes that this is a critical characteristic of the Global Name Registry application, which distinguishes it from the balance of the applications that are likely to be submitted.

It is important to note, however, while Global Name Registry’s working experience with VeriSign is an asset to ensuring the smooth and stable transition process regarding .org, following such transition process, VeriSign will not be providing any services to Global Name Registry in respect of .org.   As stated in Section C12, Global Name Registry intends to perform all aspects of the Registry Function itself.

Major Registry Transition Performed by Global Name Registry in May 2002

Further, GNR has great experience with moving a system while the system remained fully operational.  Without incurring ANY downtime on the services, GNR failed the UK main site over to the Disaster Recovery Site and moved the entire server park of the UK Registry.

The major European connectivity provider KPNQwest went into insolvency in May 2002 with almost immediate effect.  KPNQwest was the largest supplier of connectivity and other services in Europe, and its insolvency was significantly detrimental to many companies and ISPs on its network.  KPNQwest started to turn off its support of these companies almost immediately after its announcement of insolvency proceedings.

Although KPNQwest was only one of three bandwidth providers to Global Name Registry, the hosting location was on KPNQwest premises, and Global Name Registry has to move operations physically upon two days’ notice.

Global Name Registry nimbly responded to the KPNQwest news, moving the entire .name UK site (the main site), including the registry database, DNS servers, Whois servers, MX servers for .name email, WWW servers for corporate webpages, registrar www interface and “family pages” (the www.smith.name pages) over a three day period, not experiencing any downtime to the functionality of the registry.

To move its operation without adverse effect to the registry function, Global Name Registry did the following:

1.     Set up extra redundancy on one day’s notice on its hosting center in Hong Kong. This involved installing new servers, installing MX forwarding software, and putting the increased redundancy live.

2.     Failed over ALL services from the UK site to the Norwegian site, which instantly provided active services.  Global Name Registry experienced absolutely NO downtime in connection with ANY service.

3.     Global Name Registry took down the entire UK main site.

4.     Global Name Registry physically moved the entire server park of the main site, including a 1.2 ton ESS storage solution to another hosting location owned by Global Switch.

5.     Global Name Registry reconnected the system and brought the system back up.

6.     Global Name Registry failed the Norwegian site back to the UK, again experiencing no downtime.

Due to the training and experience of the Global Name Registry team, the physical move (and inherent disconnection) of the entire UK main site went without any service interruption.  This very recent success should give ICANN confidence that Global Name Registry is exceedingly suitable for undertaking a transition of the .org registry, as the experience has made Global Name Registry even more confident of future registry operations and transitions.

Registry Launch of .name and 100% Uptime

After the .name ICANN Agreement was signed in August 2001, Global Name Registry built and launched the .name registry.  The .name registry is among the most complex TLD Registries built to date because of the three-level domain structure (firstname.lastname.name), the .name email addresses (firstname@lastname.name), the defensive registrations (blocking domain names and .name emails) and namewatch registrations (monitors registrations in the .name space).

The .name registry was launched according to schedule on January 15, 2002, and the .name resolving services, Whois and registration interface have all maintained 100% uptime since launch, a claim that no other unsponsored generic TLD registry can make.  Global Name Registry also achieved 100% uptime during the major transition described below.

Operations of Large-Scale Email Solution – Nameplanet.com

Prior to winning the license to operate and administer, and to building and launching, the .name Registry, Global Name Registry operated an email solution under the name Nameplanet (the assets and licenses associated with this email solution have since been sold).  Nameplanet was founded by Global Name Registry founders in 1999 and with the reliable and stable technology and innovative functionality offered, saw its user base grow from zero to almost 2 million users in 18 months.  Due to an extremely scalable technology which was built to handle more than 50 million email users on web mail, IMAP and POP, the service enjoyed more than 99.5% update during its entire operating history, and served more than 40 million email views every month.

During operations, Nameplanet provided end user customer support in 8 languages to its global user base.  Global Name Registry sold the Nameplanet user base in the fall of 2001 to focus on the build-up and operations of the .name registry.

Product Development

The “Sunrise” Defensive Registrations (“DRs”) of .name have been a success.  The DR, for trademark owners, blocks the registration of a name or several names, rather than a resolving as an actual domain name.

To date, no reports have been made of any fraudulent registrations of DRs, and trademark owners, for which DRs were designed, generally have not complained of abuses within .name.  The DR was a novel concept introduced by Global Name Registry as part of the .name start-up to protect the .name space from illicit registrations and cyber-squatting. 

Most importantly, the .name concept continues to grow.  To date, the .name registry contains around 140,000 registered names (including both domain names and email addresses), and the thick .name registry with contacts, contains more than 350,000 objects.  During the entire first six months of the operations and growth, the services offered by Global Name Registry have been exceedingly stable and efficient, consistently enjoying 100% uptime.

Demonstrated Best-of-Breed Technical Results

Global Name Registry has, in its infancy, achieved world-class, best-of-breed technical results, which are on par with the best performers in the industry.  Today, Global Name Registry owns and controls:

1.     A world-wide DNS network, capable of serving more than 200,000 queries per second, or 17.2 billion queries per day.  Forty percent of this capacity is outsourced for .name, with additional capacity easily added.

2.     A centralized Whois source for .name, capable of serving more than 300 queries per second, or 26 million queries per day.  More capacity can be easily added.

3.     A registry (partly outsourced) connected to all ICANN-accredited registrars through the EPP protocol.

4.     A proven EPP client that has been distributed to all registrars, for use with both .name and also in use for the .info TLD; it is important to note that the C++ version of the EPP client was developed almost exclusively by Global Name Registry, and it also made significant contributions to the Java version.

5.     A real-time update mechanism to update the DNS and Whois services contents seconds or minutes after database updates happen.

6.     An active DNSO/ICANN and community participation through a dedicated policy team.

Relationships with ICANN-Accredited Registrars

Global Name Registry highly values its customers, the registrars, and dedicates much effort and time to ensure that registrars are supported efficiently and professionally at all times.  As described in Section C17.11, Global Name Registry also considers customer support (including technical assistance) to be vital to assist registrars in bringing new products like .name to the market, and Global Name Registry aims to work with each and every registrar to provide for a better end-user customer experience.

Demonstrated Experience to Work within ICANN Guidelines

Working within the ICANN guidelines and participating actively within the ICANN community, Global Name Registry launched the .name Registry and has continued to develop and refine its policies and procedures for this TLD.  This has included (i) working within the DNSO community (including on a task force and generally on the ICANN restructuring) and the gTLD constituency to frame and formulate policies for registry operations and domain name system processes, and (ii) working with ICANN-approved dispute resolution providers to implement a new and separate dispute resolution process for .name, the Eligibility Requirements Dispute Resolution Policy.  During the entire process, Global Name Registry has solicited and received input from the community and has been responsive to its needs.

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

The following concepts would be used to establish criteria to evaluate the success of the Transition

1.     Concept 1: Possibility of transitioning an existing SRS system with minimal disruption to SRS services

a.     The number of discovered discrepancies (and subsequent corrections) between the VRSN data and the transitioned data (should be zero once system is deemed ready for production and put into production)

b.     The total downtime taken by the SRS during transition

c.      The effort required from all parties, including GNR, VeriSign and ICANN

d.     The number of complaints from Registrars about errors or problems in the process

2.     Concept 2: Possibility of transitioning a gTLD in a stable and efficient manner without disruption to the DNS and Whois

a.     Disruption time of DNS and WHOIS (MUST be zero)

b.     Disruption time of SRS (should be as expected)

3.     Concept 3: Introducing a new operator of an existing TLD leads to more cost efficient services and better services

a.     The average reduction in price per year

b.     The average improvement in update frequency and update times

4.     Concept 4: Mechanisms for ensuring that all Registrars are treated fairly and equally in the transition process

a.     The number of complaints from Registrars about unfair treatment

b.     End users about errors or problems in the process

c.      ICANN satisfaction with process

d.     Community feedback into the process after selection of successor operator

5.     Concept 5: Transitioning a TLD can result in higher awareness and repurposing of the TLDs role in the Internet community

a.     Awareness about the transition among .org users

b.     Effect on marketing practices and communication to end users by Registrars.

6.     Concept 6: Mechanisms for allowing the .org community to give input on community matters and projects to improve the service to the community

a.     .org Community participating in the OrgForum

b.     .org Community benefiting from the Causeway Community Foundation and the OrgCenter

VeriSign, Inc., the current operator of the .org registry uses a registry-registrar protocol (RRP) documented in RFC 2832. At the time of the transition, the selected successor operator will be required to continue to support the RRP. In addition, the selected successor operator will be required to implement support for the IETF provreg working group's protocol specification for an Extensible Provisioning Protocol (EPP) no later than 135 days after it is adopted as a Proposed Standard [RFC 2026, section 4.1.1]. Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP within the required time frame, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.

This Section C22 details how the transition from RRP to EPP will be handled by the Global Name Registry registry services systems and how the protocols will be migrated.

This Section C22 also explains how the registry will migrate into a thick registry, where contact information can be accessed and stored, from the thin registry that it currently is. The database Section C17.3 explains in more detail how the data model proposed supports a thick registry.  With respect to .name, Global Name Registry currently operates a thick registry for .name and has implemented the data models and systems to support a thick registry.

Introduction to the Transition from RRP to EPP

Moving a registry from RRP to EPP would in some cases result in a “hard” transition date.  Such hard changeover dates are generally difficult for registrars who utilize different systems, processes and methods for fulfilling the customer experience.  A hard changeover date is therefore likely to result in some confusion and instability in the marketplace.

Global Name Registry proposes to avoid hard changeover dates by softly transitioning the RRP to EPP, and simultaneously supporting both protocols during a longer period, lasting up to 18 months.  This would allow registrars to transition when their systems and personnel are ready to do so.

It is also extremely relevant to look in Sections C18 or C17.3 for a fuller explanation of the transition from a thin to thick registry.

Since the transition of the .org registry from VeriSign to Global Name Registry will be the first registry to transition from RRP to EPP (taking into account the existing, large userbase), Global Name Registry realizes that the two protocols will have to co-exist on the same data material for a potentially long transitional period.  Therefore, the system should support both protocols simultaneously, and at the very least, support RRP from day one.  Global Name Registry proposes a solution which will allow all registrars currently on RRP to remain on RRP until they have the resources available to migrate to the newer protocol EPP.

The entire Global Name Registry system is built on an extensible protocol independent internal API, which in principle is a super-set of the functionality offered by RRP and EPP (and possibly other protocols in the future).  Global Name Registry will be able to handle a robust and stable transition to EPP for all registrars, with the very significant advantage of not having any “sudden death” period.  The figure below illustrates the layered structure of a protocol dependent layer (which effectively holds the EPP and RRP servers), and a non-protocol dependent layer (which interfaces the data structure in the database and creates appropriate responses).

 

Figure 4: Illustration of layered architecture from EPP/RRP to database

 

For the purpose of this Section C22, a registrar that is using EPP to access the objects in the .org registry, will sometimes be called an “EPP Registrar,” while a Registrar that uses the RRP to access the objects in the .org registry will sometimes be called a “RRP Registrar.”

The protocol specific layer - Differentiating between RRP and EPP commands and functionality

The protocol specific layer does everything related to the RRP and EPP protocols.  All protocol-specific handling is done in this layer.

Given that the RRP and EPP has different ways of requesting, committing and reporting from operations in the database, Global Name Registry uses an internal API that is protocol independent to interact with the data in the database (the “data model”).

The protocol specific layer handles the translation between the GNR API and the protocol in use.

As an example, for RRP, the logic in this layer will hide any contact references of objects in the data model, since contact objects cannot be accessed by RRP.

Similarly, as a second example, the protocol specific logic will ensure that the representation of the Authinfo token used in EPP will not be needed under RRP since the RRP protocol does not allow obtaining or setting the token necessary to allow an authenticated transfer. As a consequence, during the dual-protocol period when both EPP and RRP are allowed, unauthenticated transfers like under RRP are possible.

The protocol specific layer will translate any protocol specific issues to the internal GNR API, which commands are sent to the next layer.

The internal API supports all functionality offered by RRP and EPP and is designed to also scale to future protocols if and when they may be needed.

The Protocol independent layer

The protocol independent layer does all the consistency checking of the command; for example this layer will check that the domain name is for .org and not for another TLD, that the domain name is not previously registered (note that this check command is not done in the database, but in the real-time updated Whois, which scales linearly unlike the authoritative database).

If all checks pass, this layer prepares the SQL statements that will commit changes to the database.

Mapping RULES

The following sections detail some of the rules necessary to operate RRP and EPP simultaneously and illustrates some of the logic that the protocol specific layer incorporates to translate the respective protocols into the internal GNR API and the data model in the database.

Going through the two protocols, mandatory parameters in EPP which are not present in RRP are found. The API will make these parameters optional for the protocol layer and supply the missing data to the database internally.  Missing mandatory fields in the EPP/RRP requests are in any case dealt with in the protocol layer of the Core SRS System. This protocol layer will therefore enforce mandatory parameters that are not mandatory for the internal API.

The two protocols EPP and RRP are nevertheless designed for the same purpose, and their similarities far outweigh their differences. To uncover any "trouble spots" in the migration, we have provided a translation, or mapping, of the three major entities in the protocols:

1.     Mapping RRP commands to EPP commands

2.     Object status mapping

3.     Result code mapping

 

This mapping is done by the protocol dependent business logic layer outlined in the figure above.  It uses a defined set of logic and mappings to unambiguously translate a protocol command to a non-protocol specific command that fits with the internal database structure and business rules.

These mappings are described in the following three chapters of this section.

Protocol specific rules

Certain protocol specific rules should be noted:

·         Transfer of an object from an EPP Registrar to a RRP Registrar will result in deletion of the contact references in the object and update statuses associated with the object transferred to conform with the RRP.

·         Transfer from RRP to EPP is unauthenticated (no authInfo)

·         Transfer from EPP to EPP is authenticated (authInfo is mandatory)

Command mapping RRP ® EPP

The EPP protocol contains every element of RRP, but there are some parameters to EPP commands that do not have a corresponding RRP equivalent.  To prove the concept of using a combined API for the business login of both protocols, we have included a complete command and parameter mapping from RRP to EPP with explanations on how we will generate the missing mandatory parameters in EPP.

 

Note that domain transfers will be allowed unauthorized to and from RRP registrars during a time-limited period.  Since this is currently the principle behind RRP transfers (un-authenticated but possibility for Registrars to Acknowledge or Deny the transfer), we are not introducing any new security issues. We realize that such an arrangement is necessary to facilitate a smooth transfer from RRP to EPP.

Object status mapping RRP/EPP ® internal API

We can glean some insight into the internal API used to support both EPP and RRP by noting that the objects will be flagged internally with EPP statuses and one additional flags (RrL). This will allow for unambiguous translation back to RRP for any set of statuses set by the RRP protocol.

 

 

Explanation of table codes:

“O” : OR : if any status is set with O, the RRP client reads the RRP status as set

“X” : AND : the RRP command will set all corresponding API statuses as set (note that upon transfer, Registrar Lock and Registrar Hold statuses are deleted)

“-“  : The RRP Registrar will assume that these flags are set, but they are not used in the conversion

 

• RRP: Active
  ”Fallback” status used when no other status flags are set
  Domain with no delegation information: INACTIVE
  Domain with delegation: ACTIVE
• RFC 2832, RRP v. 1.1.0, does not specify whether a transfer is allowed on a domain with status Registry Lock/Registry Hold/Registrar Lock/Registrar Hold.  The RFC explicitly states that renewals should be allowed, but modifications and deletions prohibited.  We regard the transfer of a domain as a modification in this respect, and set the EPP flag Client/Server Transfer Prohibited as appropriate.

o        In EPP the Pending Transfer flag will be set when a transfer request is sent. This prevents all updates and deletes on the object. No such lock is indicated in the RFC 2832, RRP v. 1.1.0. The following will apply:

o        RRP transfer request on RRP object. Pending Transfer flag is not set, since this will invalidate the RRP object status (an object can not be both OK and Pending Transfer). The objects status will remain unchanged, as is in the current RRP implementation.

• RRP transfer request on EPP object. Pending Transfer flag is set, no transform commands other than transfer will be allowed on the object.

Issues

The following issues should be noted, although none of them are damaging to the functionality:

·         Renew-prohibited cannot be read in RRP.  This status does not exist in RRP.  This status is not inherited upon EPP to RRP transfer.  If this flag is set, renewal is denied.

·         Pending-transfer cannot be read in RRP (but normal out-of-band communication will be used (email)).

·         Pending-verification cannot be read in RRP.

·         Registry-Lock and Registry-Hold will be read in RRP if any of the statuses (SDP,STP,SUP) are set.

Resultcode mapping EPP ® RRP

Most of the result codes will be generated in the protocol dependent layer based on the communication with the internal API.  It is however interesting to have a look at the similarities of the two protocols and to use this as a platform on which to build the return codes from the API functions.

 

 

Protocol Support for Thick Registry

With EPP, Global Name Registry supports creation of “thick” objects in the registry.  The business logic will support EPP transactions to operate on objects that have “thin” characteristics (no contacts associated), or objects with “thick” characteristics (contacts associated).

The transition from a thin to thick registry will start when EPP is supported by the registry. After that, objects can be made thick simply by adding contacts and contact information.  This conversion will not be mandatory for all registrars, but registrars who want to use this feature can do so from day one of EPP support.   Based on an informal survey of registrars, Global Name Registry has learned that registrars would prefer use of a thick registry.

Objects will also be transferable between one registrar using the RRP protocol and anther registrar using the EPP.  As the discussion above shows, such a move will result in contact data being deleted if an RRP registrar gains an object where contact details are stored.  This, however, is consistent with how objects are transferred under the RRP today.  Contact information is always re-created by the gaining registrar.

However, after a period of parallel support of both RRP and EPP, the registry will discontinue support for RRP and only allow EPP operations.  This effectively will mark the start of a growth phase for the thick registry, since object contact information no longer will be deleted and therefore will be constant or in growth.

Finally, the registry will introduce rules to convert all objects in the registry to thick objects. The two following rules will apply to registry operations:

·         For the Create command:  contact references must be included when creating a registered name.  Otherwise the creation will fail.

·         For the Renew command:  contact references must be present in the object when renewing a registered name.  Otherwise the renewal will fail.

 

These two rules will ensure that registrars who are creating or renewing a registered name on behalf of a registrant will have to set contact information for the operation to succeed.  In these scenarios, registrar has an active relationship with the registrant, and getting the contact information from the registrant should not be an issue.

The figure below shows the timeline and different phases of the move from the thin registry to the thick registry.

Figure 5: Timeline for protocol transition and thin/thick transition

If the registry were to enforce at any point that all objects in the registry should be thick, this would pose a tremendous problem for registrars.  Some registered names have expiry dates far in the future, and the registrar may not be in a position to add contacts to existing registered names where the registrant is not properly informed.  Therefore, Global Name Registry has chosen the approach where only new or renewed objects are required to contain contact information.

The timeline for the protocol transition and the thin/thick transition is shown in the figure above. The phases and timelines will be the following:

 

·         Phase I: Support of RRP as VRSN does today. This phase would last six months after the Transition from VeriSign to Global Name Registry is completed.

 

·         Phase II: Introduces EPP support, but the registrar may remain on RRP.  However, it will be recommended that the registrar commence migration to EPP at this time, although they will have 12 months to complete the transition.  During this period, RRP and EPP co-exist in the registry, and the full functionality of the EPP can be used, including to create thick objects.

 

·         Phase III: At the beginning of this Phase, all Registrars must be migrated from RRP.  The registry will discontinue support for RRP.  However, objects may still be created, modified or renewed as thin objects.  This Phase III lasts six months.

 

·         Phase IV: During this phase, all objects will naturally be converted from thin to thick.  The registry anticipates that this conversion may take as long as the longest registration period available, 10 years. Upon termination of this time period, all objects will be converted.  The registry will commence enforcing two rules when EPP objects are Created or Renewed:

 

o        For Create:  Contact references must be included.

o        For Renew:  Contact references must be present in the object.

 

The most important feature to support the thick registry lies in the data model and not in the protocol.  Information on the data model can be found in Section C17.3

Conclusion

It is possible to simultaneously support RRP and EPP, although Global Name Registry believes it is best to ensure that there is a transition from RRP to EPP over time, finally arriving at a registry which supports EPP only.

However, doing the transition from RRP to EPP slowly is important to ensure stability and continuous operations by all ICANN-Accredited Registrars.  Given that the EPP is still a new protocol, Global Name Registry believes that the concern for registrars’ transition is appropriate.

The use of an internal API developed by Global Name Registry to create a protocol independent layer interacting with the data model is a highly scalable initiative, and Global Name Registry has the experience with such structures to make the RRP-EPP migration smooth and easy for registrars.

Moving the registry from a thin to a thick registry is easily supported with the EPP, and the data model of the registry supports creation of objects with contact information associated. The migration from thin to thick will happen over a period of time, with acceleration of the migration controlled by each individual registrar’s simply creating and associating contacts with registered names.  This approach ensures that the migration from thin to thick becomes a stable and incremental process which can be easily handled by all registrars and registrants.