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.

.com Registry Agreement Appendix 7

Functional and Performance Specifications

(1 December 2012)

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

1. Registry Operator Registrar Protocol;

2. Supported initial and renewal registration periods;

3. Grace period policy;

4. Nameserver functional specifications;

5. Patch, update, and upgrade policy;

6. Performance Specifications;

7. Responsibilities of the Parties;

8. Additional Services; and

9. Implementation of New Standards

 

1. Registry Operator Registrar Protocol

1.1 Extensible Provisioning Protocol

Registry Operator shall maintain the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 5730, 5731, 5732, 5734, 5910, and 3915 (and in the event Registry Operator accepts thick registration data RFC 5733) published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Registry Operator will support EPP in conformance with the aforementioned standards. 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. 

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 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 the SRS over IPv6.

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.

2. Supported initial and renewal registration periods

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

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

2.3. 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 sponsorship change shall not exceed ten years.

2.4. 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 registrations 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,
  • Renewal 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
  • Restoration 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, Extend (EPP Renew command), 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 may be set forth in its Registry-Registrar Agreement for disproportionate 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.

Extend (EPP Renew command). If a domain is extended within the Add Grace Period, there is no credit for the add. 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 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 through an EPP Command Renew. 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 immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend ("EPP Command 'Renew'"). A domain 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 immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

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

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, 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 immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

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 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 the Registrar's 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 cannot 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 than 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 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.
  • If a domain is auto-renewed, then extended, and then deleted within the Extend Grace Period, the Registrar will be credited for any Auto-Renew fee charged and the number of years for the extension.

3.2.1. Overlap Exception

  • 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 Operator 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. SYNC is not allowed.
c. EPP DELETE request is denied.
d. Bulk Transfer operations are allowed.
e. EPP UPDATE request is denied.



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

3.3.2. Pending Delete Period

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

4. Nameserver functional specifications

Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, 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.

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.

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

5. Patch, update, and upgrade policy

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

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

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

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

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

6. Performance Specifications

These Performance Specifications provide a means to measure Registry Operator's delivery of SRS, DNS Name Server and Whois services for the Registry TLD and serve as the basis for the Service Level Agreements Credits ("SLA Credits") set forth in Appendix 10.

6.1 Definitions. Capitalized terms used in this Section 6 and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.

6.1.1 "Core Internet Service Failure" means an extraordinary and identifiable event beyond the control of Registry Operator affecting the Internet services to be measured pursuant to this Section 6. Such events include, but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.

6.1.2 "Credit Level" means the credit levels set forth in the Table SLA Credits in Section 2 of Appendix 10 that outlines the total credits, penalties and/or liabilities that may be assessed to Registry Operator and sole remedies available to ICANN-Accredited Registrars for Registry Operators failure to meet Performance Specifications outlined in this Appendix 7.

6.1.3 "DNS Name Server" means the service complying with RFC 1034, 1035 and related RFCs made available on TCP/UDP port 53 on Registry Operator's selected servers.

6.1.4 "ICANN-Accredited Registrar" means an ICANN-Accredited Registrar that has a Registry-Registrar Agreement in effect with Registry Operator.

6.1.5 "Monthly Timeframe" means each single calendar month beginning and ending at 0000 Coordinated Universal Time (UTC).

6.1.6 "Performance Specifications" means a description of the measurable functional attributes of a particular System Services.

6.1.7 "Registrar Community" means all of the ICANN-Accredited Registrars who have Registry-Registrar Agreements in effect with Registry Operator for the Registry TLD and who have registered greater than 150 net new .com domain names in the prior thirty (30) calendar day period.

6.1.8 "Round-trip" means the amount of measured time that it takes for a reference query to make a complete trip from the SRS gateway, through the SRS system, back to the SRS gateway.

6.1.9 "Service Level Agreement (SLA)" means the service level agreements attached as Appendix 10 to the Registry Agreement outlining performance standards levels.

