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.

.org Registry Agreement: Appendix D

ICANN | .org Registry Agreement: Appendix D
  ICANN Logo

.org Registry Agreement: Appendix D

21 October 2002


Registry Performance Specifications

Registry Operator shall use commercially reasonable efforts to provide Registry Services for the .org TLD. The Performance Specifications, defined below, provide a means to measure Registry Operator's delivery of Registry Services under Subsection 3.3 of the Registry Agreement between Registry Operator and ICANN and, when applicable, allow for calculation of the SLA Credit payable to Registrar pursuant to Appendix E of the Registry Agreement.

1. Conventions.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

2. Definitions. 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 2 of Nameserver Availability and Performance Measurements in Exhibit A of this Appendix D. Such events include but are not limited to congestion, collapse, partitioning, power grid failures, and routing failures.

2.2 "Current Pricing Level" refers to prices charged for Registry Services as provided in Appendix G of the Registry Agreement as adjusted pursuant to Subsections 3.14.5 and 4.4 of the Registry Agreement.

2.3 "C1" means Category 1, a mission critical service.

2.4 "C2" means Category 2, a mission important service.

2.5 "C3" means Category 3, a mission beneficial service.

2.6 "Degraded Performance" means a service not meeting the performance requirement set forth in this document. Round-trip time is used as the basis of this metric for all services except nameservice; for nameservice packet loss and Round-trip time are used as metrics.

2.7 "Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 Coordinated Universal Time (UTC).

2.8 "Monthly Unplanned Outage Time" shall be the sum of minutes of all Unplanned Outage Time during the Monthly Timeframe. Each minute of Unplanned Outage Time subtracts from the available Monthly Planned Outage Time up to four (4) hours.

2.9 "Not Responding" means a service will be deemed as "Not Responding" in the event that the Registry Component Ping (rcPing), as described in Exhibit A attached hereto, responds with a negative or degraded service response.

2.10 "Planned Outage" means the periodic pre-announced occurrences during the Service Term when the System will be taken out of service for maintenance or care. Planned Outages will only be scheduled during the following window period of time each week, 0100 to 0900 UTC on Sunday (the "Planned Outage Period"). This Planned Outage Period may be changed from time to time by the Registry Operator, in its sole discretion, upon prior notice to each Registrar. Planned Outages will not exceed four (4) hours/per calendar week beginning at 0000 UTC Monday nor total more than eight (8) hours/per Monthly Timeframe. Planned Outage for a nameserver shall not coincide with or overlap Planned Outage for any other nameserver. Not withstanding the foregoing, in each calendar year Registry Operator may incur one (1) additional Planned Outage of up to eight (8) hrs in duration during the Planned Outage Period for major systems or software upgrades ("Extended Planned Outages"). This Extended Planned Outage represents the total allowed Planned Outages for the month.

2.11 "Round-trip" means the amount of measured time that it takes for a reference query to make a complete trip from the sampling agent, to the system or process being tested and back again. Usually measured in milliseconds.

2.12 "Service Availability" means when the System is operational and predictably responding in a commercially reasonable manner. By definition, this does not include Planned Outages or Extended Planned Outages.

2.13 "Service Unavailability" means when, as a result of a failure of systems within the Registry Operator's control:

2.13.1 With respect to services other than Whois Service and nameservice, Registrar is unable to establish a session with the System gateway which shall be defined as:

2.13.1.1 successfully complete a TCP session start,

2.13.1.2 successfully complete the SSL authentication handshake, and

2.13.1.3 successfully complete the Extensible Provisioning Protocol ("EPP") <login> or RRP login command.

2.13.2 With respect to all services, system monitoring tools register three (3) consecutive monitoring failures on any of the components listed in Section 3–System Services.

2.14 "SLA" means the service level agreement between Registry Operator and Registrar attached as Appendix E to the Registry Agreement.

2.15 "SLA Credit" means those credits available to the Registrar pursuant to the SLA.

2.16 "System" shall mean the list of components listed in Section 3–System Services.

2.17 "Transaction" shall mean chargeable Registry Services, which includes initial and renewal registrations.

2.18 "Unplanned Outage Time" shall mean all of the following:

2.18.1 With respect to services other than Whois Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the Registry Operator in response to a Registrar's claim of Service Unavailability for that Registrar through the time when the Registrar and Registry Operator agree the Service Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered Service Unavailability only for those individual Registrars impacted by the outage;

2.18.2 With respect to services other than Whois Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the Registry Operator in the event of Service Unavailability that affects all Registrars through the time when the Registry Operator resolves the problem with a final fix or a temporary work around, and the trouble ticket has been closed;

2.18.3 With respect to all services, the amount of time that Planned Outage time exceeds the limits established in Section 2.10 above; or

