C18. Transition Plan. This should present a detailed plan for the transition of the Registry Function from the current facilities and services provided by VeriSign, Inc., to the facilities and services you propose. Issues that should be discussed in this detailed plan include:

The DotOrg Foundation and its Registry Function provider, Registry Advantage, agree with the paramount importance of continued stability of the global domain name system and the .org TLD.  Stability is particularly vital throughout the transition period from the current management structure into the new .org structure.  Per the DotOrg Foundation’s guidance, Registry Advantage will use the resources described below to efficiently transition the .org TLD from the old administration to a more robust, centrally administered scalable top-level domain. It will ensure the stability by following consistent and expected polices, accompanied by timely notifications.  Following are registry commitments:

• Providing adequate notice to the ICANN-accredited registrars currently supporting .org names regarding the change in registries, any new registration policies, and the potential need to execute new registry agreements.
• Posting information about the new .org operator on www.dotorgfoundation.org.
• Taking recommendations from the DotOrg Foundation, its Directors and Advisors regarding the .org domain.

As described in the introduction to Question C18.6, Registry Advantage has successfully transitioned its current ccTLD registry clients.  It will use this experience, expertise, and resources to conduct a stable .org transition.

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

The primary goal of the transition is to ensure the continuity and stability of the .org TLD by ensuring zero data loss, continuous availability of the domain name system, no conflicts between new registrations and existing registration data, and clear communication with all stakeholders throughout the transition process.  Ideally, no disruption to registration or Whois services would occur, but in order to guarantee data integrity, it is important that some data reconciliation be performed after VeriSign has performed the final registration-related event and prior to the resumption of these services.  Disruption of the Whois service is expected to be minimal, as the Whois service may be used by the Internet community to verify the accuracy of data contained within the DotOrg Foundation’s registration database.  The shared registration system will be disabled for a week, in order to allow for a full reconciliation of the new database.

Dates included in the transition plan below are contingent upon ICANN and the DotOrg Foundation signing the registry agreement no later than November 1, 2002.

A. Contract Negotiation

Once ICANN has selected the DotOrg Foundation as the successor registry operator, two activities will begin immediately.  First, DotOrg Foundation will commence contract negotiations with ICANN with the intent of finalizing a contract no later than November 1, 2002.  Second, the registry will begin to provide registrars with initial information about the transition plan, including target dates for each of the major activities throughout the transition process.  At the same time in anticipation of signing the Services Agreement, Registry Advantage will begin to bring in the necessary staff and make the capital investments to be ready for the transition and launch outlined in here.

B. Preparation and Outreach

Once the contract with ICANN has been signed, DotOrg Foundation will begin working with registrars to prepare for the transition to the new registry.  With the assistance of Registry Advantage, this process will begin by distributing contracts to registrars immediately after the registry contract has been finalized.  Each registrar must execute this contract in order to allow them access to the Registry Advantage registrar toolkit (RTK) and to the testing environment. 

The RTK and all documentation associated with the new registry’s operation will be distributed immediately after receipt of the registrar’s contract by the DotOrg Foundation. Registrars will be given immediate access to the RRP and EPP testing environment known as TEST (Testing Environment, Support and Training).  Registrars will be given access no later than November 1, 2002, if the signing of the registry contract allows for reasonable preparations to take place prior to the distribution of the RTK and the opening of the test environment.

C. Data Migration

Beginning approximately 30 days prior to the transition of the registry, on or about December 1, 2002, Registry Advantage intends to begin the process of migrating data from the legacy registry hosted by VeriSign to the new registry system.  This process will require regular transmission of the registration and zone file data from VeriSign to Registry Advantage, ideally on a daily basis.  Although the first data transmission must be a full export of the relevant data from the database, the subsequent daily transmissions may be either full database dumps, or an incremental data set with only changes in data from the previous day.

Data sets received from VeriSign will be used to construct the registry’s initial database.  The intent is for each of the following data elements to be preserved from the legacy database to the new registry database:

