.BIZ Registry Agreement | Functional and Performance Specifications

  ICANN Logo

.BIZ Agreement Appendix 7
Functional and Performance Specifications
(19 June 2009)


Functional and Performance Specifications

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

1. Extensible Provisioning 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
7. Additional Services

I. Extensible Provisioning Protocol

Registry Operator shall implement 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.

II. 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 exceed 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.

III. Grace 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.

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/removal 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 using the EPP RENEW command.

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, or Transfer operation occurs within the five calendar days, the following rules apply:

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

Transfer (other than ICANN-approved bulk transfer). Transfers under the Registry-Registrar Agreement 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 currently enforced by the SRS.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Add Grace Period. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the initial add.

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. However, the Registrar's account will be reconciled at the end of the month for the number of deletions during the AGP that exceed the maximum of (i) 10% of its new registrations or (ii) fifty (50) domain names, whichever is greater. The fee imposed on those deletions exceeding the previously stated monthly maximum level will be the amount of the original registration, absent extraordinary circumstances.

For any registrar requesting an exemption from this excessive domain name deletion fee, the registrar must confirm in writing to the Registry Operator how these extraordinary circumstances were not known, or could not have been reasonably known, at the time the names were deleted and how these extraordinary circumstances were outside of its control. Registry Operator's determination of whether or not to grant an exemption shall be at its sole reasonable discretion.

3.1.2 Renew Grace Period

The Renew Grace Period is a specified number of calendar days following the renewal of a domain name registration period through an EPP Command Renew. The current value of the Renew 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 Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the renew fee. The deleted domain is moved to the Redemption Grace Period (that is, to the PendingDelete status). See below for a description of overlapping grace period exceptions.

Renew. A domain can be extended within the 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 Renew Grace Period, there is no credit to the losing registrar for the renewal fee. The expiration date of the domain 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 Grace Period. The expiration dates of transferred registrations are not affected. The losing Registrar's account not credited for the Renew 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, Renew, 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 deleted domain is moved to the Redemption Grace Period (that is, to the PendingDelete status). See below for a description of overlapping grace period exceptions.

Renew. A domain can be Renewed 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 under Section 3.9 of the Registry-Registrar Agreement 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 by virtue of the transfer 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 maximum limitation.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period. The expiration dates of transferred registrations are not affected. The losing Registrar's account is not credited 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. The current value of the Transfer 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 Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The deleted domain is moved to the Redemption Grace Period (that is, to the PendingDelete status). See below for a description of overlapping grace period exceptions.

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

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Transfer Grace Period. 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 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 Grace Period, then the Registrar is credited the registration and renew amounts, taking into account the number of years for which the registration and renew were done. The domain is deleted 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 Grace Period, the registrar will be credited for the Auto-Renew 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.The deleted Registered Name is moved to the Redemption Grace Period (that is, to the PendingDelete status).

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, second and third transfers, then only the last transfer is credited to Registrar C.
  • If a domain is extended (through the EPP command "Renew") 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 transfers, 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.1.7 Redemption Grace Period

Overview

The Redemption Grace Period Service allows registrars to restore Registered Names that were unintentionally deleted and are still within a thirty-day Redemption Grace Period (RGP). The RGP Service cover all names deleted by registrars, with the exception of those names deleted in the Add Grace Period.

The RGP Service may be implemented in two stages. Stage 1 as described in the following allows original registrars to restore unintentionally deleted registrations. In the future, ICANN and Registry Operator will discuss implementation of Stage 2, with the goal, if feasible, of allowing registrants to choose which registrar will restore their deleted name(s).

Implementation

The .biz Registry RGP is a fully automated and EPP-compliant implementation. Only statuses defined in the current EPP specifications will be used. As such all domains slated for deletion will remain in PendingDelete status for 35 days or until they are restored.

PendingDelete Status:

All domains deleted outside the Add Grace Period will be placed on PendingDelete status for a total of 35 days, after which time the names will be purged from the Registry database and made available again for registration.

