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 the ICANN-Accredited Registrars accredited by ICANN
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.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 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 .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.