• Domain name
• Sponsoring registrar
• Name servers
• IP address of each name server
• Create date
• Created by
• Last modified date
• Last modified by
• Expiration date

The fields in boldface above are required for a successful transition to occur without affecting the stability of the domain name or adversely affecting existing registrants.  The IP address of name servers will only be preserved if the name server is within the .org TLD.  Currently, VeriSign is required to maintain these “glue” records for all name servers within the .com, .net, or .org domain names.  At the time the .org domain is split away from the other two gTLDs, the .com and .net glue records for .org name servers will become unnecessary; similarly, the .org glue records for .com and .net names will become superfluous and should also be removed.

In addition to the “current state” data described above, Registry Advantage intends to transfer whatever historical transaction data is feasible.  This data, which indicates changes made to each domain name in the past, is useful in providing customer service to registrars.

Once a reasonable set of data has been imported into the Registry Advantage systems, it will be exposed for test and reconciliation purposes via two interfaces:  a Whois system and a DNS zone.  These services will be run using unique sub-domains within the dotorgfoundation.org top level domain name.  For example, the Whois server may use a domain name such as testwhois.dotorgfoundation.org, and the zone file may be rooted in a sub-domain such as testzone.dotorgfoundation.org.  In such a case, an imported name such as example.org would be available for testing purposes as example.testzone.dotorgfoundation.org.  These services will be publicly accessible and will allow the Internet community to validate the accuracy and completeness of the imported data set.  Additionally, for those entities that are willing to enter into the appropriate agreements with DotOrg Foundation, bulk access to the Whois and zone file data will be provided.  Accredited registrars who have entered into agreements with DotOrg Foundation will receive a daily report with both zone file and registration data for all domain names they sponsor.  To the extent that such additional services need to be part of the DotOrg Foundation’s agreements with the participating registrars, the Foundation will consult with ICANN on amending the registry-registrar agreements. 

D. Termination of Service by VeriSign

VeriSign’s contract to operate the .org registry terminates at the end of December 31, 2002.  It is anticipated that VeriSign will continue to process registration-related events up through that time.  Consequently, it is imperative that a final transfer of the complete registration database (with all of the data elements identified above) be performed immediately after the suspension of registration-related services by VeriSign.  This data set will be used to finalize the new registry’s database prior to the final period of data verification and reconciliation.

VeriSign has agreed to continue to provide DNS services for the .org TLD for up to a year following the termination of its agreement as registry operator.  The continuous operation of these services is essential to ensuring a smooth transition of the TLD.  While the final data migration is occurring, and until Registry Advantage has fully tested its zone file generation with the entire data set, VeriSign should continue to operate its DNS constellation with a .org zone file generated with the database in its final state at the time of the suspension of registration services.  This allows for domain names to continue to resolve while the transition in registry and in authoritative databases takes place.  While VeriSign continues to provide DNS service with this legacy zone data, no updates to the zone file will occur.

E. Reconciliation

Although it is technically feasible to begin the operation of all registry systems within 24 hours of receiving the final data set from VeriSign, DotOrg Foundation intends to allow a one week period in which registrars and the Internet community may reconcile the contents of the new registry’s database with the legacy system operated by VeriSign.  Within twenty-four hours of receiving the final data set, Registry Advantage will deliver all registrars that have signed contracts with full reconciliation reports to allow the registrars to fully reconcile the data in the new registry database with their own data.  These reports will include all zone file data and registration information present in the Registry Advantage database for domains sponsored by the registrar.

Also planned for the first twenty-four hours after receiving the finalized data from VeriSign, Registry Advantage will begin providing Whois service that incorporates the final data set.  At this time, the Whois service will be provided on its final and permanent address.  This address will be determined and announced prior to the beginning of the migration process, and will be similar in format to whois.dotorgfoundation.org.  The test Whois address used throughout the data migration process will continue to operate as well, and will remain in operation until at least 30 days after the finalization of the transition process.

