.BIZ Agreement Appendix 10 | Service Level Agreement (SLA) | (22 August 2013)

Registry Operator and ICANN agree to engage in good faith negotiations to replace this Appendix 10 with a Service Level Agreement equivalent to that of the Service Level Agreement for new gTLD registry operators within 90 days after the final new gTLD Registry Agreement has been approved by the ICANN Board of Directors.

Definitions

1.1.      DNS.  Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.

1.2.      DNSSEC proper resolution.  There is a valid DNSSEC chain of trust from the root trust anchor to a particular domain name, e.g., a TLD, a domain name registered under a TLD, etc.

1.3.      EPP.  Refers to the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.

1.4.      IP address.  Refers to IPv4 or IPv6 addresses without making any distinction between the two.  When there is need to make a distinction, IPv4 or IPv6 is used.

1.5.      Probes.  Network hosts used to perform (DNS, EPP, etc.) tests (see below) that are located at various global locations.

1.6.      RDDS.  Registration Data Directory Services refers to the collective of WHOIS and Web-based WHOIS services.

1.7.      RTT.  Round-Trip Time or RTT refers to the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the last packet of the sequence needed to receive the response.  If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered.

1.8.      SLR.  Service Level Requirement is the level of service expected for a certain parameter being measured in a Service Level Agreement (SLA).

2.         Service Level Agreement Matrix

Registry Operator is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service.  However, note that there is no provision for planned outages or similar; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes.

3.         DNS

3.1.      DNS service availability.  Refers to the ability of the group of listed-as-authoritative name servers of a particular domain name (e.g., a TLD), to answer DNS queries from DNS probes.  For the service to be considered available at a particular moment, at least, two of the delegated name servers registered in the DNS must have successful results from “DNS tests” to each of their public-DNS registered “IP addresses” to which the name server resolves.  If 51% or more of the DNS testing probes see the service as unavailable during a given time, the DNS service will be considered unavailable.

3.2.      DNS name server availability.  Refers to the ability of a public-DNS registered “IP address” of a particular name server listed as authoritative for a domain name, to answer DNS queries from an Internet user.  All the public DNS-registered “IP address” of all name servers of the domain name being monitored shall be tested individually.  If 51% or more of the DNS testing probes get undefined/unanswered results from “DNS tests” to a name server “IP address” during a given time, the name server “IP address” will be considered unavailable.

3.3.      UDP DNS resolution RTT.  Refers to the RTT of the sequence of two packets, the UDP DNS query and the corresponding UDP DNS response.  If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

3.4.      TCP DNS resolution RTT.  Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the DNS response for only one DNS query.  If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

3.5.      DNS resolution RTT.  Refers to either “UDP DNS resolution RTT” or “TCP DNS resolution RTT”.

3.6.      DNS update time.  Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, until the name servers of the parent domain name answer “DNS queries” with data consistent with the change made.  This only applies for changes to DNS information.

3.7.      DNS test.  Means one non-recursive DNS query sent to a particular “IP address” (via UDP or TCP).  If DNSSEC is offered in the queried DNS zone, for a query to be considered answered, the signatures must be positively verified against a corresponding DS record published in the parent zone or, if the parent is not signed, against a statically configured Trust Anchor.  The answer to the query must contain the corresponding information from the Registry System, otherwise the query will be considered unanswered.  A query with a “DNS resolution RTT” 5 times higher than the corresponding SLR, will be considered unanswered.  The possible results to a DNS test are:  a number in milliseconds corresponding to the “DNS resolution RTT” or, undefined/unanswered.

3.8.      Measuring DNS parameters.  Every minute, every DNS probe will make an UDP or TCP “DNS test” to each of the public-DNS registered “IP addresses” of the name servers of the domain name being monitored.  If a “DNS test” result is undefined/unanswered, the tested IP will be considered unavailable from that probe until it is time to make a new test.

3.9.      Collating the results from DNS probes.  The minimum number of active testing probes to consider a measurement valid is 20 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

