Generic Top-Level Domain (gTLD) Registry Agreements
Proposed Unsponsored TLD Agreement: Appendix C, Part 11 (.name)
Part 11 - Registry Operations Site Locations The main site and The Disaster Recovery site will be located in Europe. Further information server sites providingWhois, DNS or a combination of the two services (henceforward termed "DNS sites") will be provided. Locations will be decided according to the following criteria: (a) Internet connectivity Furthermore, the Registry Operator will retain the power to decommission any DNS site deemed to be superfluous to continued operations of the .name registry with the proviso that at least five DNS servers will be available to the public at all times. Hosting Space Hosting space will provide for standard 19" equipment racks. A secure equipment loading area, accessible 24 hours a day, will be available at each site. There will be a secure, accessible route from this loading area to the server racks, also accessible 24 hours a day. Additional space for future needs will be available at the main site and disaster recovery site, should further equipment be required at these locations. Internet connectivity The main site and disaster recovery site will have multiple Internet links, each with a guaranteed Service Level Agreement. These Internet links will provide a minimum of 2 Mbps bandwidth. Power Each full rack or cabinet will be provided with 10 Amp, 220-240 Volt AC electrical power on two redundant power strips. Each of these power strips is to be conditioned to prevent any harmful voltage spikes. Electrical power is to be supplied via two independent circuits from the local power company. Backup power is to be supplied with fuel-powered generators which will be capable of providing operational power for a period of no less than 24 hours in duration. Environmental control Temperature and humidity are to be monitored constantly to ensure that both remain within operational limits for the server equipment, as mandated by the suppliers. Fire detection and alarm systems will be provided at all sites. Facility Staff Each site will have technical staff available at all times. Members of the Registry Operator's technical staff will be qualified to perform (a) server reset or "power cycling", (b) visual inspection, (c) equipment installation or replacement, (d) removable media exchange, (e) further instructions remotely provided by the Registry Operator's technical staff at other locations. Main Site Reporting All access to the room containing the servers at the main site will be recorded with time, date, purpose, name and authorization details. All environmental incidents including, but not limited to, fire alerts, unacceptable humidity or temperature levels, will be recorded with the time, date and outcome of each incident. Main Site Security Each site will implement physical security systems including, but not limited to, intrusion detection equipment in the form of passive infrared sensors, door sensors, and security card access control. 24-hour access to the site by authorized personnel will not be hindered by aforesaid security measures. Architecture
Specification The Registry Operator has chosen broadly proven hardware from widely known and acknowledged suppliers, such as IBM and Cisco. The Registry Operator has, together with IBM, chosen the equipment to fit Registry operation requirements, based on the assumptions made in the ICANN application. However, the Registry Operator cannot guarantee the correctness of assumptions or estimates. These specifications are therefore subject to change, should alterations be required for optimal functioning of the Registry. DNS, Whois and Registry may require extended processing power or storage space as the Registry increases in size. The specifications given herein are therefore estimated requirements; these systems may be upgraded as necessary to meet growing demand. Startup configuration of Front-end servers; Startup configuration of back-end servers; All servers in each site will be accessible from a console at the site that only operators have access to. Each machine has software or hardware components that can send specific messages about the current status on the server to a monitoring or messaging system. Hardware Reporting All abnormal status will be reported to the Operation Manager. All maintenance will be reported using a standard form and reported to the Operation Manager. Physical security The Registry Operator will employ a variety of physical security systems to ensure that unauthorized personnel have no access to sensitive equipment and/or data. First and foremost of the preventive measures is that all servers containing any sensitive data (which includes all registrar and registrant information, the registry itself, and all billing, sales and contact details) will be physically secured so that only a controlled list of people has any access to them. Secondly, the hosting centers themselves will be secured so that no access to the internal networks is possible for unauthorized persons. All internal networks are isolated from public access, and external internet links are firewall-protected to prevent intruders from gaining access. Thirdly, physical precautions inside the server rooms will include movement detectors (using infra-red or similar means) to alert security personnel should an intruder gain access to a secured location. Alarms will be fitted to all doors and windows which open into or out of a restricted area. These doors and windows will be secure enough to withstand a reasonable amount of force, and damage to doors or windows will also trigger the alarms. Security staff will be present at all times, and will have sufficient training to enable them to correct most problems themselves, or contact the most appropriate personnel and contain the situation in the meantime. Personnel on the access list to the server rooms in each hosting location will be issued an access card. Should an access card be lost or stolen, it is the responsibility of each employee to report this in a timely manner so that the lost card may be deactivated and a new card issued. CCTV will be in place at all sites for identification purposes should an unauthorized person attempt to use a stolen access card. Network security User identification, passwords and IP range checking will be required for all restricted services (which includes services other than DNS resolution, Whois queries and WWW service). FTP will use the standard name and password security, with FTP security extensions available as specified in RFC2228 (see FTP section in this appendix for more details). SCP will also utilize name and password pairs, but as noted in the SCP service section of this Appendix security details such as the password are not transmitted in cleartext, and all data is encrypted using a secret key which is negotiated during the connection process. Since the SCP service affords more security than basic FTP the Registry Operator recommends that all zone file access should use this method rather than FTP. System maintenance will be performed via SSH connections. Telnet servers will not be operational on any system on the DNS network, since these pose a security risk. Each system will operate a very restricted set of basic services, as outlined in the Common Modules section of this Appendix and in the relevant sections for DNS, Whois, FTP, SCP and WWW services. Most systems will be firewall-protected in hardware, and IP filtering rulesets will be in place to reject packets that are not appropriate for a particular host. Services which are IP-restricted will have each IP address specified individually. Network addresses are not to be used, since this adds the risk that a host could masquerade as a spare IP address on an internal network. Packet "sniffers", designed to check all network traffic passing through a network interface, will be in place to catch suspicious network traffic. These will actively scan for incorrect or illegal packets, and alert the security team through email. Packet sniffers may also give some indication of the source of an attack, which would be of use in preventing that attack in future. A close watch will be kept on relevant internet security mailing lists, such as bug-traq and CERT advisories, in addition to the usual vendor-specific lists. Any exploits mentioned on these lists will be guarded against if possible, and certain emergency procedures may come into play in this case. Bug fixes and patches will be tested on development systems first, and then applied to the production systems after a suitable time. Members of the technical team will closely follow the usual DNS mailings lists, such as the "dns-ops" list and the comp.os.protocols.dns hierarchy, partly to participate in discussions about the .name domain, and partly to track possible security risks in the DNS structure or software. Network security will be verified by a security audit process, which involves scanning, from an internet-connected host, of all TCP and UDP ports on all servers operated by the Registry Operator. This information will be used to generate a list of vulnerable ports on each server, and specific tests will be performed on each entry in this list, according to the type of service available on this port. Details of security tests performed on the .name services are confidential, and subject to change. Each test will attempt to take advantage of a security flaw using a specific attack method, and then return the result. Here is an incomplete list of known attacks:
Some of these attacks may not be appropriate to all services. Further information and implementation details are available from security-related websites such as http://www.securityfocus.com and http://www.insecure.org. The Registry Operator will update the tests used when new vulnerabilities, security flaws or techniques are discovered, based on information from the aforementioned security-related mailing lists, websites and newsgroups. Security Reports All security breaches are to be reported to the Security Manager. Should a serious breach be detected, some services may be suspended temporarily, if deemed necessary to ensure reliability of the Registry data. Since reports are a helpful tool for tracking down security breaches and can be the first indication when something does go wrong, all critical components of the system will have associated reports which monitor the essential operations of the system. These specific reports are described in detail in the relevant sections of this Appendix, but they do have some features in common. The Registry Operator will run the security audit on the first of each month to test all systems for configuration issues and security holes. The data integrity tests, port scanning and subsequent exploit testing will be logged in detail, and the results of this audit will then form the basis of a monthly security report, which will also detail any recommendations for system alterations. The security report will contain the following information:
Appendices to the security report will contain the scripts and code used in the port scanning, exploit testing and data integrity tests. If a security advisory is issued between reports, a supplementary report will be generated which will analyze the advisory, perform specific tests, and detail any changes required to configuration, software, system architecture and design, or security procedures. This supplementary report will not contain the first five sections (those dealing with portscanning and subsequent vulnerability testing) listed above, although they will include a data integrity test. All security reports will be kept for posterity. Database The database is duplicated on two different servers, and the data is stored on a storage system, running RAID5 (Redundant Array of Inexpensive Disks). RAID5 uses multiple disk drives to maximize data transfer rates. All transactions editing or updating the database will be logged and these logs will be sent to an external datacentre over an encrypted link. In case of breakdowns where the internal log is corrupted, the external log can be retrieved. Core Systems At the main site the important external services are designed with redundancy in mind. Registrar interface servers, web servers, DNS servers, WHOIS servers, email forwarding and database servers are twinned. In the event of a failure of one of these components, the service in question will remain operational while the failed component, or the server itself is replaced in a timely manner. The system can be restored at the disaster recovery site, located elsewhere, using backups and transaction logs. The disaster recovery site will be brought into use in the event of a serious failure where it is impossible to continue using the main site. Firewalls The firewall will be operating in a failover configuration in the main data center. This means that in the event that one firewall fails, the second will automatically take over while the fault is rectified or the original firewall is replaced. DNS servers on different backbones The DNS servers will be multiplied in failover systems, spread across different backbones and located in different parts of the world. Backups transported offsite There will always be a recent backup available on removable media which can be used in the event of a disaster to restore critical systems. The backup library copies any appropriate data, including but not limited to, Registry data, configurations and partitions of the servers in the center to removable media. The backups will be transported offsite periodically by a security firm dedicated to this service. The removable media will then be stored in magnetically shielded vaults away from the site.
The shared Registry system will consist of a number of different components performing different functions such as taking requests from the registrars, performing updates to the database and managing updates to the email forwarding, Whois and DNS servers. At each stage during a registration or request involving a Registrar a number of stages need to be passed before each transaction can be deemed complete. If there is a failure in one or more components in the system it must not compromise the integrity of the database or the validity of the email forwarding, DNS or Whois servers. Appropriate steps will be taken to ensure that any transaction will complete correctly or in the event of a problem allow the system to be restored to a correct state. Queuing Software Communication between the different components in the shared registry system will be performed by using a distributed asynchronous message based mechanism. Communication between different entities is achieved by the transmitting entity placing a message in a queue and completed at a later point by the receiving entity taking the message out of the queue. The entities will not necessarily need to reside on the same machine. The management of messages throughout the shared registry system will be administered by using queuing software designed for this type of communication. This software will ensure that data is not lost because of failures in the underlying system or network infrastructure and will also provide assured, once only delivery of messages. Processing is such that when messages are transmitted to a queue on another machine for instance, a confirmation of receipt is always obtained from the receiver before a particular message is deleted from storage by the sender. Because of this it will always be possible to know if a message has delivered or not, and act accordingly in the event of a failure. Sending a message is achieved by putting a message onto a predefined queue. The receiving process will take the message from this queue at a later point, when it is ready to do so. Error Detection If any error occurs while sending or receiving a message, the transaction is terminated, and error messages are sent to the appropriate system consoles. At each critical point during the lifetime of a transaction in the system, the details of the relevant operation will be written to a log. The logs can be used as part of normal operations to verify the data stored in the system. The logs will also be used in the event of a system failure as part of the process that restores the system to operation and also as a means to discover if there are errors in the shared registry system, email forwarding servers, DNS servers or Whois servers. Asynchronous Processing Each request, as it enters the shared registry system from a registrar, will be placed in a queue to be processed at a later point. The process that queues the requests is independent from the process that receives them. This asynchronous processing support in the queuing software means that the exchange of messages between the sending and receiving programs is time independent. Multi-stage process A request from a Registrar that will update the database, such as the registration of a domain will pass through a number of queues in the shared registry system before the request can be treated as complete. Firstly the new request will be placed on a queue. Another process will then take the request from this queue and carry out a sequence of instructions that will result in an update to the database. The request will be transmitted to the disaster recovery site and the backup database will be updated. The update to the database will be provided to the email forwarding, Whois and DNS servers where necessary, by being placed in a queue on the update server. The final stage will be the outcome of the request being made known to the Registrar. The logging process will allow the status of a transaction to be determined if there is a hardware failure on one of the components. Update Server The update server will also use the queuing software. If an update has been made to the database then normally this will need to be reflected in the email forwarding, Whois or DNS servers. These updates will be queued on the update server. From here the email forwarding, Whois and DNS servers will be updated. Registry Server In case of an unexpected outage on the Registry Server, operations will be rapidly resumed, as there will be an automatic switch to a standby machine. If the system outage on the Registry Server also resulted in corruption of the file-systems, the entire dataset will be regenerated from the main database. Update Server In case of an unexpected system outage on the update server, operations will be rapidly resumed, as its functionality will be switched to a "warm standby" machine. In the event of fatal hardware errors, the update server can also be replaced with identical hardware. Once the update server is restarted, it will go through all the temporary files on its hard drive and update all the email forwarding, Whois and DNS servers with any committed updates. If the system outage resulted in a corruption of the file-system, the entire dataset will be regenerated from the main database. Database server In case of a failure in the database server, the secondary server will take over operations from the catalogued database up to and including to the last committed transaction. In addition, in the event of a complete non-recoverable failure of the storage system, the data will be retrievable from the database backup and the complete logs from the Registry system. Whois server In case of an error on one of the Whois servers open to the public, the server will be replaced or restored as appropriate. A complete copy of the current information will be available from another Whois server or from the database. When all the information has been copied for that server, the new Whois server will be reopened for public access. DNS server In case of an error on one of the DNS servers open to the public, the server will be replaced or restored where necessary. A complete zone transfer may then be done from the primary stealth DNS server, and the DNS may then be reopened for queries from the public. Email Forwarding server In case of an error on one of the email forwarding servers open to the public, the server will be replaced or restored as appropriate. A complete copy of the current information will be available from another email forwarding server or rebuilt from the main database. A disaster recovery site is available in the event of an emergency, and can be activated to provide the services that the main site would normally provide within a short time period. The main site is designed with redundancy in mind so the activation of the disaster recovery site would only happen if the emergency proved severe enough such that the main site would be not operational within a satisfactory time period. To prevent loss of data and to enable quick recovery in case of a disaster situation or system crash, the Registry Operator will employ a rigid backup solution to satisfy the requirements set forth and defined in Appendix C section Registry Operations. Information handled by the Registry Operator can be divided into essential data which must be included in the backup process, and non-essential or generated data which may be recovered from other sources or is not useful for the continued operations of the .name registry. As an example, the DNS zone files and Whois data can be regenerated from the SRS database. Full detailed documentation on the backup strategy employed by the Registry Operator will be made available as part of the implementation process, (henceforward termed "Backup and Restoration document"). This is to be updated regularly to reflect changing requirements as the registry grows in size and maturity. The documentation will be divided into the following areas:
A re-evaluation of all backup policies will be performed at regular intervals. During the startup phase, this evaluation process is to take place once a month; this interval is to decrease to once every three months after operational integrity has been verified. The Registry Operator will run regular tests (described later in this section) on the backup data to ensure that the backup process is operating correctly, and will also run regular tests to check that restoration procedures are correct and understood by the relevant personnel. Keeping the backup strategies updated and checking them regularly helps prevent parts of the system from being excluded from the backup system due to oversight or human error. It is important that the users with access to the machines are aware of the policies and that these users adhere to the rules and regulations, so as to eliminate potential errors. The Registry Operator will update the Backup and Restoration document whenever the Registry system is expanded or changed in any way that will affect either the amount of data to be backed up or the number of machines involved in the backup schedule. The remainder of this section includes outline information on the system interactions, processes and storage methods, together with additional notes about security and operations. The authoritative information source for the Registry Operator's backup specification is fully described in the aforementioned Backup and Restoration documentation. Backup data categories The following data categories have been identified as candidates for the backup process:
A complete analysis of the required files and storage necessary for each of these categories is to be found in the Backup and Restoration documentation. Storage media Since each storage medium provides different qualities, backups will not all be stored on the same media type. Using more than one medium also removes a single point of failure - problems with one media type are less likely to affect a different media type. This list describes the basic media types most likely to be employed by the Registry Operator: CD-ROM CD-RW (rewriteable CD) is similar to CD-R in most respects, although write speeds are typically lower and the data can be erased and overwritten. DVD-R (recordable DVD) is similar to CD-R with larger storage capacity, and is most appropriate for larger data sizes. Tape is rewriteable, and available in a variety of sizes, although this is a slow storage method it is the most commonly used method due to large capacity and is the preferred method for the Registry Operator. Backup system Backup is performed on backup servers, and will not interfere with provision of service. Each site will have its own backup system; the backup system at the main site will be separate from the system at the Disaster Recovery Site, and there will be a further backup system for DNS site data. Each DNS site holds duplicate data, so a separate process is not required for each DNS site. There will be one backup server connected to a removable storage system at the Main Site, and one backup server connected to another removable storage system at the Disaster Recovery Site. The removable storage system will be a high capacity, automated removable media library capable of keeping several complete backup sets in store at any time. The backup system will be highly automated and able to perform the assigned tasks without supervision. However, a vital part of the operational staff's daily tasks will be to monitor and check up on the progress and state of the backup system during normal operation. By default the backup system will maintain a log of operations, including status messages, errors and warnings. It will also report status, warning and error messages to the Backup Administrator by email. The Registry Operator may also employ other means of messaging, such as paging systems for critical errors related to the backup system. Machines included in the backup schedule will be prioritized so that the more critical machines are backed up first. The backup schedule will also vary depending on how critical a particular machine is considered to be. For non-critical machines a daily incremental backup scheme may be employed, with full backups performed weekly. For critical machines a full backup scheme may be used, to ensure backup quality and to enable a potential restoration session to be performed faster. The Registry Operator may employ different backup frequencies to certain types of data depending on how dynamic the data is. Operating system modules, binaries and libraries will not be updated very often and will only need to be backed up in the case of an upgrade. Configuration files need to be backed up whenever a change has been made. Dynamic data, on the other hand, will need to be backed up on a daily basis. Backup of backup system To ensure that the Registry Operator can restore an operational system as quickly as possible, there will need to be a backup of the backup system itself, hereafter termed the "backup fallback". Indexes, backup scripts and automated procedures as well as backup configuration files will be saved in case a loss of service occurs on the backup system. The backup fallback will be performed at least once a week. At the Registry Operator's discretion, another backup system may be used for this task. The aforesaid Backup and Restoration Procedures document will describe the operational requirements and procedures for the backup and restoration of the backup system. Initial test backup In the Ramp Up phase, the Registry Operator will perform and subsequently verify a full backup of the Registry's Main Site, hereafter termed the "Test Backup". This Test Backup will include a backup of all systems at the Main Site, and will be performed according to the aforesaid Backup and Restoration Procedures document. After completing a full backup of the Main Site, this backup is to be restored again. The contents of the backup shall be verified according to guidelines in the Backup and Restoration Procedures document. All incidents encountered during the backup and restoration procedures should be logged and investigated. The Registry Operator will take the appropriate steps to rectify any potential errors in system setup or backup procedures so as to ensure the quality of backup and restoration. Any further issues raised during the backup process or subsequent restoration will be passed on to the Backup Administrator, who will take appropriate action for resolution of these. The Registry Operator will, after completing the Test Backup, provide a Backup Test Result document to ICANN containing an analysis of the results of aforesaid Test Backup, and a summary describing any further information that may be relevant. Backup test procedures Data integrity of the most recent backup will be tested regularly according to the test procedures outlined in the "Test documentation" section of the Backup and Restoration documentation. The Backup Operators will monitor the outcome of these test procedures to catch any potential procedural errors and preventing such errors from occurring in the future. All tools and procedures for this purpose will be evaluated regularly and revised if the Registry Operator has valid reasons for doing so. Changes to the tools or procedures for the backup test will be documented in the aforesaid Backup and Restoration Procedures document. Offsite backup sets The Registry Operator will at all times have at least two complete backup sets located offsite and stored at a secure location. Multiple unconnected backups, taken at different times, are necessary to avoid the risks of a single point of failure as posed by a centralized storage system. Storing different backups at different locations will increase the chances that a good backup copy has been taken, a matter which will be further guaranteed by the backup testing and verification process, and will also increase the likelihood that at least one of the backups is still valid after the test process has completed. An extra copy of the backup data will ensure that should complete or partial loss of one backup occur, there is still a complete copy of the entire dataset available. Offsite storage reduces the potential harm posed by physical damage or destruction of a site. Backup reporting The results from all backups, backup tests and restorations performed by the Backup Operators will be reported and stored in both electronic and paper format. Incident reports related to the backup system will also be stored in this way. The Backup Administrator will be responsible for keeping this documentation updated at all times. The electronic version of the reports will also be backed up daily. The Backup Administrator is also responsible for documenting any changes or fixes made to the backup system so as to provide a means for tracking problems or events related to the backup system. It is also the responsibility of the Backup Administrator and the team of Backup Operators to keep the Backup and restoration Procedures document and any test procedure documents updated. Backup security Backup will be performed through a secure network on both the main site and the disaster recovery site. The Registry Operator will decide on the use of an encryption scheme for the backup of sensitive data as a part of the implementation process. Security-cleared personnel will transport the removable media to a secure location where it will be stored. This will be done at least once a week. The security companies providing the offsite storage and transport services will provide 24/7 availability. The security company will enforce access restrictions on this data, and only authorized personnel within the Registry Operator organization will be able to request the stored data on demand. Further information on security precautions and issues are included in the Backup and Restoration documentation, in the Security section. This section will be kept updated if changes are required. The Registry Operator will perform tests in the start-up phase of the registry to make sure that the Registry Operator builds the registry according to the specification outlined in this contract. When changes to the registry or new services and equipment are added to the registry, the Registry Operator will perform new tests. Guidelines for these tests are described in the section called Internal Test Procedures. To provide the best service for the Registrars, the Registry Operator will make sure that the communication between the parties follows the agreed specification. This is done by procedures performed by each new Registrar, under guidance from the Registry Operator. This procedure is described in the section called OT&E Procedures. Internal Test Procedures Testing policy The implementation of the Registry will be verified with a set of tests, hereafter called implementation tests. These tests will not involve the Registrars directly, as in an operational environment. However, some Registrars may assist the Registry Operator in performing parts of the test, in order to check the communications from their test environment. Guidelines for implementation tests are described in the Implementation Test section herein. Testing of the services is separated in different stages related to the software and hardware components, hereafter called "objects", that build the registry services. All interfaces between communicating objects will be tested with input data in the object-specific range. The output will be monitored and compared with the expected results for the inputs. Any unexpected results will be treated as an error in the implementation or design of the object, and this will be cause for a thorough analysis of code and design, after which the implementation will be corrected. A new test will be run after the implementation is corrected. Test procedures will be made before implementing the objects and will be documented. The test result will be logged and saved for later use. When doing a functional test, the component to be tested is treated as a "black box". This means that the functional test will check the data entered, and then check the output data to ensure that they match. Internal workings of the "black box" component are not relevant to this test, and success on this test is not necessarily indicative of correct internal function. The system test will test the software and hardware in the "black box". This will involve actions such as checking logs for different parts of the "black box" when inputting and outputting data, and checking different thresholds during stress tests. Implementation Tests There are seven levels of implementation tests. Guidelines for the test level are described below. Level 1: Overall functional test During this test all functionality agreed with ICANN will be tested. This includes all functionality of external interfaces such as the Registrar-Registry Interface, DNS, Whois, E-mail forwarding and WWW interface. The test dataset for this test is to be picked from the range(s) of possible data that will be put into this system. Data at the start and end of these ranges will always be tested. This test is hereafter referred to as the "Acceptance test". There will be one Overall Functional Test for each service launched as described in Appendix J. The Overall Functional Test will continue until the service passes the test. The service will be launched after the test is passed. The test procedures for each service will be documented during the specification of the service, and sent to ICANN for comments before implementation. Any changes to these procedures will be documented and explained, and the changes will be sent to ICANN for comments. The test is done in a production environment, on similar equipment to that used for production services. Level 2: Overall system test The "Overall System test" is an on site test to verify that the system is working properly. The test is done after the installation of the system. A system consists of various equipment and software that runs the service. E.g. Network equipment as router, switches and network cables, servers and its hardware components, software as operating system, middleware and user interface applications. The test procedures will be documented during the specification of the system. Some parts of the procedures may be specified by the vendor of the parts of the system. The documentation is for internal use only. Level 3: Internal functional test This test is based on the Acceptance Test, but may be extended if the Registrar Operator finds it reasonable. The test is done in the test environment and/or in the production environment. The test procedures and the result of the test are documented. The documentation is for internal use only. Level4: Internal system test This test is based on the System Test, but may be extended if the Registry Operator finds it reasonable. The test is done in the test environment and/or in the production environment. The test procedures and the result of the test are documented. The documentation is for internal use only. Level 5: Component functional test The component functional test is a test of equipment or software that is a part of a system. Only functions that will be used in the overall system configuration will be tested. The test is done in the test environment. The test procedures will be performed in the same way as the other functional tests specified herein, and the criteria for the test data are also the same. Level 6: Component system test The component system test is a test of equipment or software that is a part of a system. Only functions that will be used will be tested. The test is done in the test environment. The test procedures will be performed in the same way as the other system tests specified herein, and the criteria for the test data are also the same. The test procedures and the result of the test will be documented. The documentation is for internal use only. Level 7: Software Module test If the software running a service consists of separate product modules, the functionality of the modules will be tested. E.g. checking the public, static web pages serviced by the Registry Operator's web server. The test will be done in a test environment. The procedures will be documented before verification of a module. Data used for the test will follow the same criteria for the functional and system tests already specified. The result of these tests will also be documented. The documentation is for internal use only. Before a Registrar is allowed to interact with the SRS or any other systems operated by the Registry Operator they are required to pass the Registrar Operational Test & Evaluation (OT&E). The purpose of OT&E is to verify the correct operation and performance of a Registrar's client system. Once the non-technical criteria as outlined in the `Registry-Registrar License and Agreement are fulfilled the Registrar will only need to pass the tests described in this section to become certified for use of the Registry Operators SRS. Definitions "RRP" - This acronym refers to the protocol used for Registrar-Registry communication over SSL to the SRS. Preparations for OT&E Certification The OT&E Certification process begins when a Registrar becomes accredited by ICANN to register names in the .name TLD, at which point a welcome package will be provided to the Registrar. This package includes information that will assist the Registrar in implementing and verifying its RRP client application. This package will include the following:
The Registrar is responsible for developing and installing the RRP client application that will interface to the Registry Operators SRS. The Registrar Tool Kit is available to any interested party that would like to implement Registrar client applications. The Registry-Registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish a SSL Version 3.0 encrypted channel. The username/password and subnet list provides additional security as only a valid combination of a SSL Version 3.0 certificate; username/password and subnet will be allowed to access the live Shared Registry System. During RRP client implementation, the Registrar has access to the OT&E Environment. In the OT&E Environment, the Registrar may test the operation of its software to verify the correct handling of RRP commands, their responses, and notification messages. Operations performed in the OT&E Environment will not be charged and will not have any impacts on the live SRS. Registrars will continue to have access to the OT&E Environment after certification, so that they may continue to test their client software. When a Registrar has completed the testing of its RRP client and would like to proceed with OT&E Certification, it should contact the Registry Operators technical support to schedule a time slot. Time slots will be scheduled on a first-come-first-serve basis. At the scheduled time, the Registrar should contact the Registry Operators OT&E technical support team to initiate the certification. The Registrar Tool Kit The Registry Operator will provide software to Registrars enabling them to write client applications to interface with the SRS interface. This software will consist of a Java API with sample code and C/C++ sample code. Examples of XML message assembly will be shown in the sample code in addition to code illustrating how static XML requests can be sent to the Registry Operator. The Registrar Tool Kit will give the Registrar a reference implementation that conforms to the RRP. The Registrar Tool Kit will also contain documentation explaining the protocol specification in detail. Information included in this documentation will contain the format of request messages and possible response messages, as well as command sequences and message assembly rules for each SRS operation. The Registrar Toolkit will be licensed under the GNU Lesser General Public License and this Agreement. OT&E Certification Test Cases During OT&E certification, a Registrar's client application will be required to demonstrate the proper execution of the following operations:
NOTE: The Registry Operator reserves the right to change the OT&E Certification requirements as necessary. Post OT&E Certification All tests performed during OT&E Certification must be completed without errors. The Registry will provide the certification results in a timely manner and provide feedback for those Registrars that failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E Certification. Upon successful OT&E Certification, the Registrar becomes eligible for operation in the live SRS. A new username/password is assigned and the Registry will configure the live system to recognize the SSL certificate, username, password, and subnet blocks for the Registrar. The Registrar may start operation when it has satisfied the financial requirements for going live. Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
|
