Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

.BIZ Agreement Appendix 7 | Functional Specifications | (22 August 2013)

 

ICANN Logo

.BIZ Agreement Appendix 7
Functional Specifications


(22 August 2013)

Functional 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. DNS;
5. IDN;
6. IPv6; and
7. Additional Services





1. Extensible Provisioning Protocol

Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3915, 5910, 5730, 5731, 5732, 5733 and 5734.  If Registry Operator requires the use of proprietary EPP functionality, Registry Operator must document EPP extensions in Internet-Draft format following the guidelines described in RFC 3735.  Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment.

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

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

4. DNS

Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

For domain names which are either not registered, or the registrant has not supplied valid records such as NS records for listing in the DNS zone file, or their status does not allow them to be published in the DNS, the use of DNS wildcard Resource Records as described in RFCs 1034 and 4592 or any other method or technology for synthesizing DNS Resources Records or using redirection within the DNS by the Registry is prohibited.  When queried for such domain names the authoritative name servers must return a “Name Error” response (also known as NXDOMAIN), RCODE 3 as described in RFC 1035 and related RFCs.  This provision applies for all DNS zone files at all levels in the DNS tree for which the Registry Operator (or an affiliate engaged in providing Registration Services) maintains data, arranges for such maintenance, or derives revenue from such maintenance.

Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”).  During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors.  If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors.  Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices.  Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material.  Registry Operator shall publish its DPS following the format described in RFC 6841.

5. IDN

If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors.  Registry Operator shall comply with the ICANN IDN Guidelines at <http://www.icann.org/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time.  Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines.  DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding.

6. IPv6

Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS.  Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA.  Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91 and the recommendations and considerations described in RFC 4472.  Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Appendix 5 of this Agreement; e.g. Whois (RFC 3912), Web based Whois.  Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate with the SRS over IPv6.

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