UserPreferences

GssSlas

Service Level Agreements

TableOfContents

  1. Introduction
  2. Service Availability
    1. Service Availability - GRS
    2. Service Availability — XRIAuthority
  3. Planned Outage
    1. Planned Outage Duration
    2. Planned Outage Timeframe
    3. Planned Outage Notification
  4. Extended Planned Outage
    1. Extended Planned Outage Duration
    2. Extended Planned Outage Timeframe
    3. Extended Planned Outage Notification
  5. Processing Time
    1. Processing Time — Add, Modify, Delete
    2. Processing Time — Query XRI
    3. Processing Time — Public Resolver
    4. Update Frequency to the Public Resolver
  6. Cross-Network PublicResolver Performance Requirements
  7. Obligations

1. Introduction

The GRSP shall use commercially reasonable efforts to provide Registry Services for each Global Registry Service. The GRSP is obligated to maintain the Performance Specifications defined in this GSS section.

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

2.1. Service Availability - GRS

Service Availability as it applies to the GRS refers to the ability of the GRS to respond to Registrars that access and use the GRS through the EPP protocol defined in GssTechSpecs. GRS Unavailability will be logged with the GRSP as Unplanned Outage Minutes. The committed Service Availability for GRS is 99.9% and the Service Level Measurement Period is monthly.

2.2. Service Availability — XRIAuthority

Service Availability as it applies to the XRIAuthority refers to the ability of the XRIAuthority to resolve an XRI query from an XRI Resolver. XRIAuthority Unavailability will be logged with the GRSP as Unplanned Outage Minutes. The committed Service Availability for Nameserver is 99.999% and the Service Level Measurement Period is annually.

3. 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.1. Planned Outage Duration

The Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the GRSP 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:

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

3.3. Planned Outage Notification

The GRSP 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 GRSP must notify its Registrars. The Planned Outage Notification for the Core Services is as follows:

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

4.1. Extended Planned Outage Duration

The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the GRSP 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:

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

4.3. Extended Planned Outage Notification

The GRSP 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 GRSP must notify its Registrars. The Extended Planned Outage Notification for the Core Services is as follows:

5. 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 GRSP 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 GRS 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 GRSP 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.

5.1. Processing Time — Add, Modify, Delete

5.2. Processing Time — Query XRI

5.3. Processing Time — Public Resolver

5.4. Update Frequency to the Public Resolver

PublicResolver updates occur via Registrars requests via EPP through the GRS. Update Frequency Performance Specifications are a C3 priority level.

The committed Performance Specification with regard to Update Frequency for the PublicResolver is 15 minutes for 95% of the transactions. That is, 95% of the updates to the PublicResolver 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 PublicResolver. Update Frequency Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis.

6. Cross-Network PublicResolver Performance Requirements

PublicResolver round-trip-time and packet loss from the Internet are important elements of the quality of service provided by the GRSP. These characteristics, however, are affected by Internet performance and therefore cannot be closely controlled by GRSP. Accordingly, these requirements are not matters subject to Service Level Exceptions and credits under the Service Level Agreement.

7. Obligations

  1. Except in the case of cross-network nameserver performance (which is not a subject of this Service Level Agreement), GRSP will perform monitoring from internally located systems as a means to verify that the conditions of the SLA are being met.

  2. Upon written request, and at the sole expense of the requesting Registrar(s), GRSP will retain an independent third party to be selected by GRSP with the consent of the Registrar(s). The Registrar may, under reasonable terms and conditions, audit the reconciliation records for the purposes of verifying measurements of the Performance Specifications. The frequency of these audits will be no more than once yearly during the term of the agreement between GRSP and the Registrar.

  3. GRSP's obligations under this SLA are waived during the first 120 days after the Commencement-of-Service Date.

  4. A Registrar must report each occurrence of alleged occasion of Unavailability of Core Services to the GRSP customer service help desk in the manner required by the GRSP (i.e., e-mail, fax, telephone) in order for an occurrence to be treated as Unavailable for purposes of the SLE.

  5. In the event that the Core Services are Unavailable to an individual Registrar, GRSP will use commercially reasonable efforts to re-establish the affected Core Services for such Registrar as soon as reasonably practicable. In the event that the Unavailability of Core Services affects all Registrars, the GRSP is responsible for opening a blanket trouble ticket and immediately notifying all Registrars of the trouble ticket number and details.

  6. Both Registrar and the GRSP agree to use reasonable commercial good faith efforts to establish the cause of any alleged Core Services Unavailability. If it is mutually determined to be a GRSP problem, the issue will become part of the Unplanned Outage minutes.

  7. Beginning no later than 120 days post Commencement-of-Service Date, the GRSP will publish preliminary weekly system performance and availability reports. GRSP will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided.

  8. The GRSP will use commercially reasonable efforts to restore the critical systems of the Core Services within 24 hours after the termination of a force majeure event and restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered Service Unavailability.

  9. Incident trouble tickets must be opened within a commercially reasonable period of time.