2.1 C1If availability of C1 class
services does not meet C1 Service Levels in any given calendar month,
Registry Operator will credit Registrar according to this calculation;
C = (amv/t)*sle
Where:
| C |
= |
number of Transactions to be credited to Registrar
for the calendar month. |
| amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months). |
| t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (for example,
if previous four months had 30, 31, 30, 31 days, these time
period = (30 + 31 + 30 + 31)/4 * 24 hours * 60 minutes = 43,920
minutes). |
| sle |
=
|
service level exception. The number of Unavailable
minutes minus the number of SLA acceptable Unavailable minutes. |
Example:
Registry Operator records 15 minutes of service level exception beyond
the time periods contemplated by the SLA. The current amv is 30,000
total names registered and time period was 43,920 minutes. As such,
Registry Operator will credit Registrar for 10.25 Transactions at
the then Current Pricing Level.
2.2 C2If availability of C2 class
services does not meet C2 Service Levels in any given calendar month,
Registry Operator will credit Registrar according to this calculation;
C = (amv/t)*sle * 60%
Where:
| C |
=
|
number of Transactions to be credited to Registrar
for the calendar month. |
| amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months). |
| t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (see example
in Subsection 2.1). |
| sle |
=
|
service level exception. The number of Unavailable
minutes minus the number of SLA acceptable Unavailable minutes. |
| 60% |
=
|
priority adjustment. |
Example:
Registry Operator records 15 minutes of service level exception beyond
the time periods contemplated by the SLA. The current amv is 30,000
total names registered and time period was 43,920 minutes. As such,
Registry Operator will credit Registrar for 6.15 Transactions at the
then Current Pricing Level.
2.3 C3If availability of C3 services
does not meet C3 Service Levels in any given calendar month, Registry
Operator will credit Registrar according to this calculation;
C = (amv/t)*sle * 30%
Where:
| C |
=
|
number of Transactions to be credited to Registrar
for the calendar month. |
| amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months). |
| t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (see example
in Subsection 2.1). |
| sle |
=
|
service level exception. The number of Unavailable
minutes minus the number of SLA acceptable Unavailable minutes. |
| 30% |
=
|
priority adjustment. |
Example:
Registry Operator records 15 minutes of service level exception beyond
the time periods contemplated by the SLA. The current amv is 30,000
total names registered and the time period was 43,920 minutes. As
such, Registry Operator will credit Registrar for 3.07 Transactions
at the then Current Pricing Level.
2.4 Degraded PerformanceIf the performance
of the transactive systems (OpenXRS API, Whois) does not meet the
performance expectations outlined in Service Levels over the calendar
month in question, Registry Operator will credit Registrar according
to this calculation;
C = (amv/t)*sle * 7.5%
Where:
| C |
=
|
number of Transactions to be credited to Registrar
for the calendar month. |
| amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months). |
| t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (see example
in Subsection 2.1). |
| sle |
=
|
service level exception. The number of Degraded
Performance minutes. |
| 7.5% |
=
|
priority adjustment. |
Example:
Registry Operator records 15 minutes of service level exception beyond
the time periods contemplated by the SLA. The current amv is 30,000
total names registered and time period was 43,920 minutes. As such,
Registry Operator will credit Registrar for 0.77 Transactions at the
then Current Pricing Level.
2.5 Receipt of CreditsIn order for
Registrars to claim credits, the following procedure must be followed:
2.5.1 Issue a Request for SLA Credits.
The claiming Registrar must make a request for credits to Registry
Operator within 7 days of the SLA violation claiming that it experienced
downtime or degraded performance in excess of what is outlined in
Appendix D.
2.5.2 Provide documentation to indicate SLA
violation.
A Registrar may provide documentation in the form of either:
2.5.2.1 Registrar initiated notification(s)
to the Registry Operator of a down time that exceeded SLA limits,
including the trouble ticket number issued by the Registry Operator.
The closing ticket(s) should be included as well in order to determine
the total downtime (unless the closing ticket includes this);
or
2.5.2.2 Notification from the Registry
Operator (with trouble ticket number attached) of down time or
degraded performance. The closing ticket(s) should be included
as well in order to determine the total downtime (unless the closing
ticket includes this).
2.5.2.3 Confirmation of SLA violation:
Upon the request of the Registry Operator, the claiming Registrar
must provide reasonably available server and/or application logs
demonstrating a violation of the SLA limits. The Registrar is
expected to demonstrate response times from point of entry into
the registry server complex to point of exit from the registry
server complex. This will exclude any time taken by establishing
a TCP connection, the SSL handshake and EPP/RRP logon to the registry.
2.5.3 Justification of Volume.
In order to calculate credits, the Registrar should include volume
figures for the past four (4) calendar months, and a certification
that these numbers accurately reflect the LEAST registration activity
that would be covered during the affected SLA outage.
2.5.4 Receipt of Credit.
When the above steps have been completed to the Registry Operator's
satisfaction, the Registry Operator shall provide notification of
the number of credits that will be entered in the Registrar's account
balance and that can be used immediately toward registrations in
the Registry.
3.1 The affected ICANN-Accredited Registrar will
assist Registry Operator by reporting each occurrence of alleged Service
Unavailability to Registry Operator customer service help desk in
the manner required by Registry Operator (i.e., e-mail, fax or telephone)
in order for an occurrence to be treated as Service Unavailability
for purposes of this SLA. Registry Operator will treat all system
performance problems in order of decreasing severity and fix them
within a commercially reasonable period of time. Incidents flagged
by the measurement system will also qualify as ticketed events and
will be classed as Unavailability.
3.2 Registry Operator will perform monitoring from
internally located systems as a means to verify that the conditions
of the SLA are being met.
3.3 The SLA will be reconciled on a quarterly basis.
3.4 The Registrar will have the option to choose
which of the credit calculations described in Section 2 of the SLA
will apply where service level credit overlaps occur. There can be
several types of credits over the same calendar month, but the Registrar
can only claim one type of refund for each event.
3.5 Registry Operator will not attempt to discern
what discount levels were in effect at the specific time of a service
level exception, but rather use the discount level in effect at the
time the credits issue. All service level credits will be paid out
using the appropriate discounts and rate levels reflected by the then
current rate schedule.
3.6 The Registrar may, under reasonable terms and
conditions, audit the reconciliation records for the purposes of verifying
service level performance. The frequency of these audits will be no
more than once every six-month period during the term of the Registry-Registrar
Agreement between Registry Operator and the Registrar.
3.7 Registry Operator's obligations under this
SLA are waived during the first 120 days after the Commencement-of-Service
Date.
3.8 Incident trouble tickets must be opened within
a commercially reasonable period of time.
3.9 In the event that Service Unavailability affects
all Registrars, the Registry Operator is responsible for opening a
blanket trouble ticket and immediately notifying all Registrars of
the trouble ticket number and details.
3.10 Both Registrar and the Registry Operator
agree to use reasonable commercial good faith efforts to establish
the cause of any alleged Service Unavailability. If it is mutually
determined to be a Registry Operator problem, the issue will become
part of the Unplanned Outage Time.
3.11 Registrars must inform the Registry Operator
any time their estimated volume of transactions (excluding check domain
commands), will exceed their previous calendar month's volume by more
than 25%. In the event that a Registrar fails to inform Registry Operator
of a forecasted increase of volume of transactions of 25% or more
and the Registrar's volume increases 25% or more over the previous
month, and should the total volume of transactions added by the Registry
Operator for all Registrars for that month exceed the Registry Operator's
actual volume of the previous month's transactions by more than 20%,
then the Registrar(s) failing to give such notice will not be eligible
for any SLA Credits in that Monthly Timeframe. Registrars shall provide
their forecasts at least 30 days prior to the first day of the next
calendar month. In addition, the Registry Operator agrees to provide
monthly transaction summary reports starting no later than 60 days
after the Commencement-of-Service Date.
3.12 The Registry Operator will notify Registrar
of Planned Outages outside the Planned Outage Period at least 7 days
in advance of such Planned Outage. In addition, Registry Operator
will use reasonable commercial good faith efforts to maintain an accurate
30 day advance schedule of possible upcoming Planned Outages.
3.13 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.
3.14 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.
3.15 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.
3.16 Beginning no later than 60 days after the
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.
3.17 The Registry Operator will provide Service
Availability percentages during each Monthly Timeframe as listed in
Section 4.1 Service Level Matrix of Appendix D.