3.10.    Distribution of UDP and TCP queries.  DNS probes will send UDP or TCP “DNS test” approximating the distribution of these queries.

3.11.    Placement of DNS probes.  Probes for measuring DNS parameters shall be placed as near as possible to the DNS resolvers on the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

4.         RDDS

4.1.      RDDS availability.  Refers to the ability of all the RDDS services for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System.  If 51% or more of the RDDS testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable.

4.2.      WHOIS query RTT.  Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response.  If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

4.3.      Web-based-WHOIS query RTT.  Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request.  If Registry Operator implements a multiple-step process to get to the information, only the last step shall be measured.  If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

4.4.      RDDS query RTT.  Refers to the collective of “WHOIS query RTT” and “Web-based- WHOIS query RTT”.

4.5.      RDDS update time.  Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made.

4.6.      RDDS test.  Means one query sent to a particular “IP address” of one of the servers of one of the RDDS services.  Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered.  Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered.  The possible results to an RDDS test are:  a number in milliseconds corresponding to the RTT or undefined/unanswered.

4.7.      Measuring RDDS parameters.  Every 5 minutes, RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each RDDS service of the TLD being monitored and make an “RDDS test” to each one.  If an “RDDS test” result is undefined/unanswered, the corresponding RDDS service will be considered as unavailable from that probe until it is time to make a new test.

4.8.      Collating the results from RDDS probes.  The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

4.9.      Placement of RDDS probes.  Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

5.         EPP

5.1.      EPP service availability.  Refers to the ability of the TLD EPP servers as a group, to respond to commands from the Registry accredited Registrars, who already have credentials to the servers.  The response shall include appropriate data from the Registry System.  An EPP command with “EPP command RTT” 5 times higher than the corresponding SLR will be considered as unanswered.  If 51% or more of the EPP testing probes see the EPP service as unavailable during a given time, the EPP service will be considered unavailable.

5.2.      EPP session-command RTT.  Refers to the RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command.  For the login command it will include packets needed for starting the TCP session.  For the logout command it will include packets needed for closing the TCP session.  EPP session commands are those described in section 2.9.1 of EPP RFC 5730.  If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

5.3.      EPP query-command RTT.  Refers to the RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command.  It does not include packets needed for the start or close of either the EPP or the TCP session.  EPP query commands are those described in section 2.9.2 of EPP RFC 5730.  If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

5.4.      EPP transform-command RTT.  Refers to the RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command.  It does not include packets needed for the start or close of either the EPP or the TCP session.  EPP transform commands are those described in section 2.9.3 of EPP RFC 5730.  If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

5.5.      EPP command RTT.  Refers to “EPP session-command RTT”, “EPP query-command RTT” or “EPP transform-command RTT”.

5.6.      EPP test.  Means one EPP command sent to a particular “IP address” for one of the EPP servers.  Query and transform commands, with the exception of “create”, shall be about existing objects in the Registry System.  The response shall include appropriate data from the Registry System.  The possible results to an EPP test are:  a number in milliseconds corresponding to the “EPP command RTT” or undefined/unanswered.

5.7.      Measuring EPP parameters.  Every 5 minutes, EPP probes will select one “IP address” of the EPP servers of the TLD being monitored and make an “EPP test”; every time they should alternate between the 3 different types of commands and between the commands inside each category.  If an “EPP test” result is undefined/unanswered, the EPP service will be considered as unavailable from that probe until it is time to make a new test.

5.8.      Collating the results from EPP probes.  The minimum number of active testing probes to consider a measurement valid is 5 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

5.9.      Placement of EPP probes.  Probes for measuring EPP parameters shall be placed inside or close to Registrars points of access to the Internet across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

6.         Emergency Thresholds

The following matrix presents the emergency thresholds that, if reached by any of the services mentioned above for the TLD, may (at ICANN’s discretion) cause the emergency transition of the TLD as specified in Section 3.6 of this Agreement .

7.         Emergency Escalation

