.ORG Agreement Appendix 7 Functional and Performance Specifications (4 April 2007)

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

1. Registry Operator Registrar Protocol;
2. Supported initial and renewal registration periods;
3. Grace period policy;
4. Nameserver functional specifications;
5. Patch, update, and upgrade policy; and
6. Performance Specifications  

1. Registry Operator Registrar Protocol  

1.1 Extensible Provisioning Protocol

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, 3734, 3735, and 3915 published by the Internet Engineering Task Force (“IETF”) and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary.  

2. Supported initial and renewal registration periods

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

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

c. 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 one year, provided that the maximum term of the registration as of the effective date of the sponsorship change shall not exceed ten years.

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

3. Grace and Pending Period Policy

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 domain action may be reversed and a credit may be issued to a registrar. Relevant registry operations in this context are:

• Registration of a new domain,
• Extension of an existing domain,
• Auto-Renew of an existing domain;
• Transfer of an existing domain; and
• Deletion of an existing domain.
• Restore of a deleted domain

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. Restore is accomplished either by using the Restore screen in the web-based administrative site, or by using the EPP RENEW command with the RGP extension; provided, however, that in the case of (i) Bulk Transfers under Part B of the ICANN Policy on Transfer of Registrations between Registrars and (ii) Large Incidents, Restore may be accomplished by e-mail or fax using a Restore Request Form as specified by Registry Operator.

There are five grace periods provided by Registry Operator's Shared Registration System: Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period, Transfer Grace Period, and Redemption Grace Period.

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 domain,
• Deletion of an existing domain, and
• Restore of a domain name in Redemption Grace Period.

3.1 Grace Periods  

3.1.1 Add Grace Period

The Add Grace Period is a specified number of calendar days following the initial registration of a domain. The current value of the Add Grace Period for all registrars is five calendar days. If a Delete, Renew/Extend, or Transfer operation occurs within the five calendar days, the following rules apply:

Delete. If a domain 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 domain is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 3.2 for a description of overlapping grace period exceptions.

Excess Deletes: An Excess Deletion Fee will 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 PIR.  

Renew/Extend. If a domain 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 domain registration is extended by the number of years, up to a total of ten years, as specified by the registrar's requested Renew/Extend operation.  

Transfer (other than ICANN-approved bulk transfer). 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 domain name registration and is enforced by the SRS.  

Bulk Transfer (with ICANN approval). 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 registrations are not affected. The losing Registrar's account is charged for the initial add.  

3.1.2 Renew/Extend Grace Period

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

Delete. If a domain 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 domain is deleted from the Registry database and is moved to the Redemption Grace Period (that is, to the status: Pending Delete – Restorable). See Section 3.2 for a description of overlapping grace period exceptions.

Renew/Extend. A domain registration can be extended within the Renew/Extend Grace Period for up to a total 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.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew/Extend Grace Period, there is no credit. The expiration date of the domain registration is extended by one year and the years added as a result of the Extend remain on the domain name up to a total of 10 years.

Bulk Transfer (with ICANN approval). 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 charged for the Renew/Extend operation.  

3.1.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 domain name registration 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 45 calendar days. If a Delete, Extend, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply:  

Delete. If a domain 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 domain is deleted from the Registry database and is moved to the Redemption Grace Period (that is, to the status: Pending Delete – Restorable). See Section 3.2 for a description of overlapping grace period exceptions.

Renew/Extend. A domain can be extended within the Auto-Renew Grace Period for up to a total 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.  

Transfer (other than ICANN-approved bulk transfer). If a domain 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 domain is extended by one year up to a total maximum of ten 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.  

Bulk Transfer (with ICANN approval). 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 charged for the Auto-Renew.  

3.1.4 Transfer Grace Period

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

Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The domain is deleted from the Registry database and is moved to the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.  

Renew/Extend. If a domain registration 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 domain registration is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Renew/Extend operation.  

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Transfer Grace Period, there is no credit. The expiration date of the domain registration 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.  

Bulk Transfer (with ICANN approval). 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.  

