ICANN Logo

.NAME Agreement Appendix 7
Functional and Performance Specifications
(15 August 2007)

1.   Introduction

These functional specifications for the Registry TLD consist of the following parts:

2.  Definitions

2.1 "DNS" means the Internet domain name system.
 
2.2 "EPP" means the Extensible Provisioning Protocol, which is the protocol used by the Registry System.
 
2.3 "ICANN" means the Internet Corporation for Assigned Names and Numbers.
 
2.4 "Registered Name" means a registered Second Level Domain (SLD) E-mail address, registered third level domain name or registered second level domain name, collectively.
 
2.5 "Registered Item" refers to either a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, or a SLD E-mail Address or a Defensive Registration or a Namewatch Registration, about which GNR or an affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. An item in a Registry Database may be a Registered Item even though it does not appear in a TLD zone file (e.g., a registered but inactive name).
 
2.6 "Registry Database" means a database, comprised of data about one or more DNS domain names, SLD E-mail Addresses or Defensive Registrations within the domain of the Registry TLD that is used to generate either DNS resource records that are published authoritatively, responses to domain-name availability lookup requests, Whois queries or other services related to the Registered Items, for some or all of those names.
 
2.7 "Email Forwarding" means the second level email forwarding service operated by the Registry Operator in the .name TLD.
 
