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.

هذا المحتوى متوفر فقط باللغة (أو اللغات)

  • English

.name Registry Agreement Appendix 7

Functional Specifications

(1 December 2012)

1. Introduction

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

  • Registry-Registrar Interface Protocol;
  • Supported initial and renewal registration periods;
  • Grace period policy;
  • Nameserver functional specifications;
  • Other functional specifications;
  • Patch, update, and upgrade policy;
  • Additional Services; and
  • Implementation of New Standards.

2. Definitions

2.1 "DNS" means the Internet domain name system.

2.2 "EPP" means the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.

2.3 "ICANN" means the Internet Corporation for Assigned Names and Numbers.

2.4 "Registered Name" means a registered Second Level Domain (SLD) E-mail address, registered third level domain name or registered second level domain name, collectively.

2.5 "Registered Item" refers to either a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, or a SLD E-mail Address or a Defensive Registration or a NameWatch Registration, about which Registry Operator or an affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. An item in a Registry Database may be a Registered Item even though it does not appear in a TLD zone file (e.g., a registered but inactive name).

2.6 "Registry Database" means a database, comprised of data about one or more DNS domain names, SLD E-mail Addresses or Defensive Registrations within the domain of the Registry TLD that is used to generate either DNS resource records that are published authoritatively, responses to domain-name availability lookup requests, Whois queries or other services related to the Registered Items, for some or all of those names.

2.7 "Email Forwarding" means the second level email forwarding service operated by the Registry Operator in the .name TLD.

