Unsponsored TLD Agreement: Appendix D (.name)

Unsponsored TLD Agreement: Appendix D (.name)

(29 Jun 2001)

Performance Specification

Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry 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 and, when applicable, allow for calculation of the SLA Credit payable to ICANN-Accredited Registrars pursuant to Appendix E of the Registry Agreement.

1. Conventions.

1.1 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 "Claim Month" means the calendar month when SRS Unavailability occurred, for which the ICANN-Accredited Registrar can claim SLA Credit.

2.2 "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.3 "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.4 "DNS Service" shall mean the service complying with RFC 1034 made available on TCP/UDP port 53 on selected servers as defined in Appendix C.

2.5 "ICANN-Accredited Registrar," as used in this Appendix D, refers to an "ICANN-Accredited Registrar" as defined in Subsection 1.8 of the Registry Agreement that has a Registry-Registrar Agreement in effect with Registry Operator.

2.6 "Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 Greenwich Mean Time (GMT).

2.7 "Performance Specifications" refers to a description of the functional attributes of a particular system or service. The attributes outlined in a Performance Specification are measurable.

2.8 "Planned Outage" means the periodic pre-announced occurrences when the SRS Service will be stopped for maintenance or care. Planned Outages will be published at least one week in advance to the Registrar Community in the form on an email to each ICANN-Accredited Registrar and a notice posted on Registry Operator's web site. Planned Outages will be scheduled only during the following window period of time each week, 0600 - 1500 GMT on Sunday (the "Planned Outage Period"). The beginning of this Planned Outage Period may be changed from time to time by the Registry Operator, in its sole discretion, upon prior notice to each ICANN-Accredited Registrar. Planned Outages will not exceed 4 hours/per calendar week beginning at 1200 GMT Monday nor total more than 8 hours/per month. Notwithstanding the foregoing, Registry Operator may incur one (1) additional Planned Outage of up to 12 hours in duration during the Planned Outage Period and the immediately following three hours for major systems or software upgrades ("Extended Planned Outages"). These Extended Planned Outages represent total allowed Planned Outages for the month.

2.9 "Registrar Community" refers to all "ICANN-Accredited Registrars," as that term is defined for purposes if this Appendix D.

2.10 "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 service being tested and back again. Usually measured in milliseconds.

2.11 "SLA" means the Service Level Agreement between Registry Operator and ICANN-Accredited Registrar attached as Appendix E to the Registry Agreement.

2.12 "SLA Credit" means those credits available to the ICANN-Accredited Registrar pursuant to the SLA.

2.13 "SRS Service" shall mean the service accessible to the ICANN-Accredited Registrar for operating on the main registry data store using the defined protocol (RRP/EPP) for Registry-Registrar interaction. It does not include WWW, FTP, SCP or other services not associated directly with adding, deleting or modifying domain-names.

2.14 "SRS Availability" means when the SRS Service is operational and predictably responding in a commercially reasonable manner. By definition, this does not include Planned Outages or Extended Planned Outages. System Availability will be monitored and recorded by the Registry Operator from multiple datapoints within the Internet. The following formula shall be used for calculating SRS Availability:

where:

A = SRS Availability in percent
UDT = Unplanned Downtime in hours for the Monthly Timeframe
TA = Time available in hours for the Monthly Timeframe

The following periods will not be included in calculating SRS Availability:

2.14.1 All periods of SRS Unavailability that result from the effects of scheduled service maintenance;

2.14.2 All periods of SRS Unavailability that result from events locally at the ICANN-Accredited Registrar, or events outside of Registry Operator's control; and

2.14.3 All periods of SRS Unavailability that result from events that can be classified as malicious attacks, such as denial of service ("DOS") attacks.

2.15 "SRS Unavailability" means when, as a result of a failure of systems within the Registry Operator's control, the ICANN-Accredited Registrar is unable to either:

2.15.1 establish a session with the SRS gateway which shall be defined as:

2.15.1.1 successfully completing a TCP session start;

2.15.1.2 successfully completing the SSL authentication handshake; and

2.15.1.3 successfully completing the registry registrar protocol ("RRP") session command.

2.15.2 Execute a 3 second average round trip for 95% of the RRP check domain commands and/or less than 5 second average round trip for 95% of the RRP add domain commands, from the SRS gateway, through the SRS system, back to the SRS gateway as measured during each Monthly Timeframe.