2.18.4 With respect to all services, the amount of time that Planned Outage time occurs outside the window of time established in Section 2.10 above.

2.19 "Whois Service" means the Registry Operator Whois Services described in Appendix O of the Registry Agreement.

3. System Services.

The following table lists, by category (C1, C2, or C3), the Registry System services for which availability and performance requirements are established. Services shall meet availability requirements according to their category, as listed in the "Cat." column below. In addition, various services must meet the performance requirements listed in the "Perf." column below. These availability and performance requirements are the subject of the Service Level Agreement (SLA) between Registry Operator and registrars (SLA) or the requirements of Subsection 3.3 of the Registry Agreement between Registry Operator and ICANN, as noted by the × marks below.

Component/Service

Cat.

Perf.

SLA

ICANN
DNS        
  • AXFR/IXFR Updates

C3

P5

×

×
  • Resolution of queries within the .org TLD, each nameserver

C1

P4
 

×
Whois        
  • Singular query/response

C2

P3
 

×
Billing        
  • Account balance check/modify

C2
 

×
 
  • Manual balance adjust

C3
 

×
 
Admin        
  • Update Registrar profile

C3
 

×

×
  • Update Registrar status

C3
 

×

×
Protocol Interface        
  • Add/Renew/Delete/ Update

C1

P1

×

×
  • Transfer

C2

P6

×

×
  • Check

C1

P2

×

×

4. Service Levels (Availability and Performance)

4.1 Service Level Matrix

C1
Total duration of Unplanned Outage Time of C1 class services must not exceed 30 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.93%.
Total duration of Service Unavailability of C1 class services must not exceed 120 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.73%.

C2
Total duration of Unplanned Outage Time of C2 class services must not exceed 90 minutes per monthly Timeframe. This represents a Service Availability percentage of 99.79%.
Total duration of all Service Unavailability of C2 class services must not exceed 240 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.45%.

C3
Total duration of Unplanned Outage Time of C3 class services must not exceed 300 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.30%.
Total duration of all Service Unavailability of C3 class services not to exceed 600 minutes per Monthly Timeframe. This represents a Service Availability percentage of 98.61%.

P1
For a single-entity payload, Round-trip time should not exceed 800ms as measured by the system monitoring tools that simulates a representative registrar. A request with a multiple entity payload should materially perform consistent with the behavior of multiple, single entity payload operation.

P2
For a single-entity payload, Round-trip time should not exceed 400ms as measured by the system monitoring tools that simulates a representative registrar. A request with a multiple-entity payload should materially perform consistent with the behavior of multiple, single entity payload operation.

P3
For a singular query/response, Round-trip time should not exceed 800ms as measured by the system monitoring tools.

P4
Each nameserver achieves a measured Round-trip time of under 300ms and measured packet loss of under 10%. See Exhibit A for the measurement methodology.

P5
See Section 6.3 below.

P6
For a single-entity payload, Round-trip time should not exceed 1600ms as measured by the system monitoring tools that simulates a representative registrar. A request with a multiple-entity payload should materially perform consistent with the behavior of multiple, single entity payload operation.

4.2 Service Definition and Service Level Requirement

Service Attribute Unit of Measure Commitment
DNS service availability from each nameserver, minimum percentage uptime 99.73%
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum percentage uptime 99.999%
DNS query response rate for all nameservers combined, minimum absolute queries/sec Minimum 10,000/sec
DNS query response rate for each nameserver, minimum % of measured load (busiest hour averaged over one month) on most loaded server 300%
(see RFC 2780, sec. 2.3)
Cross-network nameserver round-trip time, maximum milliseconds 300
Cross-network nameserver packet loss, maximum percentage <10%
DNS update interval, maximum minutes 15
SRS service availability, minimum percentage uptime 99.45%
SRS processing time, maximum for query operations milliseconds 400ms
SRS processing time, maximum for write operations milliseconds 800ms
SRS service planned outage duration, maximum hours/month 8 hrs/month (includes Whois)
SRS service planned outage timeframe days and hours 0100 to 0900 UTC on Sunday
SRS service planned outage notification, minimum days 7 days
SRS service extended planned outage duration, maximum hours/quarter 0 hrs (Planned Outage Time can be used as Extended Planned Outage Time; the total planned outage time per period is the sum of Planned Outage and Extended Planned Outage.)
SRS service extended planned outage timeframe days and hours 0100 to 0900 UTC on Sunday
Whois service availability, minimum percentage uptime 99.45%
Whois query processing time, maximum milliseconds 800 ms
Whois update interval, maximum minutes 15
Whois service planned outage duration, maximum hours/month 8 hrs/month (includes SRS)
Whois service planned outage timeframe days and hours 0100 to 0900 UTC on Sunday
Whois service planned outage notification, minimum days 7 days

5. Measurement.