Zone file data will also be made available through the same DNS sub-domain used throughout the migration process.  The operation of this sub-domain was described in C 18.1.D above.

Finally, bulk access to both Whois and zone data will continue to be provided to those parties that have entered into the appropriate agreements with DotOrg Foundation.

Once data has been made available to registrars and to the Internet community through each of these mechanisms, DotOrg Foundation will allow and encourage registrars to notify the registry of any discrepancies between the new and legacy registry databases.  These notifications may take place through the usual customer support mechanisms.  Throughout this process, registrars will be responsible for interacting with their .org registrants, who will not be able to contact the registry directly for customer service or to make notifications of data mismatches.

F. Zone file propagation

After the registry has successfully created zone files using the complete set of .org data for a period of three days, Registry Advantage will coordinate with VeriSign to begin providing the zone files that VeriSign uses within its DNS server constellation.  Zone files will be transmitted to VeriSign by a mutually agreed mechanism such as FTP or DNS zone transfer (AXFR).  Security mechanisms will be implemented in order to verify that zone data originated from Registry Advantage.

Registry Advantage will work with VeriSign in order to ensure that zone file data is properly propagated to the VeriSign DNS server constellation.  Testing will include performing NS type queries for each domain name registered within the TLD on both Registry Advantage-managed servers and VeriSign managed servers to verify that the results are identical on both sets of servers.  Other records, such as the relevant SOA, NS and A records for the .org domain name itself, will also be tested.

G. Resumption of Shared Registry System

No fewer than three days after making zone file and registration data available to registrars and the Internet community as described in C 18.1.E above, DotOrg Foundation will begin providing shared registry system (SRS) services.  These services will allow registrars to register new names, modify existing registrations, and renew and delete domain names.  The initial plan is to begin SRS operations on January 8, 2003; however, DotOrg Foundation will closely monitor the number of errors in registry data reported by registrars.  If the number of reports is high, the resumption of the SRS service will be delayed to ensure that a full reconciliation of the registry database has occurred.  In such a case, the registry will begin notifying registrars of the nature of the delay and of revisions to the transition plan at least once every six hours, as described in C 18.2, below.

In order to prevent the registry systems from becoming overwhelmed by an initial flood of queued requests from registrars, Registry Advantage will slowly ramp up registrar’s connections to the SRS.  Initially, each registrar will be allowed only a single connection to the SRS.  After stable operations in this mode for a period of no less than eight hours, the registry will allow each registrar to use one additional connection.  In this manner, the number of connections available to each registrar will be gradually increased over the subsequent week, until after one week registrars are allowed a full set of connections.  Note that in order for the total number of connections to be increased to the full allowance during the course of a week, the rate may be greater than one additional connection per eight hours; it is expected that the increasing number of connections per registrar will not be linear, but that connections will be adding increasingly rapidly at the end of the week.  This conservative approach ensures stability while allowing registrars to perform needed registrations and modifications of the registry database.

Registry Advantage will allow access to the SRS using two interfaces.  For compatibility with existing implementations, registrars will be able to connect to the SRS using the same RRP protocol that VeriSign currently uses for .org registrations.  Additionally, an EPP interface will be provided with the same capabilities.  Although EPP is capable of supporting a thick registry, initially registrars will only be allowed to provide the same set of data allowed by the RRP.  Registrars will have the option of using the EPP or RRP interface, and will be provided equal access to the SRS regardless of which method they choose.

H. Modifying the root zone

Once zone data has been successfully propagated through both Registry Advantage’s and VeriSign’s DNS constellations for a period of at least ten days without error, DotOrg Foundation will request that IANA update the list of name servers associated with the .org TLD to include those operated by Registry Advantage.  Initially, the list of name servers will include a mix of VeriSign and Registry Advantage name servers.  However, in order to ensure rapid propagation of zone data and to maximize the ability to respond to problems with DNS servers, after another period of no less than thirty days, DotOrg Foundation will request that IANA update the list of authoritative name servers for the .org TLD to include only name servers managed by Registry Advantage.  At this point, the transition away from VeriSign’s infrastructure will be complete.