6.1.10 "SRS" means the Shared Registration System, a system that the Registry Operator provides to the Registrar Community via a defined protocol (EPP) for registry-registrar interaction. Specifically, it refers to the ability of ICANN-Accredited Registrars to add, modify, and delete (create, update and delete) information associated with registered domain names and associated DNS Name Servers.

6.1.11 "System Services" means the SRS, DNS Name Server and Whois services for the Registry TLD for which availability and Performance Specifications are established.

6.1.12 "Whois" refers to the Registry Operator's Whois service provided in accordance with Appendix 5.

6.2 Service Availability. Service availability is defined as the time, in minutes, that the Registry Operator's System Services are each individually responding to its users ("Service Availability") as further defined in Sections 6.2.1 through 6.2.4.

6.2.1 Service Availability is measured as follows:

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

MTM = Monthly Timeframe Minutes calculated as the number days in that month times 24 hours times 60 minutes. For example, the MTM for January is 31 days * 24 hours * 60 minutes or MTM = 44,640 minutes.

POMU = Planned Outage Minutes Used equals the number of minutes of a Planned Outage (as defined in Section 6.3 below) or Extended Planned Outage (as defined in Section 6.4 below) for that Monthly Timeframe for each individual System Service. No Monthly Timeframe shall have both a Planned and an Extended Planned Outage.

UOM = Unplanned Outage Minutes equals the total number of minutes the System Services is unavailable excluding any Planned Outages (as defined in Section 6.3 below) or Extended Planned Outage (as defined in Section 6.4 below) for that Monthly Timeframe.

The Service Availability calculation shall be calculated by the Registry Operator and the results reported for each Monthly Timeframe for SRS, Whois and DNS Name Server availability. For Service Availability Performance Specifications measured by calendar year, Yearly Timeframe Minutes (YTM) shall be substituted for Monthly Timeframe Minutes (MTM) in the calculation above. Yearly Timeframe Minutes calculated as 365 days * 24 hours * 60 minutes = 525,600 minutes. Results will be reported to the Registrar Community via e-mail and to ICANN according to Appendix 4.

6.2.2 Service Availability--SRS = 99.99% per calendar year. Service Availability as it applies to the SRS refers to the ability of the SRS to respond to ICANN-Accredited Registrars that access the SRS through the EPP protocol. SRS unavailability, except for Planned Outages (as defined in Section 6.3 below) and Extended Planned Outages (as defined in Section 6.4 below), will be logged with the Registry Operator as Unplanned Outage Minutes. Unavailability will not include any events affecting individual ICANN-Accredited Registrars locally.

SRS unavailability as it applies to the SRS shall mean when, as a result of a failure of systems within the Registry's control, an ICANN-Accredited Registrar is unable to establish a session with the SRS gateway; provided, however, that SRS unavailability shall not include an ICANN-Accredited Registrar's inability to establish a session with the SRS gateway that results from it exceeding its designated number of sessions. Establishing a session with the SRS gateway shall be defined as:

a) successfully complete a TCP session start,

b) successfully complete the SSL authentication handshake, and

c) successfully complete the Extensible Provisioning Protocol (EPP) login command.

Registry Operator will log SRS unavailability once an ICANN-Accredited Registrar reports an occurrence to Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone). The committed Service Availability for SRS is 99.99% per calendar year. The SRS Service Availability metric is a Credit Level 2.

6.2.3 Service Availability--DNS Name Server = 100% per Monthly Timeframe. Service Availability as it applies to the DNS Name Server refers to the ability of the DNS Name Server to resolve a DNS query from an Internet user. DNS Name Server unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. Registry Operator will log DNS Name Server unavailability (a) when such unavailability is detected by monitoring tools, or (b) once an ICANN-Accredited Registrar reports an occurrence to Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone) and Registry Operator confirms that the occurrence is not unique to the reporting Registrar.

DNS Name Server unavailability shall mean less than eight (8) sites on the Registry Operator's constellation are returning answers to queries with less than 1% packet loss averaged over a Monthly Timeframe or 5% packet loss for any five minute period.