Except for nameserver performance measurements (P4), Registry Operator will monitor the System in accordance with the following principles.

5.1 System/Component Monitoring:

The services defined in this Appendix will be sampled and tested as to availability pursuant to the schedule attached hereto as Exhibit A.

5.2 Performance Monitoring:

The services defined in this Appendix will be sampled and tested as to their performance pursuant to the schedule attached hereto as Exhibit A. Services Not Responding within the Round-trip response times listed in Section 4 – Service Levels will be deemed suffering from Degraded Performance for the purposes of this Appendix.

Nameserver performance measurements will be conducted by ICANN according to Exhibit A.

6. Responsibilities of the Parties.

6.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 of this document are being met.

6.2 The Registry Operator will update the Whois Service on a near real-time basis. During normal operation, all registration and information updates sent from a Registrar to the Registry are stored in the primary database (database A). The information in database A is replicated to a backup database (database B) at regular intervals, normally within five (5) minutes. The Whois Service uses database B as its source of information. The time lag in the Whois information update is determined by the database replication interval. The Registry Operator will notify Registrars in advance when changes to the Whois Service update schedule occur.

6.3 The Registry Operator will initiate the addition, deletion, or other modification of DNS zone information to the master DNS server within 15 minutes after a Transaction. The Registry Operator will notify Registrar in advance when changes to the schedule occur. The Registry Operator will notify Registrars regarding any scheduled maintenance and unavailability of the TLD nameservers.

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

6.5 Beginning no later than 60 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.

6.6 The Registry Operator will provide Service Availability percentages during each Monthly Timeframe as listed in Section 4.1 – Service Level Matrix.

7. Miscellaneous.

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

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


EXHIBIT A
Sampling and Testing Schedule

The Registry Component Ping (rcPing) facility is used to determine two elements of service level agreement (SLA) compliance for the registry. The first level of compliance involves determining the availability of specific components/functions within the registry system. The second level of compliance involves determining if the components/functions are responding within a pre-determined time period.

The rcPing request is generated by a monitor (rcPing Monitor) component within the server complex. The interface/request handler which is responsible for receiving commands for the monitored components/functions should record the time of the request arriving, ping the monitored component/function, record the stop time, determine the difference in milliseconds and respond with the integer value in milliseconds of the difference.

The rcPing Monitor will time out if no response is received from the interface within a pre-determined interval. The rcPing request is specific to the component being monitored. Monitoring requests are sent independent of one another.

The following table lists the components to be monitored by the rcPing facility.

Component

Function

Interface

rcPing Command

Response Time

eppServer AddDomain eppServer RcPingepp(add) 800
eppServer renewDomain eppServer RcPingepp(renew) 800
eppServer deleteDomain eppServer RcPingepp(delete) 800
eppServer transferDomain eppServer RcPingepp(transfer) 1600
eppServer checkDomain eppServer RcPingepp(check) 400
radmin updateRegistrar radmin RcPingAdmin(update) 800
billingServer checkBalance eppServer RcPingepp(checkBalance) 800
billingServer updateBalance eppServer RcPingepp(updateBalance) 800
whois whois whois RcPingWhois(whois) 800
Dns transfer eppServer RcPingepp(dnsTransfer) 800

Each component being monitored can be configured with the following:

1. The time-out threshold. A typical value for timeout is three (3) seconds.

2. The expected response time for each ping command, as listed above.

3. The interval at which the ping commands will be sent. A typical value for the sampling interval is five (5) minutes.

4. The number of consecutive failures (i.e. exceeded response times and ping time outs) that determine a non-compliance with the SLA for a single component. A typical value is three (3) consecutive failures.

The rcPing monitor will store all response time data in a database that will be archived on a daily basis.

Nameserver Availability and Performance Measurements

1. Availability of each .org nameserver shall be measured by the rcPing utility. A nameserver that does not respond to three consecutive ping requests (pings at five-minute intervals with three-second timeouts) will be considered as Not Responding.

2. 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 Subsection 3.3 of the Registry Agreement.

The committed Performance Specification for cross-network nameserver performance is a measured Round-trip time of under 300ms 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:

2.1. The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .org nameservers and observing the responses from the .org 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).

2.2. Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected .org 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.

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

2.3.1. The Round-trip time and packet loss from each measurement location to at least one .org nameserver must not exceed the required values.

2.3.2. The Round-trip time to each of 75% of the .org nameservers from at least one of the measurement locations must not exceed the required value.

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

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

2.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 .org nameservers persistently fail (see item 1.1.3 above) the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.

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

2.7. If, following that opportunity to cure, the .org nameservers continue to persistently fail CNNP Tests and Registry Operator fails to resolve the problem within thirty days after written 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.8. Sixty days before 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.


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

Page Updated 21-Oct-2002

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