The major events of the transition are summarized in the following chart.

Figure C18.1.1 Transition Timeline

Thin to Thick

Once the transition of registry operations has been completed and the new registry has been online and stable for a period of time, DotOrg Foundation will begin a second transition, switching the registry from a “thin” registry model to a “thick” registry model.  This transition is intended to increase the utility of the registry to the Internet community by providing a centralized repository for all registration data relating to .org domain names.

Since the beginning of the competitive registrar model in June of 1999, the .org registry has been operated by VeriSign using a thin registry model.  In this model, the registry stores only a limited set of data related to each domain name, including:

• Sponsoring registrar
• Name servers
• Creation and expiration dates

The registry stores no social data such as the registrant’s name, address or telephone number, nor is any information regarding administrative or technical contacts stored within the registry.  An end user attempting to obtain Whois data related to a particular domain name is consequently forced to perform two queries:  first, a query to the registry to discover the sponsoring registrar, and then a subsequent query to that registrar’s Whois server to obtain the complete set of data.  This has caused a number of problems for the Internet community, including confusion over the correct procedure for obtaining Whois data, inconsistent data formatting returned by various registrars, and some instances in which registrars have not provided a functioning Whois capability at all.

DotOrg Foundation proposes to transition the operation of the .org TLD to a thick registry.  The recent launches of new gTLDs such as .biz, .info and .name, as well as large established ccTLD registries such as .de, demonstrate the viability and success of the thick registry model.  The specific details of the transition from thin to thick registry operations are subject to negotiation with ICANN as well as feedback from registrars, registrants, and the affected Internet community, but the implementation will follow a phased approach as described below:

• In phase one, the registry will prohibit the use of contact objects.  In this mode the registry is purely a thin registry.
• In phase two, the registry allows for contact objects to be created, modified and deleted, and for contact objects to optionally be associated with domain names.
• In phase three, the registry requires that contact objects be associated with domain names when they are created or renewed.
• In phase four, only those domain names with contact objects are published into the .org zone file.
• In phase five, the registry will prohibit the use of domain names without contact objects associated with them.  Any domain name without contacts will be automatically deleted from the registry’s database.  In this mode the registry is purely a thick registry.
• The thin to thick migration process is described in more detail, including proposed dates for each of these phases, in Question C22.

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

Because VeriSign will continue to provide DNS resolution services on its name service infrastructure for up to a year after the beginning of the transition period, the DNS resolution function will continue uninterrupted throughout the transition period.  Other registry services, such as Whois and DNS zone file generation, may suffer from a limited interruption in service while the final set of data is imported from VeriSign.  The continuous updating process during the month leading up to the transition of registry operators should limit any unavailability of the system to less than 24 hours.  Although the registry would be fully capable of operating at that time, DotOrg Foundation is providing a one week period after the data migration has been completed to allow registrars and other members of the Internet community to reconcile the contents of the new registry database with the data contained in VeriSign’s legacy registry.  This one week period will apply to any system, such as the SRS and portions of the Account Management Interface, that have the capability to perform write operations on the registry’s database.  This period is not a technical requirement, but is suggested by DotOrg Foundation in order to ensure the stability of the transition and to minimize the risk of any data loss or conflicts during the migration.

The Whois service will suffer a limited interruption in its operation while the final data set from VeriSign is imported into the DotOrg Foundation database, managed by Registry Advantage.  This interruption in service will be limited to no more than 24 hours.

In order to allow registrars to fully verify the new registry’s registration and zone file data, the registry will temporarily suspend all registration services during the first week of the transition, beginning at midnight on January 1, 2003, and ending on January 8, 2003.  During this time, no change to the registry data may occur.  Beginning on January 8, the registry will begin to allow registrars to connect to the shared registry system with a limited number of connections.  The number of connections allowed per registrars will gradually be increased over the following week, until the registry is operating at its full capacity.

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

