Main Page | Proposal Home
Jump to question:
C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | C9 | C10 | C11 | C12 | C13 | C14 | C15 | C16 | C17 | C18 | C19 | C20 | C21 | C22 | C23 | C24 | C25 | C26 | C27 | C28 | C29 | C30 | C31 | C32 | C33 | C34 | C35 | C36 | C37 | C38 | C39 | C40 | C41 | C42
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:
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:
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
II. Preparation and Outreach
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:
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 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.
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
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
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
A summary of the major events of the transition process is provided in the chart below:
Thin to Thick
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:
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:
The thin to thick migration process is described in more detail, including proposed dates for each of these phases, in C22.
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.
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:
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:
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:
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:
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.
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:
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.
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.
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:
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.
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.
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.
The transition of a large scale registry can be judged to be successful if it results in:
[previous question] [next question]