During this PendingDelete timeframe, domain names can only be restored during the first 30 days, and cannot be otherwise modified. The only action allowed by the original registrar is the restoration of the domain name.

Note: BULK TRANSFER operations are allowed within the 30-day RGP provided that such transfer is in accordance with the Registry-Registrar Agreement. The gaining registrar in any ICANN-approved bulk transfer assumes the role of the deleting registrar with regards to any name in the PendingDelete status sponsored by the losing registrar at the time of transfer.

Note: TRANSFER or modification requests are not allowed during the RGP.

Upon being placed in PendingDelete status, domain names will be immediately removed from the DNS, but will remain in the Whois with a notation about their availability of being restored. (See Appendix 5 for further details).

At the conclusion of the 30-day RGP, the domain will remain on PendingDelete for an additional five days. During this time, the domain cannot be restored, modified, deleted, or transferred. At the conclusion of this five-day period, the domain will be purged from the Registry database and hence available for re-registration.

Restore Command:

The implementation of the Redemption Grace Period Service involves one command.

RESTORE Command: Registrars may restore names by using the existing EPP Renew command. In addition, EPP extensions will be used to capture the additional required reporting information, see below. A successful restore command will terminate the PendingDelete status, remove the deleted status attribute from the registration and return the registered name to the same state it was in immediately prior to the delete request.

If the registered name is past its expiration date at the time it is restored, then, following the restore, its registration term will be extended by the minimum term of years necessary to bring it current. The registrar will first be debited for the restoration and following for the renewal term.

There is no Restore Grace Period.

Appropriate Use of the Restore Capability

Registrars may only RESTORE Registered Names in order to correct unintentional deletions caused by registrant, registrar, or registry mistake (or as required by operation of the UDRP or other applicable dispute resolution policy in order to implement a court, arbitral tribunal or Administrative Panel decision). Restoring Registered Names in order to assume the rights to use or sell them will be considered an abuse of the system and will give Registry Operator the ability to delete those impacted domain names or terminate the Registry-Registrar Agreement.

Registrar Reporting Requirement

In order to facilitate verification of registrar compliance with the intended purpose of the Redemption Grace Period Service, Registrars are required to submit a "Registrar Restore Report" to the Registry Operator.

The reports will be generated as set forth by the Registry Operator through the restore command (EPP extensions) and in accordance with the below:

The following data shall be provided by the Registry Operator:

  • WHOIS data for deleted name, as it existed prior to deletion
  • WHOIS data for deleted name, as it existed at the time of report submission
  • Exact date and time of deletion
  • Exact date and time of restore

The following data shall be submitted by the registrar as part of the restore command. Failure to provide all of the following data at the time the restore command is submitted will result in a failure to restore the domain name.

  • Written explanation and corresponding reason code as to why registered name was restored (e.g., registrant mistake, registrar mistake, registry mistake, dispute resolution, etc.)
  • Written statement affirming that Registrar has not restored the .BIZ domain name in question in order to assume the rights to use or sell the name for itself or for any third party (unless the name was restored as required to give effect to an order or decision from a court, arbitral tribunal or Administrative Panel – in such cases a copy of the order should be provided separately to the Registry Operator by no later than five (5) business days following the restore).
  • Written statement affirming that information in report is factually accurate to the best of the Registrar's knowledge, and that the registrar acknowledges that intentionally supplying false information in the Restore Report shall constitute an incurable material breach of the Registry-Registrar Agreement and may result in the deletion of the impacted domain name(s).

The registry will maintain (for two years) copies of all Restore commands, as well as provide ICANN with copies of such reports if requested. Further, the registry will include in its monthly report to ICANN the number of Restore Reports received (see Appendix 4).

Registry Transparency Requirement – Registry Reports

The Registry Operator will provide comprehensive, regularly updated lists of names with a PendingDelete status to all Registrars via an FTP or SCP mechanism; these lists will include corresponding dates of deletion. These reports will only include names in the last five days of the PendingDelete status.

Registry Fees for Restoring Deleted Names