A number of contingency plans exist in order to provide the smoothest possible transition in the event that elements of the planned transition do not succeed completely.  This section of the proposal outlines several of those contingency plans.

In the event that any significant portion of the transition does not proceed according to the schedule described in section C18.1, registrars will be notified promptly of any delay or modification to the transition plan.  Additionally, during any period of time in which a transition milestone has not been met and a revised transition plan has not been announced to all registrars, the registry will notify registrars of the current status of the transition process at least every six hours, until a revised transition has been provided.  Finally, DotOrg Foundation will notify end users of the status of the transition by making notices available on its website.

Zone File Generation

 In the event that Registry Advantage is unable to begin generating zone files according to the scheduled outlined in section C18.1, the following steps will be taken:

• The VeriSign name server constellation will remain authoritative and continue to serve the VeriSign-generated zone file, with data current as of December 31, 2002.
• The SRS will not become operational for purposes of adding, modifying or deleting .org domain names until Registry Advantage has successfully generated .org zone files for three days.
• Once Registry Advantage has successfully generated .org zone files for three days, VeriSign will begin to obtain zone file data for its name servers from Registry Advantage.
• Subsequent to VeriSign beginning to obtain zone data for its name server constellation from Registry Advantage, SRS operations will resume according to a similar staggered schedule as described in section C18.1.
• IANA redelegation will not be requested until zone file generation has been successfully performed for ten days.

In the event that the Whois service does not become operational according to the schedule outlined in section C18.1, the following steps will be taken:

• Registrars will not be required to submit their final list of domain names with invalid registration or zone data until three days after the Whois service becomes operational.
• The SRS will not become live for at least 24 hours after the deadline for registrars to submit notifications of incorrect zone or registration data.  The registry may, at its discretion, elect to begin providing DNS services 48 hours after the deadline for such notifications.

Shared Registration Service

A failure of the shared registration service should not affect any of the read-only services of the registry, such as zone file generation and distribution, WHOIS, and reporting.  In the event that the SRS service does not become operational according to the schedule outlined in section C18.1, but becomes live within fifteen days of the planned date, the rest of the transition plan will proceed according to the original schedule.  In the event that the SRS service becomes live more than fifteen days after the original schedule, the transition plan will be revised to adjust subsequent milestones appropriately.

DNS Resolution

A failure to begin providing DNS Resolution services according to the schedule in C18.1 would have no effect on other elements of the transition.  In such a case, Registry Advantage would simply continue to rely upon VeriSign to provide DNS resolution services for a longer period of time than initially anticipated.  VeriSign’s current contract requires that they provide this service for up to a year, which should provide Registry Advantage more than enough time to resolve any issues that may arise.

New Facilities

None of the proposed new facilities are required in order for the transition to occur.  The registry’s alternate site for core registration services (described in C17.1) provides an added layer of redundancy and reliability, but given the significant high availability features present at the primary site, Registry Advantage considers it to be acceptable to begin registry operators in the unlikely event the secondary site is not fully operational at the time of transition.

Similarly, Registry Advantage has proposed a total of eight DNS POPs to ensure maximum performance reliability; however, it would be acceptable to begin operations if only six of these sites were active.  In the event that not even six of the sites were active at the time of the transition, Registry Advantage would continue to make use of VeriSign’s DNS constellation until such time as at least six Registry Advantage DNS POPs were active.

Data Migration

The frequent sample data imports during December, 2002, make unexpected problems in the final data migration process extremely unlikely.  However, in the event that the data migration is delayed or takes an unusually long period of time, Registry Advantage will be required to adjust the dates of various other steps in the transition process, such as activation of the live Whois service, zone file generation, and activation of the SRS.  In the event of a delayed data migration, Registry Advantage will make activation of the live Whois service its first priority.  As described above, two other events in the transition process are dependent on the activation of the Whois service:

Registrars will not be required to submit their final list of domain names with invalid registration or zone data until three days after the Whois service becomes operational.