The committed Service Availability for DNS Name Server is 100% per Monthly Timeframe. The DNS Name Server Service Availability metric is a Credit Level 1.

6.2.4 Service Availability--Whois = 100% per Monthly Timeframe. Service Availability as it applies to Whois refers to the ability of Internet users to access and use the Whois. Whois unavailability, except for Planned Outages (as defined in Section 6.3 below) and Extended Planned Outages (as defined in Section 6.4 below), will be logged with the Registry Operator as Unplanned Outage Minutes. Registry Operator will log Whois unavailability (a) when such unavailability is detected by Registry Operator's monitoring tools, or (b) once an ICANN-Accredited Registrar reports an occurrence to Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone). The committed Service Availability for Whois is 100% per Monthly Timeframe. The Whois Service Availability metric is a Credit Level 2.

6.3 Planned Outage. From time to time the Registry Operator will require an outage for regular maintenance or the addition of new functions or features ("Planned Outage").

6.3.1 Planned Outage Duration. Planned Outage duration defines the maximum allowable time, in minutes, that the Registry Operator is permitted to take the System Services out of service for regularly scheduled maintenance ("Planned Outage Duration"). Planned Outages are planned in advance and the Registrar Community is provided notification prior to an outage.

The Planned Outage Duration for the System Services is as follows:

(i) Planned Outage Duration - SRS = 45 minutes per Monthly Timeframe;

(ii) Planned Outage Duration - DNS Name Server = no Planned Outages allowed; and

(iii) Planned Outage Duration - Whois = no Planned Outages allowed.

The Planned Outage Duration metric is a Credit Level 6.

6.3.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which a Planned Outage may occur ("Planned Outage Timeframe"). The Planned Outage Timeframe for the System Services is as follows:

(i) Planned Outage Timeframe - SRS = 0100-0900 UTC Sunday;

(ii) Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and

(iii) Planned Outage Timeframe - Whois = no Planned Outages allowed.

The Planned Outage Timeframe metric is a Credit Level 5.

6.3.3 Planned Outage Notification. The Registry Operator shall notify all ICANN-Accredited Registrars of any Planned Outage ("Planned Outage Notification"). The Planned Outage Notification shall set forth the date and time of the Planned Outage. The number of days prior to a Planned Outage that the Registry Operator shall notify the Registrar Community is as follows:

(i) Planned Outage Timeframe - SRS = 30 days for general maintenance and 90 days for Updates or Upgrades as defined in the Patch, Update and Upgrade Policy in Section 5 of this Appendix 7;

(ii) Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and

(iii) Planned Outage Timeframe - Whois = no Planned Outages allowed.

The Planned Outage Notification metric is a Credit Level 5.

6.4 Extended Planned Outage. In some cases, such as major software upgrades and platform replacements, an extended maintenance timeframe is required ("Extended Planned Outage"). Extended Planned Outages will be less frequent than Planned Outages but their duration may be longer.

6.4.1 Extended Planned Outage Duration. The Extended Planned Outage duration defines the maximum allowable time, in hours and minutes that the Registry Operator is permitted to take the System Services out of service for extended maintenance ("Extended Planned Outage Duration"). Extended Planned Outages are planned in advance and the Registrar Community is provided notification in accordance with Section 6.4.3. Extended Planned Outage periods may not occur in the same Monthly Timeframe as a Planned Outage. The Extended Planned Outage Duration for the System Services is as follows:

(i) Extended Planned Outage Duration - SRS = 4 hours (240 minutes) per calendar year and one Extend Planned Outage of 8 hours (480) minutes every 3 years;

(ii) Extended Planned Outage Duration - DNS Name Server = no Extended Planned Outages allowed; and

(iii) Extended Planned Outage Duration - Whois = no Extended Planned Outages allowed.

The Extended Planned Outage Notification metric is a Credit Level 6.

6.4.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage may occur ("Extended Planned Outage Timeframe"). The Extended Planned Outage Timeframe for the System Services is as follows:

(i) Extended Planned Outage Timeframe - SRS = 0100 - 1300 UTC Sunday;

(ii) Extended Planned Outage Timeframe - DNS Name Server = no Extended Planned Outages allowed; and

(iii) Extended Planned Outage Timeframe - Whois = no Extended Planned Outages allowed.

The Extended Planned Outage Notification metric is a Credit Level 5.

6.4.3 Extended Planned Outage Notification. The Registry Operator must notify the Registrar Community of any Extended Planned Outage ("Extended Planned Outage Notification"). The Extended Planned Outage Notification shall set forth the date and time of the Extended Planned Outage. The number of days prior to an Extended Planned Outage that the Registry Operator must notify ICANN-Accredited Registrars is as follows:

(i) Extended Planned Outage Timeframe - SRS = 90 Days;

(ii) Extended Planned Outage Timeframe - DNS Name Server = no Extended Planned Outages allowed; and

(iii) Extended Planned Outage Timeframe - Whois = no Extended Planned Outages allowed.

The Extended Planned Outage Notification metric is a Credit Level 5.

6.5 Processing Time. Processing time is a measurement of Service Availability and equals the Round-trip for the System Services ("Processing Time"). The Registry Operator will log the Processing Time for all of the protocol transactions (i.e. Check, Add/Create, Modify/Update and Delete). Processing Time will be measured in a Monthly Timeframe and reported on a monthly basis to ICANN in accordance with Appendix 4. Should the total volume of protocol transactions (measured individually) added by all ICANN-Accredited Registrars for a Monthly Timeframe exceed Registry Operator's actual volume of protocol transactions for the previous Monthly Timeframe by more than 20%, then ICANN-Accredited Registrars shall not be eligible for any SLA credit, and Registry Operator shall have no liability to ICANN, if Registry Operator fails to meet a Processing Time Performance Specification set forth in this Section 6.5.

6.5.1 Processing Time--Check Domain = 25 milliseconds for 95%.

(i) The Processing Time for Check Domain is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for an availability check of a specific domain name.

(ii) The performance specification for Check Domain is 25 milliseconds Round-trip for 95% of the transactions during a Monthly Timeframe.

The Processing Time for Check Domain metric is a Credit Level 3.

6.5.2 Processing Time--Add/Create = 50 milliseconds for 95%.

(i) The Processing Time for Add/Create is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for add/create transactions associated with domain names.

(ii) The Performance Specification for Add/Create is 50 milliseconds for Round-trip for 95% of the transactions processed during a Monthly Timeframe.

The Processing Time for Add/Create metric is a Credit Level 3.

6.5.3 Processing Time--Modify/Update and Delete Domain = 100 milliseconds for 95%.

(i) The Processing Time for Modify/Update and Delete is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for Modify/Update and Delete transactions associated with domain names.

(ii) The Performance Specification for Modify/Update and Delete is 100 milliseconds Round-trip for 95% of the transactions processed during a Monthly Timeframe.

The Processing Time for Modify/Update and Delete metric is a Credit Level 3.

6.5.4 Processing Time--Whois Query = 5 milliseconds for 95%.

(i) The Processing Time for Whois query is applicable to the Whois and measures the Processing Time for a Whois query.

(ii) The Performance Specification for a Whois query is 5 milliseconds for 95% of the transactions during a Monthly Timeframes. That is, 95% of the transactions during a Monthly Timeframe will take 5 milliseconds or less from the time the Whois receives a query to the time it responds.

The Processing Time for Whois Query metric is a Credit Level 3.

6.5.5 Processing Time--DNS Name Server Resolution = 100 milliseconds for 95%.

(i) The Processing Time for DNS Name Server Resolution is applicable to the DNS Name Server and measures the processing time for a DNS query.

(ii) The Performance Specification for DNS Name Server Resolution is 100 milliseconds for 95% of the transactions during a Monthly Timeframe. That is, 95% of the transactions during a Monthly Timeframe will take 100 milliseconds or less from the time the name server receives the DNS query to the time it provides a response.

