RegisterOrg agrees that the continued stability of the global domain name system and the .org TLD is of paramount importance. Stability is particularly vital throughout the transition period from the current management structure into the new .org structure. RegisterOrg’s subcontractor, 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 this stability by following consistent and expected polices, accompanied by timely notifications. Following are registry commitments:

1. 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.

2. Posting information about the new .org operator on www.registerorganization.com.

3. Taking recommendations from RegisterOrg, its Directors and Advisors regarding the .org domain.

4. 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 RegisterOrg’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 RegisterOrg signing the registry agreement no later than November 1, 2002.

I. Contract Negotiation
In the event ICANN selects RegisterOrg as the successor registry operator, two activities will begin immediately. First, RegisterOrg 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.

II. Preparation and Outreach
Once the contract with ICANN has been signed, RegisterOrg 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 RegisterOrg. 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.

III. 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 subdomains within the registerorganization.org top-level domain name. For example, the Whois server may use a domain name such as testwhois.registerorganization.org, and the zone file may be rooted in a subdomain such as testzone.registerorganization.org. In such a case, an imported name such as example.org would be available for testing purposes as example.testzone.registerorganization.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 RegisterOrg, bulk access to the Whois and zone file data will be provided. Accredited registrars who have entered into agreements with RegisterOrg 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 RegisterOrg’s agreements with the participating registrars, RegisterOrg will consult with ICANN on amending the registry-registrar agreements.

IV. 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 their 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 of the 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.

V. 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, RegisterOrg 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, the Registry 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.registerorganization.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 subdomain used throughout the migration process. The operation of this subdomain was described in C18.1.

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 RegisterOrg.

Once data has been made available to registrars and to the Internet community through each of these mechanisms, RegisterOrg 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.

VI. 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.

VII. 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 C18.1 above, RegisterOrg will begin providing shared registry system (SRS) services. These services will allow registrars to register new names, modify existing registrations, renew and delete domain names. The initial plan is to begin SRS operations on January 8, 2003; however, RegisterOrg 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 in order 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 C18.2.

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.

VIII. 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, RegisterOrg 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, RegisterOrg 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.

A summary of the major events of the transition process is provided in the chart below:

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, RegisterOrg 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.

RegisterOrg 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; and
· 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 Rregistry 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 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, RegisterOrg 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 RegisterOrg 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 RegisterOrg 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 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, RegisterOrg 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 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.

Whois Service: 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 C18.1, but becomes live within 15 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 15 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, RegisterOrg 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 RegisterOrg 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, RegisterOrg 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, RegisterOrg 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, RegisterOrg would continue to make use of VeriSign’s DNS constellation until such time as at least six RegisterOrg 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, RegisterOrg 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, RegisterOrg 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), RegisterOrg 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 RegisterOrg’s satisfaction, RegisterOrg 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.

Contract Negotiations: The finalization of the registry contract with ICANN is an important element in RegisterOrg’s transition timeline. Several other major milestones in the transition plan depend on the successful signing of the contract by November 1, 2002. Fortunately, RegisterOrg does not expect a lengthy contract negotiation process. Unlike the recent creation of new gTLDs, the model registry contract has already been posted by ICANN prior to the selection of the new registry operator. By adopting many of the policies of the existing .org registry, RegisterOrg, with the assistance of its outside counsel, expects to streamline the contract process considerably. Finally, RegisterOrg is proposing no new services, minimizing the scope of the negotiations to the well-understood services that VeriSign provides today.

In the unlikely event that contract negotiations take longer than expected, RegisterOrg has the following contingency options available:
· Provide registry toolkits on an open-source basis to any interested parties, and limited access to the TEST systems as a general testing environment without the requirement of a registry registrar contract. This would allow registrars to prepare for the transition while negotiations were being finalized. This approach would allow up to an additional month of contract negotiations without jeopardizing other major milestones in the transition process.
· Shorten the amount of time during which data imports are accepted and validated from VeriSign. This option would provide registrars, registrants and the Internet community less time to scrutinize the new registry’s database, so in such a case it may be desirable to lengthen the post-cutover reconciliation period.
· Begin performing sample data imports based on public VeriSign zone file and Bulk Whois data, rather than from direct database transfer from VeriSign. These alternate data sources would not provide the same level of completeness or authority as the direct data transfer, but would allow for initial testing of RegisterOrg’s systems as well as an inspection of the migrated data.

As a last resort, and only under the most exceptional of circumstances, RegisterOrg would work with both ICANN and VeriSign to create a contingency plan that would ensure the stability and ongoing operation of the .org registry.

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; and
· 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.

RegisterOrg 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 RegisterOrg 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 RegisterOrg, or its sub-contractor, Registry Advantage. Zone file data should be made available to the registry each time that it 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 their database so that information could be extracted in real-time. Regardless of the specific mechanisms established above, VeriSign must provide RegisterOrg 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 timing of the process is 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 transition. While other services, such as the SRS, move over to RegisterOrg, the continued operation of the VeriSign DNS constellation will ensure that no disruption of the DNS service occurs. Once RegisterOrg 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 RegisterOrg.

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 RegisterOrg). 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 ccTLD 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 our highly scalable and functionally robust 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.

The attachment in Section XI, Migration Process, contains example documents that Registry Advantage submits 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
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); and
· 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, Register.com 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 Register.com 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, Register.com 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 transition 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 registry 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 they are 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 RegisterOrg 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, RegisterOrg 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, RegisterOrg 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.