Transition Plan
The technical transition from the VeriSign Registry ("Verisign") to Public Interest Registry ("PIR") will involve a multi-step procedure, outlined in detail below.
1. Technical Transition – Verisign Registry to PIR Registry
1.1: Conversion Data Specification
The data required for the transition will be detailed to VeriSign, and will include, but not be limited to, thin-registry WHOIS information currently held by by VeriSign, the gTLD zone file for .ORG, and registrar information relating to the operation of the registry (registrar ID mappings, for example). All data currently maintained by registrars will not need to be loaded into the system. Domain names and associated child entities will be converted real-time, as registrars move to the EPP-based system.
The registry data should be formatted in a common symbol delimited text file, with the first row containing appropriate column headers. The gTLD zone file can be sent in the current text format. If these formats are determined to be insufficient, an alternative format shall be negotiated between PIR and VeriSign, as long as this negotiation does not prolong the process of receiving the data. This data will be formally requested no more than three days following the signing of the .ORG Registry Agreement.
1.2: Form Registrar Transition Focus Group (RTFG)
PIR will immediately begin selecting and contacting registrars to formulate the Registrar Transition Focus Group. The mission of this group is: 1) to provide input from a registrar's perspective on the transition, 2) to provide a level of testing to ensure that the software works as documented, and 3) to ensure client software can be successfully transitioned in a timely basis.
1.3: Receive full set of test data from VeriSign
No later than 10 days after the request in 1.1 of this Appendix J has been issued, PIR expects to receive, in the common symbol-delimited form decided upon, the complete set of data to be used, solely for the purposes of testing the transition. PIR shall request Verisign to estimate a time for the retrieval and transmission of the data set, so that appropriate time can be allocated during the cutover process.
1.4: Conversion to test environment
Upon arrival of the test data, PIR will begin testing the conversion process, and load this data into a test environment to be accessed by both PIR developers as well as the RTFG. The conversion data will be segmented into two files: one considered a "full" data dump, and the second considered an "incremental" data dump.
The conversion process will involve first loading the "full" data dump, and subsequently processing the incremental dumps. Collectively, this is referred to as the "conversion process." This step is expected to be completed no later than 21 days after the data has been received.
1.5: Confirm readiness of VeriSign DNS API
PIR intends to utilize VeriSign's name servers during the transition period. This is contingent upon VeriSign having a mechanism on its side of the transfer. PIR expects to have access to a test API system no later than 7 days after the contract is signed. An API test area will also be expected from Verisign, which will generate a zone file based on the data sent in through the API. (Alternatively, PIR will be able to provide zone files based on a specification agreed with VeriSign.)
1.6: Begin internal testing and provide Test Arena ("Sandbox")
Once the data has been successfully loaded into the test arena, PIR and the RTFG will be allowed to conduct tests on the data to verify registry operations. PIR's initial testing will be conducted using a standard test suite that has already been built by PIR's back-end services provider for the purposes of verifying registry operations. The initial test suite will include at least the following areas:
1. RRP transaction processing
2. Zone File propagation and accuracy (including utilization of the VeriSign API and test area for zone file transfer - as soon as it is available)
3. Proper WHOIS data propagation and accuracy - for both RRP and EPP domains
4. PIR shall provide a test arena ("Sandbox") for all registrars to begin testing their client code. Registrars shall be provided separate methods of authentication in order to access this Sandbox.
This test phase will begin as soon as the data has been loaded into the test arena.
1.7: Implement changes from Focus Group and Internal Testing
During the testing phase, problems that are found within the registry system will be documented, ticketed into the bug tracking system, and resolved in a timely manner. As problems are resolved, fixes will be introduced back into the system using the same Quality Assurance procedure that PIR's back-end services provider uses in its current production environment. While many problems will be resolved during the initial testing phase, there may be issues that require an extensive change.
1.8: Reload VeriSign test data and re-run test suite
Once it is believed that all fixes are in place from the previous steps, PIR will re-run the data conversion process, and the test suite. The RTFG will be encouraged to conduct testing on their end to verify the results. It is expected that this will take no more than 7 days.
1.9: Begin Data Migration to production-ready system
Once system operations have been verified, VeriSign will need to provide another full set of data, identical in format and nature as the data provided in 1.1 of this Appendix J. This data will be loaded into the production-ready system using the conversion program, and data will be checked for accuracy. No transform commands will be allowed on this data. This full data dump is expected to occur at least 30 days before the cutover date. An incremental dump will then be expected at regular intervals before the cutover, and the incremental conversions will occur. All data will be checked for accuracy.
1.10: Shut down VeriSign RRP system
At the time of the cutover, VeriSign will shut down their RRP system. This assures that PIR has a complete set of data when PIR's registry goes live. VeriSign's WHOIS service, as well as the gTLD name servers, will remain operational throughout the cutover.
1.11: Receive last incremental dump from VeriSign
Immediately after the RRP shutdown, VeriSign will be expected to run the last incremental dump of the data, generate a zone file, and send this to PIR as quickly as possible, using the same methodology as described in previous steps. Utilizing incremental dumps will help minimize the downtime required in this process.
1.12: Run last incremental conversion into production system
Upon receiving the data, PIR will immediately load the data using the incremental conversion process. The data will then be verified for accuracy and completeness, using the same mechanisms that were utilized in the testing environments.
1.13: Bring up VeriSign nameserver API
VeriSign will need to back up the current zone file, and bring up the mechanism to allow PIR's zone file to be transferred to the VeriSign name servers. Once this mechanism is running, PIR will initiate a push to the name servers, and verify that all operations are running correctly.
1.14: Bring up RRP/EPP proxy system
Once all data and the name server functionality have been verified, PIR will bring up the RPP/EPP proxy system. All operations will be carefully monitored throughout this process, to ensure that all registry operations are functioning correctly.
1.15. WHOIS Services
WHOIS services will be provided in the thin model for all .ORG names operating under RRP, for which the central .ORG WHOIS server will provide referrals to the authoritative WHOIS servers.
2. Technical Transition – Post cut-over
2.1: Registrars begin EPP migration
Registrars will begin the migration from RRP to EPP in early 2003. Each registrar will be given a commercially feasible timeframe to cutover to the EPP protocol. The EPP migration process will commence in early 2003, and shall conclude no later than December 31, 2003.
2.2: WHOIS Services (thin to thick registry)
As part of the EPP migration, Registrars shall be required to provide full contact information required for thick registry WHOIS services. Thick registry WHOIS services will be provided for each .ORG name that has been migrated to EPP.
2.3: Test UltraDNS API and name server functionality
Once the cutover is completed, PIR will begin testing the transfer procedure to UltraDNS. The testing will be conducted in a similar manner as was done with the VeriSign API.
2.4: Run Parallel name servers
For a period of 30 days, PIR will send zone file data to both VeriSign and UltraDNS name servers. The UltraDNS servers will be checked for accuracy and completeness.
2.5: ICANN to switch name server delegation
Once the accuracy of the UltraDNS zone file propagation has been successfully completed, PIR will request ICANN to switch the name servers from VeriSign to UltraDNS.
2.6: VeriSign to remove PIR connectivity to their name servers
As part of the contingency outlined below, it is expected that VeriSign will keep the connectivity to the nameservers alive until 30 days after the delegation change. This step would complete the transition.
2.7: RRP and EPP co-existence
The registry will be pre-loaded with all relevant RRP data from VeriSign. If a registrar connects to the registry using RRP, it will be able to manipulate the data in the same manner as it does today through VeriSign. If the registrar connects via EPP, it will need to modify the domain name to include/update all required fields for that entity and its children (contact ROIDS, etc.). This modification step will be included in the OT&E process.
2.8: Registrar data migration to thick model
PIR will encourage registrars to migrate their data from the thin to thick registry model. This encouragement will include, but is not limited to, a weekly report showing all domains still under the thin model, full technical support and OT&E testing facilities, and notifications by PIR to migrate the data in a timely fashion.
PIR will discontinue operation of the RRP/EPP proxy software on January 1, 2004. As a result, Registrars are required to complete migration to the EPP system prior to December 31, 2003, or risk being disconnected and unable to access the Registry system.
Once all registrars have made the transition to EPP, the RRP-to-EPP proxy will be shut down, and all registry operations from that point forward will be transacted using EPP.
3. Technical Transition – Interruption of Registry Functions
PIR's transition plan aims to minimize any interruption to critical services during and after the cutover of the Registry. Because the cutover only involves the shutdown of the RRP service from VeriSign, PIR expects no interruption of service for the key end-user components of name resolution and WHOIS services.
By using the incremental dump methodology described above, PIR will minimize the amount of down time that will occur during the cutover process. This will only impact registrars' ability to transform existing registry-related information, such as name servers delegated to a particular domain, as the registry data will not be accessible during this time. All data maintained by the registrar, in their own WHOIS databases, will not be affected. The cutover process is expected to last for at least 48 hours. Once the cutover has been completed, no further interruption of service is expected.
4. Technical Transition – Contingency Plans
PIR shall create contingency plans in the event that any part of the proposed transition does not proceed as planned. Listed below are the minimal steps that shall be undertaken by PIR to ensure that the transition of the registry results in minimal disruption of service to registrars, and no disruption of service to existing .ORG registrants.
Each step in the transition is outlined below, with each step's risk assessment and contingency plan is detailed. This is for illustrative purposes only, and the Registry Operator reserves the right to make modifications to details of the Transition Plan, and the Contingency Plan(s) in order to ensure that the stability and security of the .ORG registry is not compromised.
4.1: Conversion Data Specification Contingency
In the event that VeriSign cannot supply the data in the format suggested in 1.1 of this Appendix J, PIR will work with VeriSign to establish a format that will be mutually acceptable. Both companies have the necessary technical knowledge to agree to a format in a short time frame.
4.2: Registrar Transition Focus Group (RTFG) Contingency
PIR's back-end registry services operator, has prior experience in establishing registrar groups similar to the RTFG during its LandRush 2 process. PIR will seek out alternate registrars or similarly technically competent organizations to participate in the RTFG.
4.3: Full set of test data from VeriSign Contingency
PIR will depend on VeriSign to be able to deliver data in a timely fashion to Registry Operator for the purposes of load testing the conversion process. If, however, VeriSign cannot deliver this data in time for the initial testing to commence, Registry Operator will generate a set of test data. This data is anticipated to be a representative model, but presents risk as it may only be an approximation of expected data to be later delivered from Versign.
4.4: Conversion to test environment Contingency
If problems are found within the test data, then the Registry Operator's development team will work with VeriSign to correct the problem and have the data set regenerated. The purpose of this step is to check for errors in both the data set and the conversion code, so some errors and their appropriate fixes are expected. The largest risk in this step is the indication of an unexpected amount of errors in the conversion code, which could potentially increase the time needed for this step.
4.5: Internal testing Contingency
Internal testing will begin once the data set has been loaded successfully. The RTFG testing will be available after the preliminary internal testing has concluded.
4.6: Reload VeriSign test data and re-run test suite – Contingency
The procedures for loading all data will have been fully tested at this point. If, after fixing any problems incurred in the previous steps, the data fails to load, the conversion process will be altered to correct the problem. The time allotment for this step allows for this iteration to occur.
4.7: Data Migration to production-ready system Contingency
At this point in the transition, the data load will have been tested numerous times. The risk factors here include a problem with VeriSign providing the production data, or an unforeseen error in the conversion code - both of which are unlikely at this point. If however, such an error occurs, PIR will work expeditiously with VeriSign to resolve this issue as quickly as possible. This step can occur anytime within the month prior to the cutover. While some time has been allocated for this step in the event of a problem, in the event of an unavoidable problem beyond the control of the Registry Operator, the Registry Operator will take necessary emergency steps to mitigate the risk of destabilizing the .ORG registry.
4.8: Shut down VeriSign RRP system - Contingency
The principal potential risk here is having other registry services affected by the closure of the RRP system at VeriSign. It is assumed that VeriSign has run the production system many times in this scenario. In the extremely unlikely event that either DNS or WHOIS services are affected adversely by the RRP shutdown, the cutover will be delayed until the problem can be resolved. VeriSign will be asked to provide, in writing and in advance of the cutover, a statement verifying that the RRP system can indeed be shutdown in this manner. In the event of a catastrophic failure at this point, the conversion will be aborted, and VerSign can re-open their RRP system.
4.9: Receive last incremental dump from VeriSign - Contingency
The major risk in this step is timing. It is currently not known how long it will take VeriSign to retrieve and send the incremental data set to PIR. The RRP downtime will be extended at this point if this step should take longer than anticipated. In the event of a catastrophic failure at this point, the conversion will be aborted, and VerSign can re-open their RRP system.
4.10: Run last incremental conversion into production system - Contingency
At this point in the transition, it will be known how long it takes to run an incremental conversion. – As many as five incremental conversions will have been performed to this point. In the event of a catastrophic failure at this point, the conversion will be aborted, and Versign can re-open their RRP system.
4.11: Bring up VeriSign nameserver API - Contingency
If an unforeseen issue should arise, and the registry is unable to communicate to VeriSign's name servers, attempts will be made to correct the issue. Should this prove to be an overwhelming task, the conversion will be aborted, and VeriSign can re-open their RRP system.
4.12: Bring up RRP/EPP proxy system - Contingency
If the registry system fails to come up, or unable to perform all registry services as expected, attempts will be made to correct the issue. If, however, it is determined that a problem exists that cannot be resolved in a timely manner, the system will be brought down, and VeriSign can re-open their RRP system.
4.13: Registrar EPP Migration - Contingency
PIR will handle each registrar's EPP Migration process. The RRP to EPP proxy allows registrars to continue to perform domain functions while preparing their systems for the change. In the event that a registrar has problems moving to the EPP system, they can continue to operate using RRP until the proper corrections have been made. Registry Operator shall provide necessary technical assistance (including debugging assistance) to help ensure that Registrars complete the migration to EPP successfully.
4.14: UltraDNS API and name server functionality - Contingency
The UltraDNS API is well documented, and the changes required to switch to the new name servers should be minimal. This coupled with the extended time frame allowed makes the risk factor low.
In the event that a serious problem should occur, PIR shall utilize VeriSign's name servers for the duration of the 12 months as provided for by the current contractual requirements from VeriSign.
4.15: VeriSign to remove PIR connectivity to their name servers - Contingency
Once the registry is running on the new name servers, PIR will no longer attempt any connectivity whatsoever to the VeriSign name servers. VeriSign can bring down this service on its own time-frame.
4.16: PostgreSQL database is orphaned
Because of the open source nature of PostgreSQL, the software code base does not suffer the same inherent business issues that one would see in a commercial package. Specifically, there is no underlying concern regarding the company's financial health; the code being bought out and obfuscated by a competitor; corporate espionage; etc. These kinds of risks do not affect open source products such as PostgreSQL.
Although "orphaning" by a corporate parent does not apply, there are two different scenarios where support could falter for the use of PostgreSQL. The first is a radical shift in database theory, and the related implementations, and the second is lethargy within the development community.
The first issue deals with the adoption of new database theories and technologies. In this regard, PostgreSQL excels. PostgreSQL did not originally have SQL built in. However, as the SQL standards progressed, it was incorporated into the system, and is now one of the most fully compliant SQL implementations. The adoption of new database technologies has occurred many times within the lifecycles of PostgreSQL. As new ideas develop within the database community, PostgreSQL has developed a reputation for implementing these new ideas in a timely fashion.
The second issue deals with the notion that programmers will migrate to a totally new project, and work on PostgreSQL will slow to a minimum. Given PostgreSQL's history with adaptation to standards and new technologies, as well as a sixteen-year development history, it is difficult to envision that this would occur.
Open-source data conversion utilities for PostgreSQL exist, whose explicit purpose is to facilitate the migration of data to and from PostgreSQL. As a direct result, PIR's ability to convert the data contained in its database is made significantly easier, should the need occur.
Assuming, however, that an unforeseen issue would occur which would cause PostgreSQL to no longer be maintained in an appropriate fashion, PIR would begin the migration to another database subsystem. PostgreSQL, by virtue of its conformance to industry standards, would ease the burden of migration. Overall, the degree of difficulty in migrating the data to another database system is finite and measurable. Data migration can be performed with the skill sets that Registry Operator's back-end services provider has already built in-house, as well from the PostgreSQL community.
Each RDBMS contains significant architectural differences, which must be accommodated in any data migration. Since PostgreSQL is accessible in an open and cross-platform manner via both ODBC and JDBC, a consistent application programming interface (API) is available that works with different databases through the use of database-specific drivers.
A consistent API results in function calls to perform important database actions such as initiating a connection, executing a command, and retrieving results that are identical regardless of whether the program is talking to PostgreSQL or another ODBC/JDBC compliant database. Additionally, a standardized call-level interface and standard escape sequences allow the data migration developer to specify SQL functions that perform common tasks but are executed differently in the two database systems.
The data migration process (as differentiated from a registry transition process, which includes data migration) needs to take into account several important considerations. The data migration process must identify differences and determine methods of resolving such differences and create a uniform mapping for critical tasks and functions, such as:
- Physical and Logical Storage Structures
- Data access methods across RAID or non-RAID devices
- Access to transaction logs and automated recovery methods
- Ability to perform various backup methods, including full and differential backups, as well as snapshots
- File encryption methods
- Network security access and specialized database functions
- Groups, roles and permissions, and migration of roles between databases
- Common definition and/or mapping of database objects
- Object names and identifier differences
- Qualifying table names
- Syntax for table creation, index and storage parameters
- SQL syntax mapping for important functions, such as views and queries
- Use of Unicode data
- Enforcing Data Integrity and Business Rules, including constraints
- Identifying differences and mapping functionality for transactions, locking and concurrency
- Methods of handling deadlocks
- Conversion of values to different data types
- Conversion of user-defined functions, stored procedures and special calls
- Raising program errors, common error processing methods and debug systems
Should PIR need to migrate data from its current database to a new database, the planned migration strategy would adhere to the following guidelines:
14.16.1 Determine a suitable successor database. This would involve testing various database systems within our environment, to see how each performs under the registry's normal and peak load conditions.
14.16.2 Once the successor database has been selected, the software will be procured (if not open source), installed, and appropriately configured into our test environments (see ISOC .ORG proposal, C 17-13.2-4).
14.16.3 A new set of database servers would be procured. These new servers would need to be configured and installed.
14.16.4 A data export / import procedure will be built in parallel with the development efforts in Step 4.
14.16.5 All pertinent API DB calls would be modified within the registry software (if necessary).
14.16.6 Queries would be re-analyzed to ensure that they are still optimized using the new system.
14.16.7 Once all software has been unit tested, the entire system will undergo an exhaustive test phase.
14.16.8 Any revisions that are derived from the test suites will be worked out.
14.16.9 The database would be loaded onto the procured servers, and a database export / import would be performed. No shutdown would need to occur for this step. The data would be exhaustively checked for any errors, and additional export / imports run to correct any mistakes.
14.16.10 The registry will be shutdown, the new database systems installed, an incremental export / import run, the data examined, and brought back up.
5. Technical Transition – Cooperation from VeriSign Registry
As the current operator of the .ORG registry, VeriSign must play an integral part of the transition process. To successfully transition the registry, PIR requires at least the following information and services from VeriSign:
5.1 An initial production data dump.
This includes the ability to provide both a full data set (including the corresponding zone file), and incremental sets that contain only changes from the original full data set. This will be needed for both the testing phase, as well as the production cutover. VeriSign should also provide approximate timeframes when these data sets will be available, in order to accurately gauge the cutover time.
5.2 Authorization to use the VeriSign nameservers for a period of up to 12 months.
PIR's transition plan calls for use of VeriSign's nameservers for the first 180 days after the cutover, but may be required for the entire 12 months as part of the contingency plan.
5.3 Written confirmation from VeriSign that VeriSign Registry's Whois and DNS services will not be interrupted when the VeriSign RRP system is stopped during the cutover.
5.4 VeriSign will need to provide and coordinate appropriate Application Programming Interfaces (APIs) into their name servers within 7 days of the signing of the .ORG contract.
5.5 PIR also requests an environment setup at VeriSign to test the DNS API mechanism within 10 days of the signing of the .ORG contract.
5.6 Extensive, timely coordination between PIR and VeriSign shall be required throughout the transition, with complete coverage during the cutover process. VeriSign shall take commercially reasonable steps to ensure that such coordination is provided in a timely manner.
5.7 In order to provide continuity of service to registrars and registrants, PIR will need VeriSign's cooperation (and relevant data) regarding the other areas of .ORG registry operation that VeriSign is currently responsible for. These areas include (but are not limited to) customer service, policy, technical, legal, and arbitration information. Examples include open .ORG trouble tickets, information regarding ongoing .ORG domain disputes, information regarding services the VeriSign registry currently offers to .ORG registrants and registrars, etc.
6. Operational Test & Evaluation (OT & E)
Before ICANN-Accredited Registrars will be allowed to join the live registration environment, they must first pass Operational Test and Evaluation ("OT&E") certification.
The OT&E process has two main objectives:
1. Verifying the correct operation of an ICANN-Accredited Registrar's client system, and the ICANN-Accredited Registrar's capability to operate the interface with the Registry; and
2. Establishing the contractual and business relationship between the ICANN-Accredited Registrar and the Registry, in accordance with the Registry-Registrar Agreement.
The OT&E certification process will be available to all ICANN-Accredited Registrars starting from the date described in Section 7 below.
6.1: Phase 1 - OT&E for cutover to new Registry Operator
All ICANN-Accredited Registrars who wish to perform transactions in the .ORG domain will have to make necessary technical and other modifications to their systems and processes to ensure that they connect to the PIR registry systems, and that these systems are able to execute RRP-based domain name transaction commands without any loss of functionality.
All ICANN-Accredited Registrars will be required to pass certain tests to be eligible to go live prior to the January 1, 2003 cutover of the registry. All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certification results in a timely manner and provide feedback for those ICANN-Accredited Registrars that failed to successfully complete the tests. ICANN-Accredited Registrars may correct their systems and re-schedule for certification. ICANN-Accredited Registrars will not be limited in the number of attempts at OT&E certification. Upon successful OT&E certification, the ICANN-Accredited Registrar becomes eligible for operation in the live registration environment. For specific technical details see Section 7 of Appendix C to the Registry Agreement.
6.2: Phase 2 - OT&E for RRP (thin) to EPP (thick) conversion
Since PIR will operate a central, authoritative registry database that operates on the EPP protocol, all ICANN-Accredited Registrars who wish to perform transactions in the .ORG domain will have to make necessary technical and other modifications to their systems and processes to ensure that they connect to the PIR registry systems, and that these systems are able to perform required transactions in the EPP protocol with Registry Systems. In addition, since PIR will operate the EPP registry under the "thick" provision (centralized information repository), all registrars will have to make the necessary technical and other modifications to their systems and processes to ensure that they can successfully and completely transfer necessary contact information from their systems to PIR.
All ICANN-Accredited Registrars will be required to pass certain tests to be eligible to go live prior to the January 1, 2003 cutover of the registry. All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certification results in a timely manner and provide feedback for those ICANN-Accredited Registrars that failed to successfully complete the tests. ICANN-Accredited Registrars may correct their systems and re-schedule for certification. ICANN-Accredited Registrars will not be limited in the number of attempts at OT&E certification. Upon successful OT&E certification, the ICANN-Accredited Registrar becomes eligible for operation in the thick-EPP registration environment. For specific technical details see Section 7 of Appendix C to the Registry Agreement.
7. Thin registry Data Escrow
For the duration when the Registry Operator allows registrars to operate under the RRP protocol, the Registry Operator shall encapsulate all Registry data in an electronic format mutually agreed upon by PIR and ICANN, and store in escrow with Data Escrow Provider. Data Escrow Provider will verify that the data is complete, accurate, and delivered in the intended format using scripts provided by PIR.
Until the completion of the RRP to EPP transition as defined in Section 2 above, the Registry Operator shall store in escrow all data in the formats and methods as specified in Appendix R. Domain names shall be marked with a flag to indicate whether the name is stored in the registry in RRP or EPP state, and all information stored in the escrow will accordingly reflect thin registry or thick registry characteristics.
The thin registry Data Escrow shall follow the same schedule, data format (extended as needed, example provided above), transfer process and verification procedures as defined in Appendix R.
8. Public Notification Mechanisms
Registry Operator will work in conjunction with ICANN, the registrars constituency and the Internet community at large to maximize the notification process by using a multitude of mechanisms including: the Registry Operator web site, a transition web site, email announcements; registrar communiqués; press releases, and other methods.
Announcements regarding the timing of various Transition Plan events including commencement of OT&E Phase 1 and Phase 2, RRP (thin) to EPP (thick) data migration and commencement and conclusion of the RRP/EPP proxy will, at a minimum, be available on the Registry Operator's web site and on the transition web site.
9. Disclaimer of Warranties
REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SUBCONTRACTORS, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.
Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated 24-Oct-2002
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.
|
