Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

Unsponsored TLD Agreement: Appendix D (.biz)

ICANN | Unsponsored TLD Agreement: Appendix D (.biz)

  ICANN Logo

Unsponsored TLD Agreement: Appendix D (.biz)
Posted: 11 May 2001


Performance Specifications

1. Introduction. The attached Performance Specification Matrix ("Matrix") provides a list of performance specifications as they apply to the three Core Services provided by the Registry - SRS, Nameserver, and Whois services.

2. Definition. Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.

2.1 "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 Section 3.6 of this Appendix D. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.

2.2 "Core Services" refers to the three core services provided by the Registry - SRS, Nameserver, and Whois Services.

2.3 "Performance Specification" refers to the specific committed performance service levels as specified herein.

2.4 "Performance Specification Priority" refers to the Registry's rating system for Performance Specifications. Some Performance Specifications are more critical to the operations of the Registry than others. Each of the Performance Specifications is rated as C1 - mission critical, C2 - mission important, C3 - mission beneficial, or C4 - mission maintenance.

2.5 "Registrar Community" refers to all of the ICANN-Accredited Registrars who have executed Registry-Registrar Agreements with Registry Operator for the Registry TLD.

2.6 "SRS" refers to the Shared Registration System; the service that the Registry provides to the Registrar Community. Specifically, it refers to the ability of Registrars to add, modify, and delete information associated with domain names, nameserver, contacts, and registrar profile information. This service is provided by systems and software maintained in coactive redundant data centers. The service is available to approved Registrars via an Internet connection.

2.7 "Nameserver" refers to the nameserver function of the Registry and the nameservers that resolve DNS queries from Internet users. This service is performed by multiple nameserver sites that host DNS resource records. The customers of the nameserver service are users of the Internet. The nameservers receive a DNS query, resolve it to the appropriate address, and provide a response.

2.8 "Service Level Measurement Period" refers to the period of time for which a Performance Specification is measured. Monthly periods are based on calendar months, quarterly periods are based on calendar quarters, and annual periods are based on calendar years.

2.9 "Whois" refers to the Registry's Whois service. The Registry will provide contact information related to registered domain names and nameserver through a Whois service. Any person with access to the Internet can query the Registry's Whois service directly (via the Registry website) or through a Registrar.

3. Performance Specifications. Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry TLD. The Performance Specifications defined below establish the basis for the Service Level Exception Credits ("SLE Credits") provided for in Appendix E to this Registry Agreement. These Performance Specifications also set forth Registry Operator's obligations directly to ICANN under Subsection 3.3 of the Registry Agreement.

3.1 Service Availability. Service Availability is defined as the time, in minutes, that the Registry's Core Services are responding to its users. Service is unavailable when a service listed in the Matrix is unavailable to all users, that is, when no user can initiate a session with or receive a response from the Registry ("Unavailability"). Service Availability is a C1 priority level.

3.1.1 Service Availability is measured as follows:

Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where:

TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes)

POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period)