Escalation is strictly for purposes of notifying and investigating possible or potential issues in relation to monitored services.  The initiation of any escalation and the subsequent cooperative investigations do not in themselves imply that a monitored service has failed its performance requirements.

Escalations shall be carried out between ICANN and Registry Operators, Registrars and Registry Operator, and Registrars and ICANN.  Registry Operators and ICANN must provide said emergency operations departments.  Current contacts must be maintained between ICANN and Registry Operators and published to Registrars, where relevant to their role in escalations, prior to any processing of an Emergency Escalation by all related parties, and kept current at all times.

7.1.      Emergency Escalation initiated by ICANN

Upon reaching 10% of the Emergency thresholds as described in Section 6 of this Appendix, ICANN’s emergency operations will initiate an Emergency Escalation with the relevant Registry Operator.  An Emergency Escalation consists of the following minimum elements:  electronic (i.e., email or SMS) and/or voice contact notification to the Registry Operator’s emergency operations department with detailed information concerning the issue being escalated, including evidence of monitoring failures, cooperative trouble-shooting of the monitoring failure between ICANN staff and the Registry Operator, and the commitment to begin the process of rectifying issues with either the monitoring service or the service being monitoring.

7.2.      Emergency Escalation initiated by Registrars

Registry Operator will maintain an emergency operations department prepared to handle emergency requests from registrars.  In the event that a registrar is unable to conduct EPP transactions with the registry for the TLD because of a fault with the Registry Service and is unable to either contact (through ICANN mandated methods of communication) the Registry Operator, or the Registry Operator is unable or unwilling to address the fault, the registrar may initiate an emergency escalation to the emergency operations department of ICANN.  ICANN then may initiate an emergency escalation with the Registry Operator as explained above.

7.3.      Notifications of Outages and Maintenance

In the event that a Registry Operator plans maintenance, they will provide related notice to the ICANN emergency operations department, at least, 24 hours ahead of that maintenance.  ICANN’s emergency operations department will note planned maintenance times, and suspend Emergency Escalation services for the monitored services during the expected maintenance outage period.

If Registry Operator declares an outage, as per their contractual obligations with ICANN, on services under a service level agreement and performance requirements, it will notify the ICANN emergency operations department.  During that declared outage, ICANN’s emergency operations department will note and suspend emergency escalation services for the monitored services involved.

8.         Covenants of Performance Measurement

8.1.      No interference.  Registry Operator shall not interfere with measurement Probes, including any form of preferential treatment of the requests for the monitored services.  Registry Operator shall respond to the measurement tests described in this Appendix as it would do with any other request from Internet users (for DNS and RDDS) or registrars (for EPP).

8.2.      ICANN testing registrar.  Registry Operator agrees that ICANN will have a testing registrar used for purposes of measuring the SLRs described above.  Registry Operator agrees to not provide any differentiated treatment for the testing registrar other than no billing of the transactions.  ICANN shall not use the registrar for registering domain names (or other registry objects) for itself or others, except for the purposes of verifying contractual compliance with the conditions described in this Agreement.

8.3.      Publishing of SLA measurements.  Registry Operator agrees that ICANN may publish on its website for each SLR whether Registry Operator met the applicable performance measurement as set forth in this Appendix 10 (“Threshold Measurements”).  Additionally, ICANN agrees that it shall use commercially reasonable efforts to provide Registry Operator with a monthly report within twenty (20) calendar days following the end of each calendar month, describing in reasonable detail each of the performance measurements and testing performed by ICANN during such month with regard to the TLD and the SLRs described in this Appendix 10 (such reports and the data set forth therein, the “Measurements Data”).  Except for Threshold Measurements, ICANN shall not publish Registry Operator’s Measurements Data until Registry Operator provides written consent to ICANN to publish the Measurements Data, which such consent shall be binding on Registry Operator.  In the event that Registry Operator disputes the Measurements Data, ICANN shall publish the Registry Operator’s response to such Measurements Data alongside the Measurements Data itself.