3.1.5 Bulk Transfer Grace Period

There is no grace period associated with Bulk Transfer operations. Upon completion of the Bulk Transfer, any associated fee is not refundable.  

3.1.6 Redemption Grace Period

A domain name is placed in REDEMPTIONPERIOD status when a registrar requests the deletion of a domain that is not within the Add Grace Period. A name that is in REDEMPTIONPERIOD status will not be included in the zone file. A registrar can not modify or purge a domain in REDEMPTIONPERIOD status. The only action a registrar can take on a domain in REDEMPTIONPERIOD is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. Unless restored, the domain will be held in REDEMPTIONPERIOD status for a specified number of calendar days. The current length of this Redemption Period is 30 calendar days.  

3.2 Overlapping Grace Periods

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

• If a domain 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 domain is removed from the Registry database and is immediately available for registration by any Registrar.

• If a domain 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 domain’s expiration as a result of the auto-renewal and extension are removed. The deleted domain is moved to the Redemption Grace Period (that is, to the status: Pending Delete -- Restorable).

3.2.1 Overlap Exception

• If a domain 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 domain 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 domain 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.

Note: If several billable operations, including a transfer, are performed on a domain and the domain is deleted within the grace periods of each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current Registrar.

3.3 Pending Periods

3.3.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 domain in which the current registrar of the domain (registrar B) may explicitly approve or reject the transfer request. The current value of the Transfer Pending Period is five 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:

a. EPP TRANSFER request or EPP RENEW request is denied.

b. AUTO-RENEW is allowed.

c. EPP DELETE request is denied.

d. Bulk Transfer operations are allowed.

e. EPP UPDATE request is denied.

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

3.3.2 Pending Delete Period

A domain name is placed in PENDING DELETE status if it has not been restored during the Redemption Grace Period. A name that is in PENDING DELETE status will not be included in the zone file. All registrar requests to modify or otherwise update a domain in PENDING DELETE status will be rejected. A domain 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 calendar days.

4. Nameserver functional specifications

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

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

1. A "Patch" means minor modifications to the Licensed Product made by Registry Operator during the performance of error correction services. A Patch does not constitute a Version.

2. An "Update" means a new release of the Licensed Product which may contain error corrections, minor enhancements, and, in certain circumstances, major enhancements.

3. An "Upgrade" means a new release of the Licensed Product which involves the addition of substantial or substantially enhanced functionality.

4. A "Version" means the Licensed Product identified by any single version number.

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 during 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:

i) excessive levels of data traffic

ii) unauthorized traffic; or

iii) data traffic not conforming to the protocols used by the Registry

6. Performance Specifications

(A) Registry Operator shall use commercially reasonable efforts to provide Registry Services for the .org 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 Credits as set forth in Appendix 10 to the Agreement.

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.

2. Definitions. Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.

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 7 below. Such events include but are not limited to congestion, collapse, partitioning, power grid failures, and routing failures.

2.2 "Current Pricing Level" refers to prices charged for Registry Services.

2.3 "C1" means Category 1, a mission critical service.

2.4 "C2" means Category 2, a mission important service.

2.5 "C3" means Category 3, a mission beneficial service.

2.6 "Degraded Performance" means a service not meeting the performance requirement set forth in this document. Round-trip time is used as the basis of this metric for all services except nameservice; for nameservice packet loss and Round-trip time are used as metrics.

2.7 "Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 Coordinated Universal Time (UTC).

2.8 "Monthly Unplanned Outage Time" shall be the sum of minutes of all Unplanned Outage Time during the Monthly Timeframe. Each minute of Unplanned Outage Time subtracts from the available Monthly Planned Outage Time up to four (4) hours.

2.9 "Not Responding" means a service will be deemed as "Not Responding" in the event that the Registry Component Ping (rcPing), as described in Section 7 below, responds with a negative or degraded service response.