The registry shall be permitted to charge a fee for restoring a deleted name. The Redemption Grace Period Service fee is separate from, and in addition to, the ordinary charges for registration term extensions.

IV. Nameserver functional specifications

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

 V. 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, and which is indicated by a change in the digit to right of the decimal point in the version number of the Licensed Product.

3. An "Upgrade" means a new release of the Licensed Product which involves the addition of substantial or substantially enhanced functionality and which is indicated by a change in the digit to the left of the decimal point in the version of the Licensed Product.

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 and Upgrades, Registry Operator will give each registrar notice prior to deploying the Updates and Upgrades 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 where the Registry Operator's systems are rendered inaccessible by being subject to:

i) excessive levels of data traffic
ii) unauthorized traffic
iii) data traffic not conforming to the protocols used by the Registry

 VI. Performance Specifications

1. Introduction. The attached Performance Specification Matrix ("Matrix") provides a list of performance specifications as they apply to the three Core Services provided by the Registry - SRS, Nameserver, and Whois services.

2. Definition. 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 3.6 of this Appendix 7. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.

2.2 "Core Services" refers to the three core services provided by the Registry - SRS, Nameserver, and Whois Services.

2.3 "Performance Specification" refers to the specific committed performance service levels as specified herein.

2.4 "Performance Specification Priority" refers to the Registry's rating system for Performance Specifications. Some Performance Specifications are more critical to the operations of the Registry than others. Each of the Performance Specifications is rated as C1 - mission critical, C2 - mission important, C3 - mission beneficial, or C4 - mission maintenance.

2.5 "Registrar Community" refers to all of the ICANN-Accredited Registrars who have executed Registry-Registrar Agreements with Registry Operator for the Registry TLD.

2.6 "SRS" refers to the Shared Registration System; the service that the Registry provides to the Registrar Community. Specifically, it refers to the ability of Registrars to add, modify, and delete information associated with domain names, nameserver, contacts, and registrar profile information. This service is provided by systems and software maintained in coactive redundant data centers. The service is available to approved Registrars via an Internet connection.

2.7 "Nameserver" refers to the nameserver function of the Registry and the nameservers that resolve DNS queries from Internet users. This service is performed by multiple nameserver sites that host DNS resource records. The customers of the nameserver service are users of the Internet. The nameservers receive a DNS query, resolve it to the appropriate address, and provide a response.

2.8 "Service Level Measurement Period" refers to the period of time for which a Performance Specification is measured. Monthly periods are based on calendar months, quarterly periods are based on calendar quarters, and annual periods are based on calendar years.

2.9 "Whois" refers to the Registry's Whois service. The Registry will provide contact information related to registered domain names and nameserver through a Whois service. Any person with access to the Internet can query the Registry's Whois service directly (via the Registry website) or through a Registrar.

3. Performance Specifications. Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry TLD. The Performance Specifications defined below establish the basis for the Service Level Exception Credits ("SLE Credits") provided for in Appendix 10 to this Registry Agreement.

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

3.1.1 Service Availability is measured as follows:

Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where:

TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes)

POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period)