The Processing Time for the DNS Name Server metric is a Credit Level 3.

6.6 Update Frequency. The Registry Operator makes timely updates to the data on the DNS Name Servers and Whois. ICANN-Accredited Registrars record these updates through the SRS. The SRS then updates the DNS Name Server and the Whois. Registry Operator processes this updates on a near real time basis.

The committed performance specification with regards to Update frequency for both the DNS Name Server and the Whois is 3 minutes for 95% of the transactions during a Monthly Timeframe. That is, 95% of the updates to the DNS Name Servers and Whois during a Monthly Timeframe will be completed within 3 minutes. Update frequency is measured from the time that the Registry Operator confirms the update to the time the update appears in the DNS Name Server and Whois. Update frequency performance will be reported on a monthly basis to ICANN in accordance with Appendix 4.

6.6.1 Update Frequency--DNS Name Server = 3 minutes for 95% during a Monthly Timeframe.

The Update frequency--DNS Name Server is 3 minutes for 95% during a Monthly Timeframe.

The Update frequency metric for DNS Name Server is Credit Level 4.

6.6.2 Update Frequency--Whois - 3 minutes for 95% during a Monthly Timeframe.

The Update frequency--Whois is 3 minutes for 95% during a Monthly Timeframe.

The Update frequency metric for Whois is Credit Level 4.

6.7 Cross-Network Name Server Performance Requirements. DNS Name Server Round-trip 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 SLA Credits under the Service Level Agreement set forth on Appendix 10 or obligations upon which a breach by Registry Operator of the Registry Agreement may be asserted.

The committed performance specification for cross-network name server performance is a measured Round-trip of under 300 milliseconds and measured packet loss of under 1% averaged over the course of a Monthly Timeframe and no greater than 5% for any five (5) minute period over the course of the Monthly Timeframe. Cross-network name server performance measurements may be conducted by ICANN at the times of its choosing, in the following manner:

6.7.1 The measurements may be conducted by sending strings of DNS request packets from different measuring locations to each of the .com DNS Name Servers and observing the responses from the .com DNS Name Servers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be distributed around the Internet.

6.7.2 Each string of request packets will consist of UDP or TCP packets requesting nameserver (NS) records for arbitrarily selected .com 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 may be noted.

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

6.7.3.1 The Round-trip and packet loss from each measurement location to at least one .com name server must not exceed the required values;

6.7.3.2 The packet loss to each of the .com name servers from at least one of the measurement locations must not exceed the required value; and

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

6.7.4 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 may only be deemed to have persistently failed to meet the cross-network name server performance requirement only if the .com DNS Name Servers fail the CNNP Tests (see Section 6.7.3 above) with no less than three consecutive failed CNNP Tests.

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

6.7.6 Sixty days prior to the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the testing system to be used by ICANN. In the event that Registry Operator raisees concerns regarding such system, ICANN will work directly with Registry Operator to attempt to address those concerns.

7. Responsibilities of the Parties.

7.1 Except in the case of DNS Name Server 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.

7.2 The Registry Operator will provide system performance and availability reports monthly to the Registrar Community via e-mail and to ICANN according to Appendix 4.

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

7.4 The Registry Operator will use commercially reasonable efforts to restore the critical systems of the System 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 for purposes of this Appendix 7 or the SLA.

7.5 Registry Operator shall not be liable to ICANN or ICANN-Accredited Registrars for any credits or penalties or be deemed to be in breach of any of its obligations under the Registry Agreement if it fails to meet a Performance Specification as a result of its compliance with any Consensus Policy established after the Effective Date to the extent and for so long as the failure to meet a Performance Specification is unavoidable by commercially reasonable efforts due to Registry Operator's compliance with such Consensus Policy.

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

8. Additional Services

8.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 domain name portfolio in the .com 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 Verisign 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.

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

9. Implementation of New Protocols

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