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

Parameter

SLR (monthly basis)

DNS

DNS service availability

0 min downtime = 100% availability

DNS name server availability

£
432 min of downtime (» 99%)

TCP DNS resolution RTT

£
1500 ms, for at least 95% of the queries

UDP DNS resolution RTT

£
500 ms, for at least 95% of the queries

DNS update time

£
60 min, for at least 95% of the probes

RDDS

RDDS availability

£
864 min of downtime (» 98%)

RDDS query RTT

£
2000 ms, for at least 95% of the queries

RDDS update time

£
60 min, for at least 95% of the probes

EPP

EPP service availability

£
864 min of downtime (» 98%)

EPP session-command RTT

£
4000 ms, for at least 90% of the commands

EPP query-command RTT

£
2000 ms, for at least 90% of the commands

EPP transform-command RTT

£
4000 ms, for at least 90% of the commands

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

Critical Function

Emergency Threshold

DNS Service (all servers)

4-hour total downtime / week

DNSSEC proper resolution

4-hour total downtime / week

EPP

24-hour total downtime / week

RDDS (WHOIS/Web-based WHOIS)

24-hour total downtime / week

Data Escrow

Breach of the Registry Agreement
caused by data escrow.

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