UOM = Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability during the Service Level Measurement Period minus POM).

Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party (to be selected by Registry Operator with the consent of the Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be no more than once yearly during the term of the agreement between Registry Operator and the Registrar.

This calculation is performed and the results reported for each calendar month for SRS and Whois availability and for each calendar year for Nameserver availability. Results will be reported to the Registrar Community via e-mail and to ICANN according to Appendix 4.

3.1.2 Service Availability—SRS = 99.9% per calendar month. Service Availability as it applies to the SRS refers to the ability of the SRS to respond to Registrars that access and use the SRS through the EPP protocol. SRS Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for SRS is 99.9% and the Service Level Measurement Period is monthly.

3.1.3 Service Availability—Nameserver = 99.999% per calendar year. Service Availability as it applies to the Nameserver refers to the ability of the Nameserver to resolve a DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Nameserver is 99.999% and the Service Level Measurement Period is annually.

3.1.4 Service Availability—Whois = 99.95% per calendar month. Service Availability as it applies to Whois refers to the ability of all users to access and use the Registry's Whois service. Whois Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Whois is 99.95% and the Service Level Measurement Period is monthly.

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

(i) Planned Outage Duration - SRS = 8 hours (480 minutes) per month;

(ii) Planned Outage Duration - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Duration - Whois = 8 hours (480 minutes) per month.

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

(i) Planned Outage Timeframe - SRS = 0600-1400 UTC Sunday;

(ii) Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Timeframe - Whois = 0600-1400 UTC Sunday.

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

(i) Planned Outage Timeframe - SRS = 3 days;

(ii) Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Timeframe - Whois = 3 days.

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

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

(i) Extended Planned Outage Duration - SRS = 18 hours (1080 minutes) per calendar quarter;

(ii) Extended Planned Outage Duration - Nameserver = (no planned outages allowed); and

(iii) Extended Planned Outage Duration - Whois = 18 hours (1080 minutes) per calendar quarter.

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

(i) Extended Planned Outage Timeframe - SRS = 0600 - 0000 UTC Saturday or Sunday;

(ii) Extended Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Extended Planned Outage Timeframe - Whois = 0600 - 0000 UTC Saturday or Sunday.

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

(i) Extended Planned Outage Timeframe - SRS = 4 weeks;

(ii) Extended Planned Outage Timeframe - Nameserver =(no planned outages allowed); and

(iii) Extended Planned Outage Timeframe - Whois = 4 weeks.

3.4 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 Registry Operator 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 SRS 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 Registry Operator 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.

3.4.1 Processing Time—Add, Modify, Delete = 3 seconds for 95%.

(i) Processing Time - Add, Modify, and Delete is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for add, modify, and delete transactions associated with domain names, nameservers, contacts, and registrar profile information.

(ii) The Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95% of the transactions will take 3 seconds or less from the time the Registry Operator receives the request to the time it provides a response.

3.4.2 Processing Time—Query Domain = 1.5 seconds for 95%.

(i) Processing Time - Query Domain is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for an availability query of a specific domain name.

(ii) The performance specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Registry Operator receives the query to the time it provides a response as to the domain name's availability.

3.4.3 Processing Time—Whois Query = 1.5 seconds for 95%.

(i) Processing Time - Whois Query is only applicable to the Whois. It measures the processing time for a Whois Query.

(ii) The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Whois receives a query to the time it responds.

3.4.4 Processing Time—Nameserver Resolution = 1.5 seconds for 95%.

(i) Processing Time - Nameserver Resolution is only applicable to the Nameserver. It measures the processing time for a DNS query.

(ii) The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time Nameserver receives the DNS query to the time it provides a response.

3.5 Update Frequency. There are two important elements of the Registry that are updated frequently and are used by the general public; Nameserver and Whois. Registrars generate these updates through the SRS. The SRS then updates the Nameserver and the Whois. These will be done on a batch basis. Update Frequency Performance Specifications are a C3 priority level.

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

3.5.1 Update Frequency—Nameserver = 15 minutes for 95%.

3.5.2 Update Frequency—Whois = 15 minutes for 95%.

3.6 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 10).

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:

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

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

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

3.6.3.1 The round-trip time and packet loss from each measurement location to at least one .biz nameserver must not exceed the required values.

3.6.3.2 The round-trip time to each of 75% of the .biz nameservers from at least one of the measurement locations must not exceed the required value.

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

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

3.6.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 .biz nameservers persistently fail (see Section 3.6.3 above) the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.

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

3.6.7 If, following that opportunity to cure, the .biz nameservers continue to persistently fail CNNP Tests and Registry Operator fails to resolve the problem after thirty days notice of the continuing failures, Registry Operator will be deemed not to have met its obligations under the Registry Agreement.

3.6.8 Sixty days prior to 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.

4. Responsibilities of the Parties.

4.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 in this document are being met.