The SRS will not become live for at least 24 hours after the deadline for registrars to submit notifications of incorrect zone or registration data.  The registry may, at its discretion, elect to begin providing DNS services as much as 48 hours after the deadline for such notifications.

Data Errors

In the event that significant errors are found in the new .org registry database as part of the reconciliation process (Step V in the transition process described in C18.1), Registry Advantage will delay the activation of the SRS so that these errors can be resolved prior to any conflicting entries being made into the registry database.  Once any errors have been resolved to Registry Advantage’s satisfaction, Registry Advantage would provide registrars with a subsequent period no shorter than 24 hours to perform additional reconciliation against the revised registry database.  The SRS would be activated no fewer than 24 hours after the end of this additional reconciliation period.

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

The transition should have minimal impact on both .org registrants and Internet users seeking to resolve .org names.  DNS operations will continue uninterrupted throughout the transition period, and all names registered as of midnight on January 1, 2003 will continue to resolve throughout the transition and until such time as they are deleted or removed from the zone file by the sponsoring registrar.

• During the brief period in which the SRS is not available, .org registrants will not be able to perform any of the following functions:
• Registering new domain names
• Modifying name servers for existing domain names
• Initiating a transfer of registrar for an existing domain name
• Deleting domain names

Finally, as indicated in C18.2, there may be a short period in which the Whois service is temporarily unavailable.  This will prevent both .org registrants and Internet users in general from obtaining Whois information.

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

The DotOrg Foundation views a smooth and stable transition of the .org registry as one of its key charges if it is selected as the new registry operator.  While the Foundation is prepared to take on the principal responsibility for this goal, a smooth transition will naturally require VeriSign’s cooperation. 

As described in item C18.6 below, Registry Advantage employs a multi-step transition methodology to ensure that data is moved between registry operators with no data loss and minimal downtime.  VeriSign’s co-operation will primarily be required during the two phases of the migration process:  Current State Analysis and Execution.  During the Current State Analysis, VeriSign personnel will be required to answer straightforward questions about the existing operation of the registry, the data within the zone, as well as appropriate mechanisms for data to be moved between VeriSign and Registry Advantage.  Once the Data Transfer and Migration plan has been generated by Registry Advantage personnel, it will be provided to VeriSign for review and comment.

During the Execution phase of the migration process, it is vital that VeriSign provides zone file and registration data to the DotOrg Foundation, or its sub-contractor, Registry Advantage.  Zone file data should be made available to the registry each time that the data is updated.  Registration data should be provided on at least a daily basis, with an option for either a full database dump or an incremental list of changes to the data within the past 24 hours.  Alternatively, it would be acceptable for VeriSign to provide a mechanism to the new registry operator to interactively query its database so that information could be extracted in real-time.  Regardless of the specific mechanisms established above, VeriSign must provide DotOrg Foundation with a full database dump immediately upon terminating registration services.  This final data set will be used as the authoritative basis for the new registry’s database. The process will take place during the thirty days leading up to the transition, followed by the one time database dump at the conclusion of the VeriSign contract.  This cooperation is imperative to ensure an accurate registry transition, which protects current registrants and registrars.

During the transition process, VeriSign must continue to provide name service for .org names, as specified in their existing .org contract, Section 5.1.5.  This service is essential to ensuring a smooth transition for Internet users seeking to resolve .org names.  This particular element requires two modes of operation by VeriSign.  Immediately after the transition occurs, VeriSign must continue to serve the .org zone data as it existed at the time of cutover.  While other services, such as the SRS, move over to the DotOrg Foundation, the continued operation of the VeriSign DNS constellation will ensure that no disruption of the DNS service occurs.  Once DotOrg Foundation is ready to begin publishing authoritative zone data, VeriSign must begin the second mode of operation in which it receives the zone file data from the DotOrg Foundation.