2.8 "SLD E-mail Address" means an e-mail address consisting of a second level domain name within the domain of the Registry TLD and a defined user name (e.g., john@smith.name), about which Registry Operator (or an affiliate engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance.
 
2.9 "Registered Item Holder" means the holder of a Registered Item.
 
2.10 "The "Registrar Tool Kit" comprises the EPP, APls, documents and Software.
 
2.11 "Registry TLD" means the .name TLD.
 
2.12 The "Registry System" means the system operated by GNR and its technology partners for Registered Items in the Registry TLD.
 
2.13 "Software" means reference client software intended to allow Registrar to develop its system to register second-level domain names through the Registry System.
 
2.14 A "TLD" means a top-level domain of the DNS.
 
2.15 Other terms used in this Agreement as defined terms shall have the meanings ascribed to them in the context in which they are defined.

3.  Registry-Registrar Interface Protocol

3.1 Extensible Provisioning Protocol (EPP): Registry Operator has implemented, and shall maintain support of, the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3733, 3734, and 3735 published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary.
3.2 In addition to the standard EPP mappings, the Registry Operator has additional mappings for NameWatch, Defensive Registrations and Email Forwarding.

4.  Supported initial and renewal registration periods

4.1 Initial registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms of up to ten years in one year increments.
 
4.2 Renewal registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms not exceeding a total of ten years.
 
4.3 Holder-Authorized Transfers: Upon change of sponsorship of the registration of a Registered Name from one registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the Registered Name shall be extended by a minimum of one year, provided that the maximum term of the registration as of the effective date of the sponsorship change shall not exceed ten years.
 
4.4 ICANN-Approved Transfers: The change of sponsorship of registration of Registered Names from one registrar to another, according to Part B of the ICANN Policy on Transfer of Registrations between Registrars shall not result in the extension of the term of the registration and Registry Operator may assist in such change of sponsorship.

5.   Grace and Pending Period Policy

5.1

This section describes Registry Operator's practices for operational "Grace" and "Pending" periods, including relationships among sequential operations that occur within given time frames. A Grace Period refers to a specified number of calendar days following a Registry operation in which a Registered Name action may be reversed and a credit may be issued to a registrar. Relevant registry operations in this context are:

  • Registration of a new Registered Name
  • Extension of an existing Registered Name
  • Auto-Renew of an existing Registered Name
  • Transfer of an existing Registered Name
  • Deletion of an existing Registered Name.
5.2 Extension of a registration period is accomplished using the EPP RENEW command or by auto-renewal; registration is accomplished using the EPP CREATE command; deletion is accomplished using the EPP DELETE command; transfer is accomplished using the EPP TRANSFER command or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part.
 
5.3 There are four grace periods provided by Registry Operator's Shared Registration System: Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period, and Transfer Grace Period
 
5.4

A Pending Period refers to a specified number of calendar days following a Registry operation in which final Registry action is deferred before the operation may be completed. Relevant Registry operations in this context are:

  • Transfer of an existing Registered Name

  • Deletion of an existing Registered Name
5.5 Grace Periods
 
 
 5.5.1

Add Grace Period

The Add Grace Period is a specified number of calendar days following the initial registration of a Registered Name. The current value of the Add Grace Period for all registrars is five (5) calendar days. If a Delete, Renew/Extend, or Transfer operation occurs within the five calendar days, the following rules apply:
(a)   Delete. If a Registered Name is deleted within the Add Grace Period, the sponsoring Registrar at the time of the deletion is credited for the amount of the registration; provided, however, that Registry Operator shall have the right to charge Registrars a fee as set forth on Exhibit A to the Registry-Registrar Agreement for excess deletes during the Add Grace Period. The Registered Name is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.6 for a description of overlapping grace period exceptions.
 
(b) Excess Deletes. An Excess Deletion Fee may be charged pursuant to Appendix 8, Exhibit A of the Registry Agreement when the number of deleted registrations within the five-day add grace period is in excess of ninety percent (90%) of the total number of initial registrations made by the registrar over a relevant time period as determined by the Registry Operator.
 
(c) Renew/Extend. If a Registered Name is renewed/extended within the Add Grace Period, there is no credit for the add. The account of the sponsoring Registrar at the time of the extension will be charged for the initial add plus the number of years the registration is extended. The expiration date of the Registered Name is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Renew/Extend operation.
 
(d) Holder-Authorized Transfers: Transfers under Part A of the ICANN Policy on Transfer of Registrations between Registrars may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the Registered Name and is enforced by the SRS.
 
(e) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Add Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred Registered Names are not affected. The losing Registrar's account is charged for the initial add.
 
  5.5.2

Renew/Extend Grace Period

The Renew/Extend Grace Period is a specified number of calendar days following the renewal/extension of a Registered Name period. The current value of the Renew/Extend Grace Period is five (5) calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:

 
(a)   Delete. If a Registered Name is deleted within the Renew/Extend Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the renew/extend fee. The Registered Name is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.6 for a description of overlapping grace period exceptions.
 
    (b) Renew/Extend. A Registered Name can be extended within the Renew/ExtendGrace Period for up to a maximum of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.
 
    (c) Holder-Authorized Transfers: If a Registered Name is transferred within the Renew/Extend Grace Period, there is no credit to the losing registrar for the renewal fee. The expiration date of the Registered Name is extended by one year and the years added as a result of the Extend remain on the Registered Name up to a maximum of 10 years.
 
    (d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Renew/Extend Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is not credited for the Renew/Extend operation.
 
  5.5.3

Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An auto-renewal occurs if a Registered Name is not renewed by the expiration date; in this circumstance the registration will be automatically renewed by the system the first day after the expiration date. The current value of the Auto-Renew Grace Period is forty-five (45) calendar days. If a Delete, Extend, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply:

 
    (a)   Delete. If a Registered Name is deleted within the Auto-Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the Auto-Renew fee. The Registered Name is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.6 for a description of overlapping grace period exceptions.
 
    (b) Renew/Extend. A Registered Name can be extended within the Auto-Renew Grace Period for up to a maximum of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.
 
    (c) Holder-Authorized Transfers: If a Registered Name is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled. The expiration date of the Registered Name is extended by one year up to a maximum of ten years and the gaining Registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum.
 
    (d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is not credited for the Auto-Renew.
 
  5.5.4

Transfer Grace Period

The Transfer Grace Period is a specified number of calendar days following the transfer of a Registered Name according to Part A of the ICANN Policy on Transfer of Registrations between Registrars. The current value of the Transfer Grace Period is five (5) calendar days. If a Delete, Renew/Extend, or Transfer occurs within that five calendar days, the following rules apply:

 
    5(a) Delete. If a Registered Name is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The Registered Name is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.6 for a description of overlapping grace period exceptions.
 
    (b) Renew/Extend. If a Registered Name is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be charged for the number of years the registration is extended. The expiration date of the Registered Name is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Renew/Extend operation.
 
    (c) Holder-Authorized Transfers: If a Registered Name is transferred within the Transfer Grace Period, there is no credit. The expiration date of the Registered Name is extended by one year up to a maximum term of ten years. The ICANN Policy on Transfer of Registrations between Registrars does not allow transfers within the first 60 days after another transfer has occurred; it is registrars' responsibility to enforce this restriction.
 
    (d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Transfer Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Transfer operation that occurred prior to the Bulk Transfer.
 
5.6 Overlapping Grace Periods
 
  5.6.1

If an operation is performed that falls into more than one grace period, the actions appropriate for each grace period apply (with some exceptions as noted below).

  • If a Registered Name is deleted within the Add Grace Period and the Renew/Extend Grace Period, then the Registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done. The Registered Name is removed from the Registry database and is immediately available for registration by any Registrar.

  • If a Registered Name is auto-renewed, then extended, and then deleted within the Renew/Extend Grace Period, the registrar will be credited for any Auto-Renew fee charged and the number of years for the extension. The years that were added to the Registered Name's expiration as a result of the auto-renewal and extension are removed.
  5.6.2 Overlap Exception
  • If a Registered Name is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example, if a Registered Name is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first and second transfers, then only the last transfer is credited to Registrar C.

  • If a Registered Name registration is extended within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.
5.7 Pending Periods
 
  5.7.1

Transfer Pending Period

The Transfer Pending Period is a specified number of calendar days following a request from a registrar (registrar A) to transfer a Registered Name in which the current registrar of the Registered Name (registrar B) may explicitly approve or reject the transfer request. The current value of the Transfer Pending Period is five (5) calendar days for all registrars. The transfer will be finalized upon receipt of explicit approval or rejection from the current registrar (registrar B). If the current registrar (registrar B) does not explicitly approve or reject the request initiated by registrar A, the registry will approve the request automatically after the end of the Transfer Pending Period. During the Transfer Pending Period:

  • EPP TRANSFER request or EPP RENEW request is denied
  • AUTO-RENEW is allowed
  • EPP DELETE request is denied
  • Bulk Transfer operations are allowed
  • EPP UPDATE request is denied

After a transfer of a Registered Name, the EPP TRANSFER request may be denied for 60 days.

 
  5.7.2

Pending Delete Period

A domain name is placed in PENDING DELETE status if it is deleted outside any applicable grace periods. A Registered Name that is in PENDING DELETE status will not be included in the zone file. All registrar requests to modify or otherwise update a Registered Name in PENDING DELETE status will be rejected. A Registered Name is purged from the registry database a specified number of calendar days after it is placed in PENDING DELETE status. The current length of this Pending Delete Period is five (5) calendar days.

6.   Nameserver functional specifications

Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, and 2182.

7.   Other functional specifications

The email forwarding service will be operated as an SMTP service accepting standard email on TCP port 25, and forwarding to the account specified during registration of or subsequent updates to the registration.

The Registry operator reserves the right to limit the maximum accepted size of email and also the number of emails forwarded per account to ensure service quality. The operator may also undertake other necessary actions needed to ensure the stable operation of the service. This could include, but is not limited to deferring and blocking incoming connections and data.

The Registry operator may introduce concepts such as SenderID, SPF and other systems into the email solution. The Registry will issue an advisory statement to Registrars seven days in advance of implementation.

The Registry will continue to operate family-pages for the shared second levels in the Registry.


8.   Patch, update, and upgrade policy

Registry Operator may issue periodic patches, updates or upgrades to the Software, EPP or APIs ("Licensed Product") licensed under the Registry- Registrar Agreement (the "Agreement") that will enhance functionality or otherwise improve the Shared Registration System under the Agreement. For the purposes of this Part 5 of Appendix 7, the following terms have the associated meanings set forth herein.

Each Update and Upgrade causes a change in version.

* Patches do not require corresponding changes to client applications developed, implemented, and maintained by each registrar.

* Updates may require changes to client applications by each registrar in order to take advantage of the new features and/or capabilities and continue to have access to the Shared Registration System.

* Upgrades require changes to client applications by each registrar in order to take advantage of the new features and/or capabilities and continue to have access to the Shared Registration System.

Registry Operator, in its sole discretion, will deploy Patches both inside and outside scheduled and announced Shared Registration System maintenance periods.

For Updates (where client changes are not required), Registry Operator will give each registrar notice prior to deploying the Updates into the production environment. The notice shall be at least thirty (30) days.

For Updates (where client changes are required) and Upgrades, Registry Operator will give each registrar notice prior to deploying the Update or Upgrade into the production environment. The notice shall be at least ninety (90) days. Such notice will include an initial notice before deploying the Update that requires changes to client applications or the Upgrade into the Operational Test and Evaluation ("OT&E") environment to which all registrars have access. Registry Operator will maintain the Update or Upgrade in the OT&E environment for at least thirty (30) days, to allow each registrar the opportunity to modify its client applications and complete testing, before implementing the new code in the production environment. This notice period shall not apply in the event Registry Operator's system is subject to the imminent threat of a failure or a material security threat, the discovery of a major security vulnerability, or a Denial of Service (DoS) attack or any other kind of excessive load where the Registry Operator's systems are rendered inaccessible or degraded by being subject to, without limitation:

9.   Performance Specifications

Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry TLD. The Performance Specifications, defined below, provide a means to measure Registry Operator's delivery of Registry Services and, when applicable, allow for calculation of the SLA Credit payable to ICANN-Accredited Registrars pursuant to Appendix 10 of the Registry Agreement.

9.1

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

 
9.2 Definitions Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.
 
9.3 "Claim Month" means the calendar month when SRS Unavailability occurred, for which the ICANN-Accredited Registrar can claim SLA Credit.
 
9.4 "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 2 of Nameserver Availability and Performance Measurements in Exhibit A of this Appendix. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.
 
9.5 "Current Pricing Level" refers to prices charged for Registry Services as provided in the Registry Agreement.
 
9.6 "DNS Service" shall mean the Nameserver service made available on TCP/UDP port 53 on selected servers.
 
9.7 "ICANN-Accredited Registrar," as used in this Appendix, refers to an "ICANN-Accredited Registrar" that has a Registry-Registrar Agreement in effect with Registry Operator.
 
9.8

"Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 Greenwich Mean Time (GMT).

 
9.9 "Performance Specifications" refers to a description of the functional attributes of a particular system or service. The attributes outlined in a Performance Specification are measurable.
 
9.10 "Planned Outage" means the periodic pre-announced occurrences when the SRS Service will be stopped for maintenance or care. Planned Outages will be published at least one week in advance to the Registrar Community in the form of an email to each ICANN-Accredited Registrar. Planned Outages will be scheduled only during the following window period of time each week, 0000 - 0900 GMT on Sunday (the "Planned Outage Period"). The beginning of this Planned Outage Period may be changed from time to time by the Registry Operator, in its sole discretion, upon prior notice to each ICANN-Accredited Registrar. Planned Outages will not exceed 4 hours/per calendar week beginning at 1200 GMT Monday nor total more than 8 hours/per month. Notwithstanding the foregoing, Registry Operator may incur one (1) additional Planned Outage of up to 12 hours in duration during the Planned Outage Period and the immediately following three hours for major systems or software upgrades ("Extended Planned Outages"). These Extended Planned Outages represent total allowed Planned Outages for the month.
 
9.11 "Registrar Community" refers to all "ICANN-Accredited Registrars" as that term is defined for purposes of this Appendix.
 
9.12 "Round-trip" means the amount of measured time that it takes for a reference query to make a complete trip from the sampling agent, to the service being tested and back again. Usually measured in milliseconds.
 
9.13 "SLA" means the Service Level Agreement between Registry Operator and ICANN-Accredited Registrar attached as Appendix 10 to the Registry Agreement.
 
9.14 "SLA Credit" means those credits available to the ICANN-Accredited Registrar pursuant to the SLA.
 
9.15 "SRS Service" shall mean the service accessible to the ICANN-Accredited Registrar for operating on the main registry data store using the defined protocol (EPP) for Registry-Registrar interaction. It does not include WWW, FTP, SCP or other services not associated directly with adding, deleting or modifying domain-names.
 
9.16  

"SRS Availability" means when the SRS Service is operational and predictably responding in a commercially reasonable manner. By definition, this does not include Planned Outages or Extended Planned Outages. System Availability will be monitored and recorded by the Registry Operator. The following formula shall be used for calculating SRS Availability:

where:

A = SRS Availability in percent
UDT = Unplanned Downtime in hours for the Monthly Timeframe
TA = Time available in hours for the Monthly Timeframe
  9.16.1 The following periods will not be included in calculating SRS Availability:
 
    (a) All periods of SRS Unavailability that result from the effects of scheduled service maintenance;
 
    (b) All periods of SRS Unavailability that result from events locally at the ICANN-Accredited Registrar, or events outside of Registry Operator's control; and
 
    (c) All periods of SRS Unavailability that result from events that can be classified as malicious attacks, such as denial of service ("DoS") attacks.
 
9.17 "SRS Unavailability" means when, as a result of a failure of systems within the Registry Operator's control, the ICANN- Accredited Registrar is unable to either:
 
  9.17.1 establish a session with the SRS gateway which shall be defined as:
 
    (a) successfully completing a TCP session start;
 
    (b) successfully completing the SSL authentication handshake; and
 
    (c) successfully completing the extensible provisioning protocol ("EPP") session command.
 
  9.17.2 Execute a 3 second average round trip for 95% of the EPP check domain commands and/or less than 5 second average round trip for 95% of the EPP add domain commands, from the SRS gateway, through the SRS system, back to the SRS gateway as measured during each Monthly Timeframe.
 
9.18 "System Services" shall mean the list of services provided in Section 3 - System Services.
 
9.19 "Transaction" shall mean completion of a defined SRS command.
 
9.20 "Unplanned Downtime" shall mean all of the following:
 
  9.20.1 The amount of time recorded between a trouble ticket first being opened by the Registry Operator in response to an ICANN-Accredited Registrar's claim of SRS Unavailability for that ICANN-Accredited Registrar through the time when the ICANN-Accredited Registrar and Registry Operator agree the SRS Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered SRS Unavailability only for those ICANN-Accredited Registrars impacted by the outage as evidenced by their submission of an SLA claim;
 
  9.20.2 The amount of time recorded between a trouble ticket first being opened by the Registry Operator in the event SRS Unavailability that affects all ICANN-Accredited Registrars through the time when the Registry Operator resolves the problem with a final fix or a temporary work around, and the trouble ticket is closed;
 
  9.20.3 The amount of time the Planned Outage exceeds the limits established in Subsection 9.10 above; and
 
  9.20.4 The amount of time that the Planned Outage time occurs outside the window of time established in Subsection 2.8 above.
 
9.21 "Whois Service" shall mean the information service made available on TCP port 43 on selected servers.
 

10.   System Services

The following table lists the System Services for which availability and performance requirements are established. System Services shall meet the availability and performance levels described in Section 5.

System Service
SLA
ICANN
DNS Service
 
X
SRS Service
X
X
Whois Service
 
X

11.   Service Levels (Availability and Performance)

11.1 DNS Service. Registry Operator considers the DNS Service to be the most critical service of the Registry, and will ensure that unavailability times are kept to an absolute minimum.
 
  11.1.1   DNS Service Availability = 99.999%. Registry Operator will provide the above-referenced DNS Service Availability. Registry Operator will log DNS Service unavailability: (a) when such unavailability is detected by the monitoring tools described in Exhibit A, or (b) once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail or fax. The committed Performance Specification is 99.999% measured on a monthly basis.
 
  11.1.2 Performance Level. At any time, each nameserver (including a cluster of nameservers addressed at a shared IP address) MUST be able to handle a load of queries for DNS data that is three times the measured daily peak (averaged over the Monthly Timeframe) of such request on the most loaded nameserver.
 
  11.1.3 Response Time. The DNS Service will meet the Cross-Network Nameserver Performance Requirements described in 15.2.
 
11.2   SRS Service. Registry Operator provides built-in redundancy into the SRS Service. Such redundancy will ensure that SRS Unavailability is kept to an absolute minimum.
 
  11.2.1 SRS Service Availability = 99.4%. Registry Operator will provide the above-referenced SRS Service Availability. Registry Operator will log SRS Unavailability once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail or fax. The committed Performance Specification is 99.4% measured on a monthly basis.
  11.2.2 Performance Level. The Registry Operator will, on average, be capable of processing 40 Transactions per second.
 
  11.2.3 Response Time. The SRS Service will have a worst-case response time of 3 seconds, not including network delays, before it will be considered Unavailable.
 
11.3 Whois Service. Registry Operator provides built-in redundancy into the Whois Service. Such redundancy will ensure that unavailability of the Whois Service is kept to an absolute minimum.
 
  11.3.1 Whois Service Availability = 99.4%. Registry Operator will provide the above-referenced Whois Service Availability for port 43. Registry Operator will log Whois Service unavailability: (a) when such unavailability is detected by the monitoring tools described in Exhibit A, or (b) once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail or fax. The committed Performance Specification is 99.4% measured on a monthly basis.
 
  11.3.2 Response Times. The port 43 Whois Service will have a worst-case response time of 1.5 seconds, not including network delays, before it will be considered unavailable.

12.   Measurement

Registry Operator will monitor the Service Levels in Section 11 in accordance with the following principles.

12.1   SRS Service/Component Monitoring: The Registry operator will monitor the SRS service remotely using proprietary software developed in-house, and will in addition use protocol server logs to verify the results.
 

13.   Responsibilities Of The Parties

13.1   Except in the case of nameserver performance requirements, Registry Operator will perform monitoring from internally located systems as a means to verify that the availability and performance measurements of this document are being met.
 
13.2 The Registry Operator will update the Whois Service on a near real time basis. The Registry Operator will notify ICANN-Accredited Registrars in advance when major changes to the Whois Service update schedule occur.
 
13.3 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.
 
13.4 The Registry Operator will provide System Service availability percentages during each Monthly Timeframe as listed in Section 11 - Service Levels (Availability and Performance) to ICANN.
 
13.5 The Registry Operator will use commercially reasonable efforts to restore the critical systems of the SRS Service within 48 hours in the event of Force Majeure. Further, the Registry Operator will make commercially reasonable efforts to restore full functionality of the SRS Service within 72 hours. Outages due to Force Majeure will not be considered Unavailability.

14.   Miscellaneous

14.1   This Appendix is not intended to replace any term or condition in the Registry Agreement.
 
14.2 Dispute Resolution will be handled pursuant to the terms of Subsection 5 of the Registry Agreement.
 
14.3 The following table defines the levels of performance the Registry Operator will adhere to:
 
Performance
Specification
Description
SRS
Nameserver
Whois
Service Availability 99.4% per month 99.999% per month across the nameserver constellation 99.4% per month
SRS Transaction processing time <3 seconds for 95% of the transactions N/A N/A
Whois query processing time N/A N/A <1.5 seconds for 95% of the transactions
Planned Outage Duration 8 hours per month N/A 8 hours per month
Planned Outage Timeframe 0000-0900 GMT Sunday N/A 0000 - 0900 GMT Sunday
Planned Outage Notification 7 days N/A 7 days
Extended Planned Outage Duration 12 hours per month N/A 12 hours per month
Extended Planned Outage Timeframe 0000-0900 GMT Saturday or Sunday N/A 0000-0900 GMT Saturday or Sunday
Cross-Network Nameserver Performance (CNNP) N/A <300ms RTT and 10% packet loss N/A


 

Exhibit A

15.   Sampling and Testing Schedule

15.1   Monitoring and Testing Tools
 
  15.1.1   Internal proprietary monitoring and SLA measurement tools have been developed by the Registry Operator to ensure a consisted and accurate level of monitoring.
 
  15.1.2 Other industry standard tools are also utilized for the purpose of monitoring registry systems.
 
15.2 Nameserver Performance Measurements
 
  15.2.1 Cross-Network Nameserver Performance Requirements.
 
    (a)   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.
 
    (b) 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:
    (c) The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .name nameservers and observing the responses from the .name nameservers. (These strings of requests and response 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).
 
    (d) Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected .name second-level domains, pre-selected 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.
 
    (e) To meet the packet loss and Round-trip-time requirements for a particular CNNP Test, all three of the following must be true:
 
    (f) The Round-trip time and packet loss from each measurement location to at least one .name nameserver must not exceed the required values.
 
    (g) The Round-trip time to each of 75% of the .name nameservers from at least one of the measurement locations must not exceed the required value.
 
    (h) The packet loss to each of the .name nameservers from at least one of the measurement locations must not exceed the required value.
 
    (i) Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.
 
    (j) 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 .name nameservers persistently fail the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.
 
    (k) 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.
 
    (l) If, following that opportunity to cure, the .name nameservers continue to persistently fail CNNP Tests and Registry Operator fails to resolve the problem within thirty days after written notice of the continuing failures, Registry Operator will be deemed not to have met its obligations under Subsection 3.3 of the Registry Agreement.
 
    (m)   Sixty days before 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.