2.1 C1–If 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 C2–If 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 C3–If 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 Performance–If the performance of the transactive systems
(OpenXRS API, Whois) does not meet the performance expectations
outlined in Service Levels over the 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 Unavailable minutes minus the number of SLA acceptable
Unavailable 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 Credits–In 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 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.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.g., 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 occurs. 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 120 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 5 minutes
of 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 root-servers.
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 120 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 - Service Levels of Appendix
D.