Finally, once the transition has occurred, VeriSign should modify certain services (such as its web page and Whois service) to indicate that .org registry services have transitioned to the DotOrg Foundation.  This will allow registrants and Internet users to locate these services after the transition has occurred and minimize confusion and a slow down in registrars’ or registrants’ access to registry services.

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

Registry Advantage has significant experience migrating TLD operations onto its infrastructure.  Seven country code TLD operators have entered into agreements in which Registry Advantage will provide outsourced technical operations of their registry infrastructure, and at this time four of these have been successfully migrated to the Registry Advantage infrastructure.  In all cases, these transitions have been completed with no interruption of the domain name service and no data loss.  Additionally, in order to ensure a smooth transition, legacy registration mechanisms (such as e-mail templates) have continued to operate throughout transition periods with no interruption of service.

The migration process is built upon a commitment to migrating all customer data and operations to the highly scalable and functionally robust Registry Advantage infrastructure with no impact to end users, registrars, or other members of the community.  The Transfer and Migration methodology is a total end-to-end solution and flexible enough to work with any partner.  This process includes the following phases:

• Current State Analysis
• Data Transfer and Migration Plan
• Training
• Execution
• Parallel Operation
• Final Cutover

Registry Advantage has significant experience managing migration projects for large volumes/quantities of data that are currently being used in a production, high volume transaction environment.  Registry Advantage’s translation layer technology provides an interim mechanism for existing registrars and/or registrants to easily interface with our systems.  Registry Advantage’s experience and applications enable the management of the migration with little to no downtime.

Registry Advantage submits documents to its ccTLD registry customers in order to guide them through the migration process, and in order to obtain an initial set of information regarding the registry as part of the Current State Analysis. The process is described below.

The Process

Below is a description of the current process analysis.

Current State Analysis: During the initial phase of the migration process, registrars will complete an informational questionnaire.  This information will be confirmed by both the experienced Registry Advantage migration engineer and the registrar.  If desired, Registry Advantage can dispatch a representative to work with the registrar to gather this information.  It is critical that this data is accurate, as it will drive the rest of the process.  Some of the information collected during this phase includes:

• Existing database type and schema
• Current method for partners, registrars and their registrants interface with the registry (e.g. email, API, CGI) 
• Registrar processes (e.g. batch generation of zone files, real time updates)

Data Transfer and Migration Plan

After the Current State Analysis has been completed and confirmed by the registrar, Registry Advantage will develop a proposed data transfer plan.  The plan will include detailed activities, responsibilities and a schedule.  The finalization of the plan is an iterative process between Registry Advantage and the partner.  When it is completed and approved by all parties the Training and Execution phases are initiated.  By the end of the planning phase, Registry Advantage will have a thorough understanding of how information will be migrated from the partner’s database as well as how the translation layer must be modeled to handle current registry transactions.

Training

Registrar training is critical to the successful launch of the registry and begins early.  The training program is comprehensive and includes contingency situations as well as escalation paths if problems exist.

Execution

The actual work as detailed in the Data Transfer Migration Plan occurs in the execution phase of the implementation.  Any deviations from the plan are confirmed with the registrar via email to ensure there is adequate communication.  To minimize any potential issues, all ‘go live’ events are performed off hours with documented roll back procedures in the event there are problems.  At the end of this phase, the registrar and Registry Advantage are operating in parallel.

Parallel Operation

During this phase, data reconciliation is performed as frequently as possible to ensure that the information in the Registry Advantage systems is accurate.  Parallel operation is ‘one way’ in that the authoritative data source is still the registrar’s system and data is pushed to Registry Advantage.  This will ensure registration accuracy before the final cutover occurs.  Any problems that are noted during this period are corrected as required.  At the end of this phase, Registry Advantage will provide the registrar with the results of its data reconciliation as well as a listing of issues and resolutions that occurred.  During the parallel operation phase, registrars and registrants will continue to use their existing method of registry interaction.

Final Cutover