2.16 "System Services" shall mean the list of services provided in Section 3 - System Services.

2.17 "Transaction" shall mean completion of a defined SRS command.

2.18 "Unplanned Downtime" shall mean all of the following:

2.18.1 The amount of time recorded between a trouble ticket first being opened by the Registry Operator in response to an ICANN-Accredited Registrar's claim of SRS Unavailability for that ICANN-Accredited Registrar through the time when the ICANN-Accredited Registrar and Registry Operator agree the SRS Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered SRS Unavailability only for those ICANN-Accredited Registrars impacted by the outage as evidenced by their submission of an SLA claim;

2.18.2 The amount of time recorded between a trouble ticket first being opened by the Registry Operator in the event SRS Unavailability that affects all ICANN-Accredited Registrars through the time when the Registry Operator resolves the problem with a final fix or a temporary work around, and the trouble ticket is closed;

2.18.3 The amount of time the Planned Outage exceeds the limits established in Subsection 2.8 above; and

2.18.4 The amount of time that the Planned Outage time occurs outside the window of time established in Subsection 2.8 above.

2.19 "Whois Service" shall mean the information service made available on TCP port 43 on selected servers and described more fully in Appendix O.

3. System Services.

The following table lists the System Services for which availability and performance requirements are established. System Services shall meet the availability and performance levels described in Section 4. The availability and performance levels are the subject of the SLA or the requirements of Subsection 3.3 of the Registry Agreement.

4. Service Levels (Availability and Performance)

4.1 DNS Service. Registry Operator considers the DNS Service to be the most critical service of the Registry, and will ensure that unavailability times are kept to an absolute minimum. The hardware, software and geographic redundancy built into the DNS Service will reduce unavailability times to a minimum.

4.1.1 DNS Service Availability = 99.999%. Registry Operator will provide the above-referenced DNS Service Availability. Registry Operator will log DNS Service unavailability (a) when such unavailability is detected by monitoring tools described in Exhibit A, or (b) once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail, or fax as described in the customer support escalation procedures described in Appendix F. The committed Performance Specification is 99.999% measured on a monthly basis.

4.1.2 Performance Level. At any time, each nameserver (including a cluster of nameservers addressed at a shared IP address) MUST be able to handle a load of queries for DNS data that is three times the measured daily peak (averaged over the Monthly Timeframe) of such requests on the most loaded nameserver.

4.1.3 Response Time. The DNS Service will meet the Cross-Network Nameserver Performance Requirements described in Section 2 of Exhibit A to this Appendix D.

4.2 SRS Service. Registry Operator provides built-in redundancy into the SRS Service in the form of 2 databases capable of running the SRS Service. Such redundancy will ensure that SRS Unavailability is kept to an absolute minimum.

4.2.1 SRS Service Availability = 99.4%. Registry Operator will provide the above-referenced SRS Service Availability. Registry Operator will log SRS unavailability once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail, or fax as described in the customer support escalation procedures described in Appendix F. The committed Performance Specification is 99.4% measured on a monthly basis.

4.2.2 Performance Level. The Registry Operator will, on average, be capable of processing 40 Transactions per second.

4.2.3 Response Time. The SRS Service will have a worst-case response time of 3 seconds, not including network delays, before it will be considered Unavailable.

4.3 Whois Service. Registry Operator provides built-in redundancy into the Whois Service in the form of multiple servers running in 2 different data centers. Such redundancy will ensure that unavailability of the Whois Service is kept to an absolute minimum.

4.3.1 Whois Service Availability = 99.4%. Registry Operator will provide the above-referenced Whois Service Availability. Registry Operator will log Whois Service unavailability (a) when such unavailability is detected by monitoring tools described in Exhibit A, or (b) once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail, or fax as described in the customer support escalation procedures described in Appendix F. The committed Performance Specification is 99.4% measured on a monthly basis.

4.3.2 Performance Level. The Registry Operator will offer a Whois Service to query certain domain name information. Whois Service will, on average, be able to handle 200 queries per second.

4.3.3 Response Times. The Whois Service will have a worst-case response time of 1.5 seconds, not including network delays, before it will be considered unavailable.

5. Measurement.

Registry Operator will monitor the Service Levels in Section 4 in accordance with the following principles.

5.1 SRS Service/Component Monitoring: The Monitoring Tools used by Registry Operator will be the following:

5.1.1 TIVOLI Management Environment (TME 10). A suite of distributed systems management products, provides management of network computing resources of many different types from a single point. TME 10 products provide a consistent interface to different operating systems and services, and allow administrators to control users, systems and applications from one desktop. The Registry Operator will use TME 10 to manage and monitor applications, computers, networks and backup.

5.1.2 Big Brother. This tool is designed to let system administrators monitor network, application and computer performance in near real-time, from any web browser, anywhere. Big Brother uses a client-server architecture combined with methods, which both push and pull data. Network testing is done by polling all monitored services from a single machine and reporting these results to a central location. The Registry Operator will use Big Brother to monitor network, computer and application status.

5.1.3 The Multi Router Traffic Grapher (MRTG). This is a tool to monitor the traffic load on network-links. MRTG generates HTML pages containing GIF images that provide a LIVE visual representation of this traffic. The Registry Operator will use this tool for additional monitoring of services, computers and applications using SNMP.

5.2 Performance Monitoring: The System Services defined in this Appendix will be sampled and tested as to their performance pursuant to the schedule attached hereto as Exhibit A.

6. Responsibilities of the Parties.

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

6.2 The Registry Operator will update the Whois Service on a near real time basis. The Whois service database is generated from the master database at the main site, and converted into a format usable by the Whois server by the update server. The initial service will be static; data will be generated and transmitted to Whois servers at regular intervals. The second phase will provide near real-time updates to the Whois database; this will be achieved by sending changes to the database if the volume of changes is below a Registry Operator-decided threshold. Past this threshold, the standard full database transfer will be used. Data is distributed from the update server after registrations have been accepted to the master database, unless a large volume of registrations are to be processed in which case the update server will batch up the data and transmit this every two minutes. Updates transmitted from the update server will be received at the Whois servers by an update application ("Whois update daemon"). The Registry Operator will notify ICANN-Accredited Registrars in advance when major 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 5 minutes of a Transaction.

6.4 Beginning no later than 120 days after the Commencement-of Service Date, the Registry Operator will publish preliminary weekly System Service performance and availability reports. Registry Operator will use best efforts to finalize these reports no later than 30 after the preliminary reports are provided.

6.5 The Registry Operator will provide System Service availability percentages during each Monthly Timeframe as listed in Section 4 - Service Levels (Availability and Performance) to ICANN and to ICANN-Accredited Registrars..

6.6 The Registry Operator will use commercially reasonable efforts to restore the critical systems of the SRS Service within 48 hours in the event of Force Majeure. Further, the Registry Operator will make commercially reasonable efforts to restore full functionality of the SRS Service within 72 hours. Outages due to Force Majeure will not be considered Unavailability.

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.

7.3 The following table defines the levels of performance the Registry Operator will adhere to:

EXHIBIT A
Sampling and Testing Schedule

1. Monitoring and Testing Tools

Tool: TIVOLI Management Environment (TME 10). A suite of distributed system management products, provides management of network computing resources of many different types from a single point. TME 10 products provide a consistent interface to different operating types from a single point. TME 10 products provide a consistent interface to different operating systems and services, and allow administrators to control users, systems and applications from one desktop. The Registry Operator will use TME 10 to manage and monitor applications, computers, networks and backup.

Schedule: Continuous Monitoring. Daily Reports.

Tool: Big Brother. This tool is designed to let system administrators monitor network, application and computer performance in near real-time, from any web browser, anywhere. Big Brother uses a client-server architecture combined with methods, which both push and pull data. Network testing is done by polling all monitored services from a single machine and reporting these results to a central location. The Registry Operator will use Big Brother to monitor network, computer and application status.

Schedule: Continuous Monitoring. Daily Reports.

Tool: The Multi Router Traffic Grapher (MRTG). This is a tool to monitor the traffic load on network-lines. MRTG generates HTML pages containing GIF images that provide a LIVE visual representation of this traffic. The Registry Operator will use this tool for additional monitoring of services, computers and applications using SNMP.

Schedule: Continuous Monitoring. Daily Reports.

2. Nameserver Performance Measurements

2.1. 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 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:

2.1.1. The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .name nameservers and observing the responses from the .name nameservers. (These strings of requests and response 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.1.2. Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected .name 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.1.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.1.3.1. The Round-trip time and packet loss from each measurement location to at least one .name nameserver must not exceed the required values.

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

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

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

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

2.1.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.1.7. If, following that opportunity to cure, the .name 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.1.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.