2.10 "Planned Outage" means the periodic pre-announced occurrences during the Service Term when the System is taken out of service for maintenance or care. Planned Outages will only be scheduled during the following window period of time each week, 1300 to 2300 UTC on Saturday (the "Planned Outage Period"). The Planned Outage Period may be changed from time to time by the Registry Operator, in its sole discretion, upon prior notice to each Registrar. Planned Outages will not exceed four (4) hours/per calendar week beginning at 0000 UTC Monday nor total more than eight (8) hours/per Monthly Timeframe. Planned Outage for a nameserver shall not coincide with or overlap Planned Outage for any other nameserver. Not withstanding the foregoing, in each calendar year Registry Operator may incur one (1) additional Planned Outage of up to eight (8) hrs in duration during the Planned Outage Period for major systems or software upgrades (an "Extended Planned Outage"). An Extended Planned Outage represents the total allowed Planned Outages for the month.

2.11 "Round-trip" means the amount of measured time, usually measured in milliseconds, that it takes for a reference query to make a complete trip from the sampling agent to the system or process being tested and back again.

2.12 "Service Availability" means when the System is operational and predictably responding in a commercially reasonable manner. By definition, neither Planned Outages nor Extended Planned Outages shall be considered or included in determining Service Availability.

2.13 "Service Unavailability" means when, as a result of a failure of systems (with respect to systems that are within the Registry Operator's control):

2.13.1 With respect to services other than Whois Service and nameservice, Registrar is unable to establish a session with the System gateway which shall be defined as:

2.13.1.1 successfully complete a TCP session start,

2.13.1.2 successfully complete the SSL authentication handshake, and

2.13.1.3 successfully complete the Extensible Provisioning Protocol ("EPP") <login> or RRP login command.

2.13.2 With respect to all services, system monitoring tools register three (3) consecutive monitoring failures on any of the components listed in Section 3–System Services.

2.13.3 Neither Planned Outages nor Extended Planned Outages shall be considered or included in determining Service Unavailability.

2.14 "SLA" means the service level agreement between Registry Operator and Registrar set forth on Appendix 10.

2.15 "SLA Credit" means those credits available to the Registrar pursuant to the SLA.

2.16 "System" shall mean the list of components listed in Section 3–System Services.

2.17 "Transaction" shall mean chargeable Registry Services, which includes initial and renewal registrations.

2.18 "Unplanned Outage Time" shall mean all of the following:

2.18.1 With respect to services other than Whois Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the Registry Operator in response to a Service Unavailability experienced by a Registrar through the time when the Service Unavailability has been resolved with a final fix or a temporary work around. This will be considered Service Unavailability only for those individual Registrars impacted by the Service Unavailability;

2.18.2 With respect to services other than Whois Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the Registry Operator in the event of Service Unavailability that affects all Registrars through the time when the Registry Operator resolves the problem with a final fix or a temporary work around;

2.18.3 With respect to all services, the amount of time that Planned Outage time exceeds the limits established in Section 2.10 above; or

2.18.4 With respect to all services, the amount of time that Planned Outage time occurs outside the window of time established in Section 2.10 above.

2.19 "Whois Service" means the Registry Operator Whois Services described in Appendix O of the Registry Agreement.

2.20 With respect to the use of “.org nameservers” (Appendix D, Exhibit A) for definition of described testing, “.org nameservers” will refer to those hostnames and IP addresses associated for operation of the .org zone file delegation as listed within the root zone, and published by the Internet Assigned Numbers Authority.

3. System Services.

The following table lists, by category (C1, C2, or C3), the Registry System services for which availability and performance requirements are established. Services shall meet availability requirements according to their category, as listed in the "Cat." column below. In addition, various services must meet the performance requirements listed in the "Perf." column below. These availability and performance requirements are the subject of the Service Level Agreement (SLA) between Registry Operator and registrars as noted by the × marks below.

4. Service Levels (Availability and Performance)

4.1 Service Level Matrix

4.2 Service Definition and Service Level Requirement

5. Measurement.

Except for nameserver performance measurements (P4), Registry Operator will monitor the System in accordance with the following principles.

5.1 System/Component Monitoring:

The services defined in this Appendix will be sampled and tested as to availability pursuant to the schedule attached hereto as Exhibit A.

5.2 Performance Monitoring:

The services defined in this Appendix will be sampled and tested as to their performance pursuant to the schedule attached hereto as Exhibit A. Services Not Responding within the Round-trip response times listed in Section 4 – Service Levels will be deemed suffering from Degraded Performance for the purposes of this Appendix.

Nameserver performance measurements will be conducted by ICANN according to Exhibit A.

6. Responsibilities of the Parties.

6.1 Except in the case of nameserver performance measurements, 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.

6.2 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 replicated databases as its source of information. The time lag in the Whois information update is determined by the database replication interval. Whois may be serviced by multiple backup replicated databases (database B, C, D etc). The Registry Operator will notify Registrars in advance when changes to the Whois Service update schedule occur.

6.3 The Registry Operator will initiate the addition, deletion, or other modification of DNS zone information to its DNS service within 5 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.

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

6.5 Beginning no later than 60 days post 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.

6.6 The Registry Operator will provide Service Availability percentages during each Monthly Timeframe as listed in Section 4.1 – Service Level Matrix.

7. Miscellaneous.

7.1 This Appendix is not intended to replace any term or condition in the Registry Agreement.

7.2 Dispute Resolution will be handled pursuant to the terms of the Registry Agreement.

EXHIBIT A
Sampling and Testing Schedule

The Registry Component Ping (rcPing) facility is used to determine two elements of service level agreement (SLA) compliance for the registry. The first level of compliance involves determining the availability of specific components/functions within the registry system. The second level of compliance involves determining if the components/functions are responding within a pre-determined time period.

The rcPing request is generated by a monitor (rcPing Monitor) component within the server complex. The interface/request handler which is responsible for receiving commands for the monitored components/functions should record the time of the request arriving, ping the monitored component/function, record the stop time, determine the difference in milliseconds and respond with the integer value in milliseconds of the difference. The rcPing Monitor will time out if no response is received from the interface within a pre-determined interval. The rcPing request is specific to the component being monitored. Monitoring requests are sent independent of one another.

The following table lists the components to be monitored by the rcPing facility.

Each component being monitored can be configured with the following:

1. The time-out threshold. A typical value for timeout is three (3) seconds.

2. The expected response time for each ping command, as listed above.

3. The interval at which the ping commands will be sent. A typical value for the sampling interval is five (5) minutes.

4. The number of consecutive failures (i.e. exceeded response times and ping time outs) that determine a non-compliance with the SLA for a single component. A typical value is three (3) consecutive failures.

The rcPing monitor will store all response time data in a database that will be archived on a daily basis.

Nameserver Availability and Performance Measurements

1. Availability of each .org nameserver shall be measured by the rcPing utility. A nameserver that does not respond to three consecutive ping requests (pings at five-minute intervals with three-second timeouts) will be considered as Not Responding.

2. 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 Subsection 3.3 of the Registry Agreement.

The committed Performance Specification for cross-network nameserver performance is a measured Round-trip time of under 300ms 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:

2.1. The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .org nameservers and observing the responses from the .org 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).

2.2. Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected .org 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.

2.3. To meet the packet loss and Round-trip-time requirements for a particular CNNP Test, all three of the following must be true:

2.3.1. The Round-trip time and packet loss from each measurement location to at least one .org nameserver must not exceed the required values.

2.3.2. The Round-trip time to each of 75% of the .org nameservers from at least one of the measurement locations must not exceed the required value.

2.3.3. The packet loss to each of the .org nameservers from at least one of the measurement locations must not exceed the required value.

2.4. Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.

2.5. To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times 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 .org nameservers persistently fail (see item 1.1.3 above) the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.

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

2.7. If, following that opportunity to cure, the .org 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.

2.8. Sixty days before the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the testing tools, procedures and testing methodology to be used by ICANN. In the event that Registry Operator does not approve of such tools, procedures and testing methodology, ICANN will work directly with Registry Operator to make necessary modifications.