2.8 "SLD E-mail Address" means an e-mail address consisting of a second level domain name within the domain of the Registry TLD and a defined user name (e.g., john@smith.name), about which Registry Operator (or an affiliate engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance.

2.9 "Registered Item Holder" means the holder of a Registered Item.

2.10 "The "Registrar Tool Kit" comprises the EPP, APls, documents and Software.

2.11 "Registry TLD" means the .name TLD.

2.12 The "Registry System" means the system operated by Registry Operator and its technology partners for Registered Items in the Registry TLD.

2.13 "Software" means reference client software intended to allow Registrar to develop its system to register second-level domain names through the Registry System.

2.14 A "TLD" means a top-level domain of the DNS.

2.15 Other terms used in this Agreement as defined terms shall have the meanings ascribed to them in the context in which they are defined.

3. Registry-Registrar Interface Protocol

3.1 Extensible Provisioning Protocol (EPP): Registry Operator has implemented, and shall maintain support of, the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 5730, 5731, 5732, 5733, 5734, 5910 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. If Registry Operator requires the use of functionality outside of EPP RFCs, Registry Operator must document EPP extensions using Internet-Draft format following the guidelines described in RFC 3735. Registry Operator is not required to submit documented EPP extensions to the IETF but to consider the recommendations on standardization described in section 2.1. of RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment.

3.2 In addition to the standard EPP mappings, the Registry Operator has additional mappings for NameWatch, Defensive Registrations and Email Forwarding.

3.3 Registry Operator shall take action to remove orphan glue records (as defined at http://www.icann.org/en/committees/security/sac048.pdf [PDF, 163 KB]) when provided with evidence in written form that such records are present in connection with malicious conduct.

4. Supported initial and renewal registration periods

4.1 Initial registrations of Registered Items (where available according to functional specifications and other requirements) may be made in the registry for terms of up to ten years in one year increments.

4.2 Renewal registrations of Registered Items (where available according to functional specifications and other requirements) may be made in the registry for terms not exceeding a total of ten years.

4.3 Holder-Authorized Transfers: Upon change of sponsorship of the registration of a Registered Item 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 Item shall be extended by a minimum of one year, provided that the maximum term of the registration as of the effective date of the sponsorship change shall not exceed ten years.

4.4 ICANN-Approved Transfers: The change of sponsorship of registration of Registered Items from one registrar to another, according to Part B of the ICANN Policy on Transfer of Registrations between Registrars shall not result in the extension of the term of the registration and Registry Operator may assist in such change of sponsorship.

5. Grace and Pending Period Policy

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

  • Registration of a new Registered Item
  • Extension of an existing Registered Item
  • Auto-Renew of an existing Registered Item
  • Transfer of an existing Registered Item
  • Deletion of an existing Registered Item.

5.2 Extension of a registration period is accomplished using the EPP RENEW command or by auto-renewal; registration is accomplished using the EPP CREATE command; deletion is accomplished using the EPP DELETE command; transfer is accomplished using the EPP TRANSFER command or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part.

5.3 There are 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

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

  • Transfer of an existing Registered Item
  • Deletion of an existing Registered Item
  • Restore of a Registered Name in the Redemption Grace Period.

5.5 Grace Periods

5.5.1 Add Grace Period

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

(a) Delete. If a Registered Item is deleted within the Add Grace Period, the sponsoring Registrar at the time of the deletion is credited for the amount of the registration; provided, however, that Registry Operator shall have the right to charge Registrars a fee as set forth on Exhibit A to the Registry-Registrar Agreement for excess deletes during the Add Grace Period. The Registered Item is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.8 for a description of overlapping grace period exceptions.

(b) Renew/Extend. If a Registered Item is renewed/extended within the Add Grace Period, there is no credit for the add. The account of the sponsoring Registrar at the time of the extension will be charged for the initial add plus the number of years the registration is extended. The expiration date of the Registered Item is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Renew/Extend operation.

(c) Holder-Authorized Transfers: Transfers under Part A of the ICANN Policy on Transfer of Registrations between Registrars may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the Registered Item and is enforced by the SRS.

(d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Add Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred Registered Items are not affected. The losing Registrar's account is charged for the initial add.

5.5.2 Renew/Extend Grace Period

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

(a) Delete. If a Registered Item 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. A Registered Name immediately goes into the Redemption Grace Period. A Defensive Registration or a NameWatch Registration is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.8 for a description of overlapping grace period exceptions.

(b) Renew/Extend. A Registered Item can be extended within the Renew/ExtendGrace Period for up to a maximum of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

(c) Holder-Authorized Transfers: If a Registered Item is transferred within the Renew/Extend Grace Period, there is no credit to the losing registrar for the renewal fee. The expiration date of the Registered Item is extended by one year and the years added as a result of the Extend remain on the Registered Item up to a maximum of ten years.

(d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Renew/Extend Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is not credited for the Renew/Extend operation.

5.5.3 Auto-Renew Grace Period

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

(a) Delete. If a Registered Item is deleted within the Auto-Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the Auto-Renew fee. The Registered Name immediately goes into the Redemption Grace Period. A Defensive Registration or a NameWatch Registration is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.8 for a description of overlapping grace period exceptions.

(b) Renew/Extend. A Registered Item can be extended within the Auto-Renew Grace Period for up to a maximum of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

(c) Holder-Authorized Transfers: If a Registered Item is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled. The expiration date of the Registered Item is extended by one year up to a maximum of ten years and the gaining Registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum.

(d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is not credited for the Auto-Renew.

5.5.4 Transfer Grace Period

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

(a) Delete. If a Registered Item is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The Registered Name immediately goes into the Redemption Grace Period. A Defensive Registration or a NameWatch Registration is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 5.8 for a description of overlapping grace period exceptions.

(b) Renew/Extend. If a Registered Item is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be charged for the number of years the registration is extended. The expiration date of the Registered Item is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Renew/Extend operation.

(c) Holder-Authorized Transfers: If a Registered Item is transferred within the Transfer Grace Period, there is no credit. The expiration date of the Registered Item is extended by one year up to a maximum term of ten years. The ICANN Policy on Transfer of Registrations between Registrars does not allow transfers within the first 60 days after another transfer has occurred; it is registrars' responsibility to enforce this restriction.

(d) ICANN-Approved Transfers: Bulk transfers with ICANN approval may be made during the Transfer Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Transfer operation that occurred prior to the Bulk Transfer.

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

5.7 Redemption Grace Period

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

5.8 Overlapping Grace Periods

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

  • If a Registered Item is deleted within the Add Grace Period and the Renew/Extend Grace Period, then the Registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done. The Registered Item is removed from the Registry database and is immediately available for registration by any Registrar.
  • If a Registered Item is auto-renewed, then extended, and then deleted within the Renew/Extend Grace Period, the registrar will be credited for any Auto-Renew fee charged and the number of years for the extension. The years that were added to the Registered Item's expiration as a result of the auto-renewal and extension are removed.

5.8.2 Overlap Exception

  • If a Registered Item is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example, if a Registered Item is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first and second transfers, then only the last transfer is credited to Registrar C.
  • If a Registered Item registration is extended within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.

5.9 Pending Periods

5.9.1 Transfer Pending Period

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

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

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

5.9.2 Pending Delete Period

A Registered Name is placed in PENDING DELETE status if it has not been restored during the Redemption Grace Period. A Registered Item that is in PENDING DELETE status will not be included in the zone file. All registrar requests to modify or otherwise update a Registered Item in PENDING DELETE status will be rejected. A Registered Item is purged from the registry database a specified number of calendar days after it is placed in PENDING DELETE status. The current length of this Pending Delete Period is five (5) calendar days.

6. Nameserver functional specifications

Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966 published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto.

Within eighteen (18) months of the Effective Date, Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions ("DNSSEC"). Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and the parties agree that best practices described in RFC 4641 and its successors are recommended but not mandatory. 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 the "DPS-framework" (currently in draft format, see http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework) within 180 days after the "DPS-framework" becomes an RFC.

Within eighteen (18) months of the Effective Date, 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.

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 Operator 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 but this provision shall not apply to the provision of nameservice or any other non-registry service for a domain or zone used for other than registration services to unaffiliated third parties by a single entity (including its affiliates) for domain names registered through an ICANN-Accredited Registrar.

If the Registry Operator offers Internationalized Domain Names ("IDNs"), it shall comply with RFCs 3492, 5890, 5891, 5892, 5893, 5894 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.

7. Other functional specifications

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

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

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

8. Patch, update, and upgrade policy

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

  • 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.
  • 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.
  • 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 left of the decimal point in the version number of the Licensed Product.
  • 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 both inside and outside scheduled and announced Shared Registration System maintenance periods.

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

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

  • Excessive levels of data traffic
  • Unauthorized traffic; or
  • Data traffic not conforming to the protocols used by the Registry

9. Additional Services

9.1 Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)

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 second and/or third-level domain names, email forwarding addresses and/or Defensive Registrations portfolio in the dot-NAME top-level domain.

At least fifteen days before completing a BTAPPA, the losing registrar must provide to all second and/or third-level domain names, email forwarding addresses and/or Defensive Registrations registrants 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 second and/or third-level domain names, email forwarding addresses and/or Defensive Registration is transferred under the BTAPPA service during any applicable grace period as described in Section 5 above, there is no credit. The expiration dates of transferred registrations are not affected.

Second and/or third-level domain names, email forwarding addresses and/or Defensive Registrations 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". Second and/or third-level domain names, email forwarding addresses and/or Defensive Registrations that are within the auto-renew grace window are subject to bulk transfer, but Registry Operator may decline to provide a credit for those second and/or third-level domain names, email forwarding addresses and/or Defensive Registrations deleted after the bulk transfer, but prior to the expiration of the auto-renew grace window.

Registry Operator 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 Registry Operator or ICANN, or if a registrar with common ownership or management or both has already requested BTAPPA service within the preceding six-month period.

10. Implementation of New Standards

Registry Operator and ICANN agree to engage in good faith negotiations at regular intervals (at least once every eighteen months following the Effective Date) regarding possible implementation of new RFCs related to the matters addressed in Appendices 1 (Escrow Specifications), 5 (Whois) and 7 (Technical and Functional Specifications).

11. Miscellaneous

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

11.2 The Registry Operator shall provide to ICANN and publish on its website its accurate contact details including a valid email and mailing address as well as a primary contact for handling inquiries related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details