UOM = Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability during the Service Level Measurement Period minus POM).

Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party (to be selected by Registry Operator with the consent of the Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be no more than once yearly during the term of the agreement between Registry Operator and the Registrar.

This calculation is performed and the results reported for each calendar month for SRS and Whois availability and for each calendar year for Nameserver availability. Results will be reported to the Registrar Community via e-mail and to ICANN according to Appendix T.

3.1.2 Service Availability—SRS = 99.9% per calendar month. Service Availability as it applies to the SRS refers to the ability of the SRS to respond to Registrars that access and use the SRS through the XRP protocol defined in Appendix C. SRS Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for SRS is 99.9% and the Service Level Measurement Period is monthly.

3.1.3 Service Availability—Nameserver = 99.999% per calendar year. Service Availability as it applies to the Nameserver refers to the ability of the Nameserver to resolve a DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Nameserver is 99.999% and the Service Level Measurement Period is annually.

3.1.4 Service Availability—Whois = 99.95% per calendar month. Service Availability as it applies to Whois refers to the ability of all users to access and use the Registry's Whois service. Whois Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Whois is 99.95% and the Service Level Measurement Period is monthly.

3.2 Planned Outage. High volume data centers like the Registry require downtime for regular maintenance. Allowing for regular maintenance ("Planned Outage") ensures a high level of service for the Registry. Planned Outage Performance Specifications are a C4 priority level.

3.2.1 Planned Outage Duration. The Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry Operator is allowed to take the Registry Services out of service for regular maintenance. Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. This Performance Specification, where applicable, has a monthly Service Level Measurement Period. The Planned Outage Duration for the Core Services is as follows:

(i) Planned Outage Duration - SRS = 8 hours (480 minutes) per month;

(ii) Planned Outage Duration - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Duration - Whois = 8 hours (480 minutes) per month.

3.2.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The Planned Outage Timeframe for the Core Services is as follows:

(i) Planned Outage Timeframe - SRS = 0600-1400 UTC Sunday;

(ii) Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Timeframe - Whois = 0600-1400 UTC Sunday.

3.2.3 Planned Outage Notification. The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage Notification Performance Specification defines the number of days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned Outage Notification for the Core Services is as follows:

(i) Planned Outage Timeframe - SRS = 3 days;

(ii) Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Timeframe - Whois = 3 days.

3.3 Extended Planned Outage. In some cases such as software upgrades and platform replacements an extended maintenance timeframe is required. Extended Planned Outages will be less frequent than regular Planned Outages but their duration will be longer. Extended Planned Outage Performance Specifications are a C4 priority level.

3.3.1 Extended Planned Outage Duration. The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry Operator is allowed to take the Registry Services out of service for extended maintenance. Extended Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. Extended Planned Outage periods are in addition to any Planned Outages during any Service Level Measurement Period. This Performance Specification, where applicable, has a Service Level Measurement Period based on a calendar quarter. The Extended Planned Outage Duration for the Core Services is as follows:

(i) Extended Planned Outage Duration - SRS = 18 hours (1080 minutes) per calendar quarter;

(ii) Extended Planned Outage Duration - Nameserver = (no planned outages allowed); and

(iii) Extended Planned Outage Duration - Whois = 18 hours (1080 minutes) per calendar quarter.

3.3.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage can occur. The Extended Planned Outage Timeframe for the Core Services is as follows:

(i) Extended Planned Outage Timeframe - SRS = 0600 - 1400 UTC Saturday or Sunday;

(ii) Extended Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Extended Planned Outage Timeframe - Whois = 0600 - 1400 UTC Saturday or Sunday.

3.3.3 Extended Planned Outage Notification. The Registry Operator must notify all of its Registrars of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage Notification for the Core Services is as follows:

(i) Extended Planned Outage Timeframe - SRS = 4 weeks;

(ii) Extended Planned Outage Timeframe - Nameserver =(no planned outages allowed); and

(iii) Extended Planned Outage Timeframe - Whois = 4 weeks.

3.4 Processing Time. Processing Time is an important measurement of transaction-based services like the Registry. The first three Performance Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the quality of that service.

Processing Time refers to the time that the Registry Operator receives a request and sends a response to that request. Since each of the Registry Services has a unique function the Performance Specifications for Processing Time are unique to each of the Registry Services. For example, a Performance Specification for the Nameserver is not applicable to the SRS and Whois, etc. Processing Time Performance Specifications are a C2 priority level.

Processing Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The Registry Operator will log the processing time for all of the related transactions, measured from the time it receives the request to the time that it returns a response.

3.4.1 Processing Time—Add, Modify, Delete = 3 seconds for 95%.

(i) Processing Time - Add, Modify, and Delete is applicable to the SRS as accessed through the XRP protocol defined in Appendix C. It measures the processing time for add, modify, and delete transactions associated with domain names, nameservers, contacts, and registrar profile information.

(ii) The Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95% of the transactions will take 3 seconds or less from the time the Registry Operator receives the request to the time it provides a response.

3.4.2 Processing Time—Query Domain = 1.5 seconds for 95%.

(i) Processing Time - Query Domain is applicable to the SRS as accessed through the XRP protocol defined in Appendix C. It measures the processing time for an availability query of a specific domain name.

(ii) The performance specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Registry Operator receives the query to the time it provides a response as to the domain name's availability.

3.4.3 Processing Time—Whois Query = 1.5 seconds for 95%.

(i) Processing Time - Whois Query is only applicable to the Whois. It measures the processing time for a Whois Query.

(ii) The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Whois receives a query to the time it responds.

3.4.4 Processing Time—Nameserver Resolution = 1.5 seconds for 95%.

(i) Processing Time - Nameserver Resolution is only applicable to the Nameserver. It measures the processing time for a DNS query.

(ii) The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time Nameserver receives the DNS query to the time it provides a response.

3.5 Update Frequency. There are two important elements of the Registry that are updated frequently and are used by the general public; Nameserver and Whois. Registrars generate these updates through the SRS. The SRS then updates the Nameserver and the Whois. These will be done on a batch basis. Update Frequency Performance Specifications are a C3 priority level.

The committed Performance Specification with regard to Update Frequency for both the Nameserver and the Whois is 15 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver and Whois will be effectuated within 15 minutes. This is measured from the time that the registry confirms the update to the registrar to the time the update appears in the Nameserver and Whois. Update Frequency Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis.

3.5.1 Update Frequency—Nameserver = 15 minutes for 95%.

3.5.2 Update Frequency—Whois = 15 minutes for 95%.

3.6 Cross-Network Nameserver Performance Requirements. Nameserver round-trip-time and packet loss from the Internet are important elements of the quality of service provided by the Registry Operator. These characteristics, however, are affected by Internet performance and therefore cannot be closely controlled by Registry Operator. Accordingly, these requirements are not matters subject to Service Level Exceptions and credits under the Service Level Agreement (Appendix E), but they are Registry Operator obligations under Section 3.3 of the Registry Agreement.

The committed Performance Specification for cross-network nameserver performance is a measured round-trip time of under 300 ms and measured packet loss of under 10%. Cross-network nameserver performance measurements will be conducted by ICANN at times of its choosing, in the following manner:

3.6.1 The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .biz nameservers and observing the responses from the .biz nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root nameserver locations (on the US East Coast, US West Coast, Asia, and Europe).

3.6.2 Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected .biz second-level domains, preselected to ensure that the names exist in the Registry TLD and are resolvable. 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.

3.6.3 To meet the packet loss and round-trip-time requirements for a particular CNNP Test, all three of the following must be true:

3.6.3.1 The round-trip time and packet loss from each measurement location to at least one .biz nameserver must not exceed the required values.

3.6.3.2 The round-trip time to each of 75% of the .biz nameservers from at least one of the measurement locations must not exceed the required value.

3.6.3.3 The packet loss to each of the .biz nameservers from at least one of the measurement locations must not exceed the required value.

3.6.4 Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.

3.6.5 To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times 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 .biz nameservers persistently fail (see Section 3.6.3 above) the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.

3.6.6 In the event of persistent failure of the CNNP Tests, ICANN will give Registry Operator written notice of the failures (with backup data) and Registry Operator will have sixty days to cure the failure.

3.6.7 If, following that opportunity to cure, the .biz 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.

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

4. Responsibilities of the Parties.

4.1 Except in the case of nameserver performance measurements, Registry Operator will perform monitoring from internally located systems as a means to verify that the availability and performance measurements in this document are being met.

4.2 Beginning no later than 120 days post 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.

4.3 The Registry Operator will provide the Whois Service as specified in Appendices C and O.

4.4 The Registry Operator will use commercially reasonable efforts to restore the critical systems of the Core Services within 24 hours after the termination of a force majeure event and restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered Service Unavailability.

5. Miscellaneous.

5.1 This Appendix is not intended to replace any term or condition in the Registry Agreement.

5.2 Dispute Resolution will be handled pursuant to the terms of Subsection 5.9 of the Registry Agreement.

PERFORMANCE SPECIFICATION MATRIX

 

Performance Specification Description

SRS

Nameserver

Whois
         

1
Service Availability 99.9% per calendar month 99.999% per calendar year 99.95% per calendar month

2
Processing Time–Add, Modify, Delete 3 sec for 95% NA NA

3
Processing Time–Query Domain 1.5 sec for 95% NA NA

4
Processing Time–Whois NA NA 1.5 sec for 95%

5
Processing Time–Nameserver Resolution NA 1.5 sec for 95% NA

6
Update Frequency NA 15 min for 95% 15 min for 95%

7
Planned Outage–Duration 8 hrs per calendar month not allowed 8 hrs per calendar month

8
Planned Outage–Timeframe 0600 - 1400 UTC Sun not allowed 0600 - 1400 UTC Sun

9
Planned Outage–Notification 3 days not allowed 3 days

10
Extended Planned Outage–Duration 18 hrs per calendar quarter not allowed 18 hrs per calendar quarter

11
Extended Planned Outage–Timeframe 0600 - 1400 UTC Sat or Sun not allowed 0600 - 1400 UTC Sat or Sun

12
Extended Planned Outage–Notification 28 days not allowed 28 days

13
Cross-Network Nameserver Performance NA 300 ms RTT and 10% packet loss NA

Earlier drafts:

26 April 2001
25 April 2001




Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 19-May-2001

©2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.