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

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


ICANN Logo

.ORG Agreement Appendix 7 
Functional Specifications 
(22 August 2013)

 

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

1.    Registry Operator Registrar Protocol;

2.    Supported initial and renewal registration periods;

3.    Grace period policy;

4.    DNS;

5.    IDN;

6.    IPv6; and

7.    Additional Services

1. Registry Operator Registrar Protocol

1.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 exceeding a total of ten years.

c. Upon change of sponsorship of the registration of a Registered Name from one registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the Registered Name shall be extended by one year, provided that the maximum term of the registration as of the effective date of the sponsorship change shall not exceed ten years.

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

3. Grace and Pending Period Policy

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

·         Registration of a new domain,

·         Extension of an existing domain,

·         Auto-Renew of an existing domain;

·         Transfer of an existing domain; and

·         Deletion of an existing domain.

·         Restore of a deleted domain

Extension of a registration period is accomplished using the EPP RENEW command or by auto-renewal; registration is accomplished using the EPP CREATE command; deletion is accomplished using the EPP DELETE command; transfer is accomplished using the EPP TRANSFER command or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part. Restore is accomplished either by using the Restore screen in the web-based administrative site, or by using the EPP UPDATE command with the RGP extension; provided, however, that in the case of (i) Bulk Transfers under Part B of the ICANN Policy on Transfer of Registrations between Registrars and (ii) Large Incidents, Restore may be accomplished by e-mail or fax using a Restore Request Form as specified by Registry Operator.

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

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

·         Transfer of an existing domain,

·         Deletion of an existing domain, and

·         Restore of a domain name in Redemption Grace Period.

3.1 Grace Periods

3.1.1 Add Grace Period

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

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

Excess Deletes: An Excess Deletion Fee will be charged pursuant to Appendix 8, Exhibit A of the Registry Agreement when the number of deleted registrations within the five-day add grace period is in excess of ninety percent (90%) of the total number of initial registrations made by the registrar over a relevant time period as determined by PIR.

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

Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between Registrars may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the domain name registration and is enforced by the SRS.

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

3.1.2 Renew/Extend Grace Period

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

Delete. If a domain is deleted within the Renew/Extend Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the renew/extend fee. The domain is deleted from the Registry database and is moved to the Redemption Grace Period (that is, to the status: Pending Delete – Restorable). See Section 3.2 for a description of overlapping grace period exceptions.

Renew/Extend. A domain registration can be extended within the Renew/Extend Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

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

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

3.1.3 Auto-Renew Grace Period

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

Delete. If a domain is deleted within the Auto-Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the Auto- Renew fee. The domain is deleted from the Registry database and is moved to the Redemption Grace Period (that is, to the status: Pending Delete – Restorable). See Section 3.2 for a description of overlapping grace period exceptions.

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

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled. The expiration date of the domain is extended by one year up to a total maximum of ten and the gaining Registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum.

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

3.1.4 Transfer Grace Period

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

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

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

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Transfer Grace Period, there is no credit. The expiration date of the domain registration is extended by one year up to a maximum term of ten years. The ICANN Policy on Transfer of Registrations between Registrars does not allow transfers within the first 60 days after another transfer has occurred; it is registrars’ responsibility to enforce this restriction.

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

3.1.5 Bulk Transfer Grace Period

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

3.1.6 Redemption Grace Period

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

3.2 Overlapping Grace Periods

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

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

• If a domain is auto-renewed, then extended, and then deleted within the Renew/Extend Grace Period, the registrar will be credited for any Auto-Renew fee charged and the number of years for the extension. The years that were added to the domain’s expiration as a result of the auto-renewal and extension are removed. The deleted domain is moved to the Redemption Grace Period (that is, to the status: Pending Delete -- Restorable).

3.2.1 Overlap Exception

• If a domain is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example, if a domain is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first and second transfers, then only the last transfer is credited to Registrar C.

• If a domain registration is extended within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.

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

3.3 Pending Periods

3.3.1 Transfer Pending Period

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

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

b. AUTO-RENEW is allowed.

c. EPP DELETE request is denied.

d. Bulk Transfer operations are allowed.

e. EPP UPDATE request is denied.

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

3.3.2 Pending Delete Period

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

4. 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 ORG 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 .ORG domain names. Registry Operator reserves the right to allocate less than all of the previously reserved single and two-character .ORG domain names.

Pursuant to the Phased Allocation Program, Registry Operator shall allocate the domain names through an auction process to registrants who commit to building out the domain with a sound marketing and branding strategy to include but not limited to a strong focus on quality, creativity, and the ability to launch the initiative in a timely manner.

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

The parties have duly executed this Amendment as of the date first written below.

 

7.2 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 .ORG 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 Registry Operator 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.

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.

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.