4.2 The Registry Operator will provide the Whois Service as specified in Appendix 5.

4.3 The Registry Operator 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.

5. Miscellaneous.

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

6. Performance Specifications

PERFORMANCE SPECIFICATION MATRIX

 

Performance Specification Description

SRS

Nameserver

Whois

 

 

 

 

 

1

Service Availability

99.9% per calendar month

99.999% per calendar year

99.95% per calendar month

2

Processing Time–Add, Modify, Delete

3 sec for 95%

NA

NA

3

Processing Time–Query Domain

1.5 sec for 95%

NA

NA

4

Processing Time–Whois

NA

NA

1.5 sec for 95%

5

Processing Time–Nameserver Resolution

NA

1.5 sec for 95%

NA

6

Update Frequency

NA

15 min for 95%

15 min for 95%

7

Planned Outage–Duration

8 hrs per calendar month

not allowed

8 hrs per calendar month

8

Planned Outage–Timeframe

0600 - 1400 UTC Sun

not allowed

0600 - 1400 UTC Sun

9

Planned Outage–Notification

3 days

not allowed

3 days

10

Extended Planned Outage–Duration

18 hrs per calendar quarter

not allowed

18 hrs per calendar quarter

11

Extended Planned Outage–Timeframe

0600 - 0000 UTC Sat or Sun

not allowed

0600 - 0000 UTC Sat or Sun

12

Extended Planned Outage–Notification

28 days

not allowed

28 days

13

Cross-Network Nameserver Performance

NA

300 ms RTT and 10% packet loss

NA

7. Additional Services

7.1 Bulk Transfer After Partial Portfolio Acquisition.

Bulk Transfer After Partial Portfolio Acquisition (BTAPPA) is a registry service available to consenting registrars in the circumstance where one ICANN-accredited registrar purchases, by means of a stock or asset purchase, merger or similar transaction, a portion but not all, of another ICANN-accredited registrar’s domain name portfolio in the .BIZ top-level domain.

At least fifteen days before completing a BTAPPA, the losing registrar must provide to all domain name registrants for names involved in the bulk transfer, written notice of the bulk change of sponsorship. The notice must include an explanation of how the Whois record will change after the bulk transfer occurs, and customer support and technical contact information of the gaining registrar.

If a domain is transferred under the BTAPPA service during any applicable grace period as described in Section 3 above, there is no credit. The expiration dates of transferred registrations are not affected.

Domain names in the following statuses at the time of the Transfer Request will not be transferred in a BTAPPA: “pending transfer”, “redemption grace period (RGP)”, or “pending delete”. Domain names that are within the auto-renew grace window are subject to bulk transfer, but NeuStar may decline to provide a credit for those names deleted after the bulk transfer, but prior to the expiration of the auto-renew grace window.

NeuStar has discretion to reject a BTAPPA request if there is reasonable evidence that a transfer under BTAPPA is being requested in order to avoid fees otherwise due to NeuStar or ICANN, or if a registrar with common ownership or management or both has already requested BTAPPA service within the preceding six-month period.

In the event that one or more ICANN-accredited Registrars participate in the BTAPPA service, each such Registrar shall be required to agree to the pricing, terms and conditions set forth in Appendix 7, Exhibit A.

7.2 Single and Two-Character Phased Allocation Program:

.BIZ Single and Two Character Phased Allocation Program ("Phased Allocation Program"). The domain names included within the scope of the Phased Allocation Program shall be limited to single and two-character .BIZ domain names. NeuStar reserves the right to not allocate all single and two-character .BIZ domain names.

Pursuant to the Phased Allocation Program, NeuStar may elect to allocate the domain names via the following processes: 1) request for proposals based on evaluation criteria, 2) auction, or 3) first come, first served registration.

The domain names allocated via the Phased Allocation Program are an exception to the Maximum Service Fee described in Section 7.3(a) of the .BIZ Registry Agreement. Revenue derived from the Phased Allocation Program will be considered in the calculation of the average annual price of registrations for purposes of Section 7.2(a).