At this point, the Registry Advantage highly available, scalable and real time registry infrastructure becomes the authoritative data source for the partner.  Transactions (new registrations, name server changes, etc.) are being handled by Registry Advantage.  The registrar is fully trained and has confirmed that it is ready for the cutover.  If possible, registrars will begin using the new API to interface with Registry Advantage.  The timing of the final cutover is flexible.

Case Study

A case study is presented below to provide an illustrative example of the processes that Registry Advantage has employed for previous migrations.  This case study relates to the successful migration of a country code top level domain name from a legacy registry system to the Registry Advantage infrastructure.  In order to protect the confidentiality of the registry described in the case studies, the specific registry name is not provided.  The name of the registry, as well as the names of other registries that have been successfully migrated to the Registry Advantage systems, may be submitted to ICANN upon request.

This registry had a significant number of existing names and an ongoing registration volume.  As a result, it was necessary for the migration process to be concluded with no downtime of any critical system and no disruption of the registration process.  Registration and zone data was merged from multiple sources, including an Access database, BIND zone files, and e-mail templates.  This data was compiled into a staging database where it was reconciled against the live registry’s zone files and registration data through both automated and manual processes.

Upon completion of the data import and reconciliation, Registry Advantage began operating in a parallel operations mode.  In this mode, all registration requests were processed both by the legacy registry and by the Registry Advantage system. Prior to moving to the Registry Advantage system, the legacy registry used e-mail templates for all registrations, modifications and deletions of domain names.  In order for a successful migration to occur, it was necessary for the Registry Advantage system to support registrations via both e-mail templates and the shared registration system.  During the parallel operations mode, the shared registration system was disabled because the legacy registry did not support a real-time update mechanism.  During the parallel operations period, zone files and registration data were compared on a daily basis in order to ensure that the Registry Advantage systems were processing requests according to the policies and procedures of the registry.

Once both Registry Advantage and the registry administrator were satisfied that the data had been correctly imported, Registry Advantage began to produce zone files that were loaded by the legacy name servers.  Initially, zone files were manually copied to the name servers and inspected; in later phases, the zone data was propagated via an AXFR-based zone transfer mechanism.  Finally, Registry Advantage activated the shared registration system.  At this point, the Registry Advantage system was considered to be authoritative and the legacy registration system no longer attempted to mirror registration data.

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

The transition of a large scale registry can be judged to be successful if it results in:

• No disruption of the domain name system.  First and foremost, existing names within the .org top level domain name continue to operate throughout the transition period.  This continuity is essential to the ongoing stability of the Internet, and is important in fulfilling the expectations of both existing .org registrants and the general Internet community attempting to access .org domain names.
• No data loss.  The transition cannot be deemed successful if any significant amount of data is lost or becomes corrupt within the new registry.
• Minimal disruption of the shared registration service.  In order to ensure no conflicts in registrations accepted by the DotOrg Foundation versus existing registrations, it is crucially important that the final data set from VeriSign be carefully reconciled against the newly activated registry database.  As a result, some interruption of the shared registration service is required, but this disruption should be held to the minimum, preferably less than ten days.
• Minimal disruption of the Whois service.  In order to ensure that all data is successfully migrated from VeriSign into the new registry’s Whois database, a short interruption of service is required.  This interruption of service would occur between the termination of service by VeriSign and the conclusion of the data import and initial reconciliation of Whois data by Registry Advantage.  The transition should be judged to be successful if this disruption is less than 24 hours.
• Timely and informative communications with registrars.  The timing of the notifications will be agreed with ICANN, and is anticipated to be approximately fifteen (15) days before any significant step in the transition.  In some limited circumstances, unexpected events may occur which affect the technical operations of the registry during the transition.  In these situations, DotOrg Foundation may be required to make rapid alterations to the transition plan, but in no case will any significant step be altered without at least 24 hours notice to registrars.  A smooth transition will also depend on timely notification to .org registrants and members of the Internet community who may seek to make use of .org domain names.  Therefore, the DotOrg Foundation will post information regarding the transition plan on its website, so that it may be accessed by any interested party on a 24/7 basis.