Unsponsored TLD Agreement: Appendix D (.pro)
Posted: 2 March 2002
Performance Specifications
Registry Operator shall use commercially reasonable efforts to provide Registry Services at the levels set forth herein for the Registry TLD. The performance specifications, defined below, provide a means to measure Registry Operator's delivery of the Registry Services (as defined in the Registry Agreement) and, when applicable, allow for calculation of the SLA Credit payable to Registrar pursuant to Appendix E of the Registry Agreement.
1. Definitions. Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Agreement.
1.1 "Available" means that a given Service is operational as described in Section 2 below.
1.2 "Billing Period" shall mean each single calendar month beginning and ending at 0000 Greenwich Mean Time (GMT).
1.3 "CNNP Test" refers to a series of 100 DNS Queries used to measure cross network name server performance, as described in Subsection 2.1.4 below.
1.4 "Core Internet Service Failure" refers to an extraordinary and identifiable event beyond the control of Registry Operator affecting the Internet services to be measured pursuant to Subsection 2.1.4 below. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.
1.5 "DNS Point of Presence" shall mean one or more DNS name servers in a single geographic location, all responding on one or more common IP addresses.
1.6 "DNS Queries" shall mean single UDP queries of either of the following types:
with no more than one question section and must be made for domain names within the Registry TLD.
1.7 "DNS Service" shall mean the Domain Name Service complying with RFC 1034 as described in Appendix C of the Registry Agreement.
1.8 "Measured Transaction" shall mean queries or other transactions performed and monitored by Registry Operator explicitly for the purpose of determining whether or not a Service is Available.
1.9 "Planned Outage" means the periodic pre-announced occurrences when the Services will be taken out of service for maintenance or care. Planned Outages will not exceed four (4) hours per calendar week beginning at 0000 GMT Monday, nor total more than eight (8) hours per month. Notwithstanding the foregoing, Registry Operator may incur one (1) additional Planned Outage of up to eight (8) hrs per month in duration for major systems or software upgrades ("Extended Planned Outages"). In months in which Extended Planned Outages occur, no other Planned Outages may occur.
1.10 "Round-trip" means the amount of measured time that it takes for a measured query to make a complete trip from the sampling agent, to the system or process being tested and back again. Round-trip is usually measured in seconds or fractions of seconds.
1.11 "RRP Commands" shall mean requests to check, modify, add, or delete a domain name.
1.12 "RRP Service" shall mean the Shared Registry System (the "SRS") as described in Exhibit C of the Registry Agreement.
1.13 "Sampling Period" shall mean any one-minute period in which measurements are taken to determine whether or not a Service is Available.
1.14 "Service Level Exception" means the number of minutes of Unplanned Outage Time for a given Service in excess of the limits defined in Section 3 below.
1.15 "Service Unavailability" means when, as a result of a failure of systems within Registry Operator's control, one or more of the Services is not operating as described in Section 2 below. Service Unavailability includes both Planned Outage and Unplanned Outage Time.
1.16 "Services" shall mean the list of components listed in Section 2 of this Appendix.
1.17 "SLA" means the service level agreement between Registry Operator and Registrar attached as Appendix E to the Registry Agreement.
1.18 "SLA Credit" means those credits available to Registrar pursuant to the SLA.
1.19 "Unplanned Outage Time" shall mean the amount of time, other than during a Planned Outage, recorded between a trouble ticket first being opened by Registry Operator in response to a Registrar's claim of Service Unavailability for that Registrar through the time when the ticket has been closed. If Registry Operator determines that the incident described by the ticket was not the result of Service Unavailability, the time recorded by the ticket will not count towards Unplanned Outage Time.
1.20 "Update Time" means the time elapsed between a change being confirmed by the SRS and the change being made in the Whois Service or at a DNS Point of Presence.
1.21 "Whois Queries" means queries for a single domain name in the Registry TLD.
1.22 "Whois Service" means the Whois Service described in Appendices C and O of the Registry Agreement.
The following is the set of registry system Services for which availability and performance (including update times) requirements are established. Services shall meet the performance and availability requirements as listed herein. These availability and performance requirements set forth the Registry Operator's obligations directly to ICANN under Subsection 3.3 of the Registry Agreement.
2.1.1 Performance Specifications
2.1.1.1 The performance specification for DNS Queries is 300 milliseconds Round-trip time.
2.1.1.2 A DNS Point of Presence is considered to be Available during a Sampling Period if it responds to DNS Queries within the performance specification for 95% of all Measured Transactions within that Sampling Period.
2.1.2.1 The DNS Service is considered to be Available for a Sampling Period if over half of the System's DNS Points of Presence are Available for that Sampling Period.
2.1.2.2 The total Service Unavailability of the DNS Service shall not exceed 5 minutes per calendar year. This represents 99.999% system availability. There shall be no simultaneous Planned Outage of DNS Service at over half of the System's DNS Points of Presence.
2.1.3.1 The Update Time for the DNS Service shall not exceed 15 minutes for 95% of all updates.
2.1.4 Cross Network Nameserver Performance Requirements. The committed performance specifications for cross-network nameserver performance is a measured Round-trip time of under 300 ms and measured packet loss of under 10%. The cross-network nameserver performance requirements of this Subsection 2.1.4 are in addition to the requirements of Subsections 2.1.1, 2.1.2, and 2.1.3 above. Cross-network nameserver performance measurements will be conducted by ICANN at times of its choosing, in the following manner:
2.1.4.1 The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .pro name servers and observing the responses from the .pro nameservers. The measuring locations will be four root nameserver locations (on the US East Cost, US West Coast, Asia, and Europe).
2.1.4.2 Each string of request packets will consist of 100 DNS Queries at 10 second intervals requesting NS type resource records for arbitrarily selected .pro third-level domains, preselected to ensure that the names exist in the Registry TLD and are resolvable. All third-level domains must exist within the .pro second-level domains as defined within Appendix L. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received will be noted.
2.1.4.3 To meet the packet loss and Round-trip time requirements for a particular CNNP Test, all three of the following must be true:
(a) The Round-trip time and packet loss from each measurement location to at least one .pro nameserver must not exceed the required values.
(b) The Round-trip time to each of 75% of the .pro nameservers from at least one of the measurement locations must not exceed the required value.
(c) The packet loss to each of the .pro nameservers from at least one of the measurement locations must not exceed the required value.
2.1.4.4 Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.
2.1.4.5 To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different time of the day, as well as on different days of the week). Registry Operator will be deemed to have failed to meet the cross-network nameserver performance requirement only if the .pro nameservers persistently fail the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.
2.1.4.6 In the event of persistent failure of the CNNP Tests, ICANN will give Registry Operator written notice of the failures (with test data) and Registry Operator will have sixty days to cure the failure.
2.1.4.7 If, following that opportunity to cure, the .pro nameservers continue to persistently fail CNNP Tests and Registry Operator fails to resolve the problem after thirty days notice of the continuing failures, Registry Operator will be deemed not to have met its obligations under Subsection 3.3 of the Registry Agreement.
2.1.4.8 Sixty days prior to the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the testing tools and procedures to be used by ICANN. In the event that Registry Operator does not approve of such tools and procedures, ICANN will work directly with Registry Operator to make necessary modifications.
2.1.4.9 ICANN shall make available all data relating to CNNP Test results of the .pro name servers to Registry Operator. Data will be made available in a well-defined electronic format no later than the tenth day of the month following the month in which measurements were taken.
2.2.1 Performance Specifications. The performance specification for Whois Queries is 1500 milliseconds Round-trip time.
2.2.2.1 The Whois Service is considered to be Available for a Sampling Period if it responds to Whois Queries within the performance specification for 95% of all Measured Transactions within that Sampling Period.
2.2.2.2 The total Unplanned Outage Time of the Whois Service must not exceed 90 minutes per month. This represents 99.79% service availability.
2.2.3 Updates. The Update Time for the Whois Service shall not exceed 15 minutes for 95% of all updates.
2.3.1 Performance Speficiations
2.3.1.1 The performance specifications for add, modify and delete commands is 3000 milliseconds Round-trip time per domain present within the command.
2.3.1.2 The performance specification for check commands is 1500 milliseconds Round-trip time per domain present within the command.
2.3.2.1 The RRP Service is considered to be Available for a Sampling Period if it responds to RRP commands within the performance specification for 95% of all Measured Transactions within that Sampling Period.
2.3.2.2 The total Unplanned Outage Time of the RRP Service must not exceed 60 minutes per month. This represents 99.87% service availability.
3. Responsibilities of the Parties
3.1 Registry Operator will use commercially reasonable efforts to restore the critical components of the System within 48 hours in the case of a force majeure event. Outages due to a force majeure event will not be considered System Unavailability.
3.2 Except in the case of nameserver performance requirements, Registry Operator will perform monitoring from internally located systems as a means to verify that the availability and performance measurements of this document are being met.
3.3 Beginning no later than 120 days after the Commencement-of-Service Date, the Registry Operator will publish preliminary weekly system performance and availability reports. Registry Operator will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided.
3.4 The Registry Operator will provide Service Availability percentages during each Billing Period as listed in this Appendix.
4.1 This Appendix is not intended to replace any term or condition in the Registry Agreement.
4.2 Resolution of disputes under this Appendix between ICANN and Registry Operator will be handled pursuant to the terms of Subsection 5.9 of the Registry Agreement.
Earlier drafts:
Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
©2001, 2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.