ICANN | General Counsel's Briefing Regarding Proposed Registry Agreement Revisions | 25 January 2003
  ICANN Logo

General Counsel's Briefing Regarding Proposed Revisions to .com and .net Registry Agreements to Reflect Services Introduced 25 January 2003
23 February 2003


General Counsel's Analysis of VeriSign Global Registry Services' Request for Amendment to Registry Agreement


To the Board:

One topic on the agenda for the 25 February 2003 Board meeting is approval of revision of .com and .net registry agreements to reflect new services introduced on 25 January 2003 (Redemption Service; ConsoliDate). This memo is to provide you background and recommendations on this topic.

On 25 January 2003, VeriSign's registry performed a software upgrade (these occur about three times yearly). The most significant change in this upgrade was the separation of .org (the operation of which was transferred to Afilias, PIR's contractor) from .com and .net (which VeriSign continues to operate). However, three other significant new/changed services/functions were also introduced with this upgrade:

1. Redemption Grace Period
2. ConsoliDate
3. Inclusion of registry expiration dates and status in registry Whois output

The purpose of the agenda topic is to authorize updating the .com and .net registry agreements to reflect these changes.

1. Redemption Grace Period

As you may recall, the Redemption Grace Period is an ICANN-proposed initiative to respond to the increasing number of complaints made by customers with domain names that were unintentionally deleted and then registered by someone else, often using the domain name to display content repugnant to the former registrant. Frequently the registrant experienced significant delays and costs (many thousands of dollars paid to the new registrant) to recover the that name and have the former services (web service, e-mail, etc.) restored.

To address these very unfortunate situations, the ICANN staff proposed inserting a 30-day period after deletion of every name, in which the domain name would no longer resolve but the former registrant (and only the former registrant) could have the name restored for a fee. After favorable public discussion, the Board concluded that the idea should be further explored. [See also this supplemental paper.] At its Accra meeting, the Board adopted the following resolution:

Redemption Grace Period

Whereas, on 14 February 2002 the ICANN staff posted a proposal to establish a Redemption Grace Period for unsponsored TLDs under which names deleted by registrars would be deactivated for thirty days, during which the registrant could redeem the name through a registrar before being subject to re-registration;

Whereas, the proposal was the topic of discussion by registrars, registry operators, and users, including at numerous meetings, through e-mail, and at the ICANN Public Forum held 13 March 2002 in Accra, Ghana;

Whereas, the commentary received has shown that some domain names are being deleted without the intention of the domain-name holder;

Whereas, the community discussions have demonstrated broad support for the general points of the Redemption Grace Period Proposal, with the recognition that several technical details must be worked out before the proposal can be implemented;

Resolved [02.45] that the President is authorized to convene a technical steering group (including knowledgeable registry and registrar personnel and in consultation with the Domain Name Supporting Organization) to develop a concrete proposal implementing the Redemption Grace Period Proposal, to be considered by the Board at a later meeting after posting on the ICANN web site and an opportunity for public comment.

A technical steering group (consisting of three gTLD registrar representatives and three gTLD registry representatives) was convened and issued a report recommending adoption of the period and providing proposals for implementation details.

The technical steering group's proposal received broad community support. In response to this, the Board adopted the following resolution in Bucharest:

Redemption Grace Period

Whereas, ICANN resolution 02.45 authorized the convening of a technical steering group to develop a concrete proposal for implementation of a Redemption Grace Period for deleted domain names;

Whereas, the Technical Steering Group's Implementation Proposal was posted on the ICANN website on 7 June 2002;

Whereas, the proposal called for implementing a Redemption Grace Period by instituting an extended Delete Pending Period and a new Restore capability, which will be a new Registry Service for which registry operators will be able to charge a cost-based service fee;

Whereas, the Redemption Grace Period proposal was discussed and received broad community support at the ICANN Public Forum held 27 June 2002 in Bucharest, Romania;

Resolved [02.83] that the President and General Counsel are authorized to conduct negotiations on behalf of ICANN toward appropriate revisions to agreements between ICANN and the unsponsored TLD registry operators to implement the Redemption Grace Period in a manner consistent with the Technical Steering Group's Implementation Proposal.

Following up on this resolution, I discussed at length with VeriSign (at the time the operator of .com, .net, and .org, the only contracted gTLDs with a significant number of deletions) the implementation of the Redemption Grace Period. VeriSign agreed to develop the necessary software modifications to its registry system for deployment in the software release that occurred on 25 January 2003. The VeriSign offering provides registrars with three options for restoring deleted domains – through the automated Registry-Registrar Protocol, through a web-based Registrar Tool, or by contacting VeriSign Registry customer service – and otherwise is in substantial compliance with the recommendations of the Technical Steering Group.

The Technical Steering Group recommended that the new service be funded by "a cost-based fee as mutually agreed between each registry and ICANN for 'restoring' names." As the time for deployment approached, VeriSign submitted cost data and, based on that data, I preliminarily approved introduction of the service at a fee level of US$ 85 (for the first 2000) and then US$ 40 (thereafter) per restore operation. The approval also stipulated that VeriSign would not charge for restoring domains that had been deleted trhough registry error. This approval was based on VeriSign's estimated costs and other factors, as recited in my 15 January 2003 letter giving the preliminary approval. The approval provided that it was subject to revision by the Board upon its consideration of the matter.

My 15 January 2003 letter is attached. I recommend that the Board now authorize revision of the .com and .net registry agreements to make the preliminary authorization permanent. The revision will require adjustment of several appendices; I have attached the two most relevant: Appendix G (price) and Appendix C, part 7 (the Redemption Service description).

I also recommend that the Board express its sentiment that registrars (like the registry operator) should not charge customers for restoring domain names that are deleted due to their own error. Although issues such as this involving economic terms between registrars and their customers are governed by market forces rather than any ICANN agreement, it seems appropriate for the Board to express the common-sense expectation that customers should not suffer financially from registrar errors.

I am in very preliminary discussions with the other gTLD registry operators regarding implementation of the Redemption Service; I hope these can be concluded and the service instituted in those TLDs in the next several months.

2. ConsoliDate

ConsoliDate is a VeriSign-proposed service designed to allow registrants (such as companies with large portfolios of domain names) to synchronize the exipration dates of the domain registrations. It allows the registrant to add any number of days to a registration's term from one day to one day less than a year, for a maximum fee depending on the length of extension ranging from US$3 to US$14. Because annual renewals are still available for US$6, there appears to be no significant harm in allowing this service at VeriSign's proposed fee, and in my 15 January 2003 letter I preliminarily approved introduction of the service on the terms VeriSign proposed, again subject to revision by the Board upon its consideration of the matter.

My 15 January 2003 letter and the attached drafts of Appendix G and Appendix C, part 7 (ConsoliDate Service description) provide additional details.

I recommend that the Board authorize revision of the .com and .net registry agreements to reflect this service.

3. Inclusion of registry expiration dates and status in registry Whois output

Also on 25 January 2003, the format of the registry-level Whois was revised to include the expiration (and creation) dates and status of registered names. This change was in part to support the requirements stated by the Technical Steering Group for the Redemption Grace Period. An example registry Whois output is as follows:

Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.

Domain Name: ROOT-SERVERS.NET
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: A.ROOT-SERVERS.NET
Name Server: F.ROOT-SERVERS.NET
Name Server: J.ROOT-SERVERS.NET
Name Server: K.ROOT-SERVERS.NET
Status: REGISTRY-LOCK
Updated Date: 23-aug-2002
Creation Date: 04-jul-1995
Expiration Date: 03-jul-2005

>>> Last update of whois database: Sun, 23 Feb 2003 17:33:01 EST <<<

Various minor adjustments to some appendices are appropriate in view of this change to the registry Whois output.

I will circulate suggested resolution language under separate cover.

Best regards,

Louis Touton
General Counsel


Appendix C to .com and .net Registry Agreements

The text below would be added as a new part 7 of Appendix C of the .com and .net Registry Agreements.


Functional Specification

* * *

7. Additional Services Descriptions

A. Redemption Service

Overview

The Redemption Service allows registrars to restore Registered Names that were unintentionally deleted and are still within a thirty-day Redemption Period.

Detailed Implementation – States

The Redemption Service is implemented by applying the following statuses through which deleted names progress:

REDEMPTIONPERIOD: A domain name is placed in REDEMPTIONPERIOD status when a registrar requests the deletion of a name 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 name in REDEMPTIONPERIOD status. The only action a registrar can take on a name 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 thirty calendar days.

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

PENDINGRESTORE: A domain name is placed in PENDINGRESTORE status when a registrar requests restoration of a domain that is in REDEMPTIONPERIOD status. A name that is in PENDINGRESTORE status will be included in the zone file. Registrar requests to modify or otherwise update a domain in REDEMPTIONPERIOD status will be rejected. A domain name is returned to REDEMPTIONPERIOD status a specified number of calendar days after it is placed in PENDINGRESTORE unless the registrar submits a complete Registrar Restore Report to the Registry Operator. The current length of this Pending Restore Period is seven calendar days.

Detailed Implementation – Command

The implementation of the Redemption Service involves one command:

RESTORE Command: Registrars may restore names by submitting an RRP Restore command, by using the registrar tool, or by contacting customer service. Once the RRP Restore Command is executed, the Registrar must submit the Restore Report through the Registrar Tool. The Restore Report cannot be submitted through the RRP interface. Deleted Names in REDEMPTIONPERIOD status can be restored by registrars without delay or required interaction with Registry Customer Service personnel.

Appropriate Use of the Restore Capability

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

Registrar Reporting Requirement

In order to facilitate verification of registrar compliance with the intended purpose of the Redemption Service, Registrars are required to submit a "Registrar Restore Report" to the Registry Operator with a copy to ICANN. The report should be submitted within two business days after restoring any deleted name. The report will document the circumstances that created the need to restore the Registered Name.

The Registrar Restore Report will be transmitted electronically according to a format to be specified, and shall include the following contents:

1. A copy of the Whois data for the deleted name, as it appeared prior to the deletion;

2. A copy of the Whois data for the deleted name, as it appears at the time the report is being submitted;

3. The date and time the Registered Name was deleted;

4. The date and time the Registered Name was restored;

5. A brief written explanation of the reason why the Registered Name was Restored (e.g., registrant mistake, registrar mistake, registry mistake, dispute resolution);

6. A statement that the registrar has not restored the Registered Name in order to assume the rights to use or sell the Registered Name for itself or for any third party (unless the name was restored as required to give effect to an order or decision from a court, arbitral tribunal or Administrative Panel – in such cases a copy of the order should be included with the report); and

7. A statement that the information in the Restore Report is true to best of the registrar’s knowledge, and that the registrar acknowledges that intentionally supplying false information in the Restore Report shall constitute an incurable material breach of the Registry-Registrar Agreement.

If the registrar fails to submit a complete Registrar Restore Report at the end of the Pending Restore Period, the Registry Operator will (following an attempt to notify the registrar by both telephone and e-mail) return the name to REDEMPTIONPERIOD status (subject to a new Redemption Period.) Any subsequent invocation of the RESTORE command will be incur the applicable charge, independent of charges for earlier RESTORE commands.

The registry will maintain (for two years) copies of all Registrar Restore Reports, subject to ICANN review, and will include in its monthly report to ICANN the number of Restore Reports received (see Appendix T).

In order to ensure the effectiveness of this reporting provision, registrar requests to modify, transfer, or otherwise update domains in PENDINGRESTORE status will be rejected.

Registry Transparency – Registrar Reports

Also, the Registry Operator will make lists of all names in PENDINGDELETE status available to all registrars (and the corresponding dates of deletion from the registry database) available to all registrars via FTP or other means. In order to provide equal notice to all registrars about which names will actually drop, no registrar can modify or restore a name in PENDINGDELETE status.

Registry Transparency – Public Whois

See Appendix O.

Registry Fees for Restoring Deleted Names

The maximum registry fee for restoring a deleted name is set forth in Appendix G to the Registry Agreement. The Redemption Service fee is separate from, and in addition to, the ordinary charges for registration term extensions.

B. ConsoliDate Service

Overview

The ConsoliDate service allows registrars to offer their customers the ability to obtain a specific anniversary date for any domain name registration. Registrants will have the entirely optional ability to synchronize (or stagger) the expiration date of their registrations in order to simplify record-keeping and accounting.

Interface

The ConsoliDate service is implemented by means of the SYNC command. The ability to SYNC a registration will be available through both the Registry-Registrar Protocol (RRP) and the Registrar Web Tool.

The SYNC command allows a registrar to move the expiration date of a domain name forward to a specific month and day. The request to synchronize a domain name MUST contain the following data:

  • The "EntityName" parameter set to value "Domain".
  • Fully qualified second level domain name in the "DomainName" parameter.
  • The "Date" parameter to identify the month and day, in the format mm-dd (e.g., 01-05 for January 5th.)

In the following example, a registrar synchronizes a domain name to January 5th. A client (a registrar) types the lines beginning with "C:" and a server (the Registry) returns the lines beginning with an "S:"

C:SYNC<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:Date:01-05<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:RegistrationExpirationDate:2006-01-05
10:27:00.000<crlf>
S:.<crlf>

System Calculations for SYNC Command

A successfully completed SYNC command extends the domain name forward to the date specified by the registrar, and returns the new registration expiration date in the "RegistrationExpirationDate" attribute in the response.

The SYNC command is entirely separate from the ADD and RENEW commands. Registrars are still able to ADD and RENEW domains in increments of one to ten years. The SYNC command may not extend a domain name registration beyond the 10-year registration limit.

The minimum extension of a domain’s expiration date is until the following day. The maximum extension of a domain is one year minus one day. SYNC can only be used to extend a domain’s expiration date, not to remove time from a domain’s registration term. (In other words, a registration can only have its expiration date SYNC’d forward, not backwards in time.)

A registrar can only use the SYNC command once per year, per domain. (The service cannot be used as a de facto month-over-month renewal for registrations.) The registrar can re-set this limitation by executing a renewal or self-transfer of the registration.

The registry will reject any SYNC command and return an error response code if the requested sync-to date is missing, invalid, or the same as the current anniversary date. Also, the SYNC command will not accept a request to move the anniversary date to 29 February.

SYNC Command Availability

The SYNC command applies only to already-registered domains in "ACTIVE" status.

The SYNC command is not available while a domain is in Transfer Pending status. (A registrar must first NAK the transfer before executing the SYNC command. This is consistent with the current rules surrounding explicit renewals for a registration within the Transfer Pending status.)

The SYNC command is also not available (i.e. a SYNC request will be rejected) if a domain is in any of the following statuses:

  • REGISTRY-LOCK
  • REGISTRY-HOLD
  • REGISTRAR-LOCK
  • REGISTRAR-HOLD
  • REDEMPTIONPERIOD
  • PENDINGRESTORE
  • PENDINGDELETE

Registry Fees for ConsoliDate Service

The registry fee for the ConsoliDate service is set forth in Appendix G to the Registry Agreement.


Appendix G to .com and .net Registry Agreements

The text below would be added to Appendix G of the .com and .net Registry Agreements.


Registry Operator Maximum Price Schedule

[Existing text (concerning initial and renewal registrations and transfers) would remain unchanged, to be followed by this additional text:]

4. Fee for Restoring Deleted Domain-Name Registrations

Registry Operator may charge registrars the following maximum prices for each Registered Name that is restored pursuant to the Redemption Grace Period Policy set forth in Appendix C to the Registry Agreement:

Until the end of the second calendar month after the calendar month in which the cumulative total of Registered Names (for all TLDs as to which Registry Operator operates the registry) restored pursuant to the Redemption Grace Period Policy reaches 2000 US$ 85.00
Thereafter US$ 40.00

Registry Operator will waive the fee for restoring any Registered Name that was deleted as the result of a mistake of the Registry Operator.

Note: this "Restore Fee" fee for restoring deleted names is separate from, and in addition to, any Renewal Fees that may be charged pursuant to Section 2 of this appendix.

5. Fee for ConsoliDate Service

Registry Operator may charge registrars the following maximum prices for each Registered Name expiration date extension under the ConsoliDate service as follows:

Fixed service fee per registration that undergoes extension of its expiration under ConsoliDate US$ 2.00
Variable fee per calendar month of extension US$ 1.00

Note: the ConsoliDate service fee is separate from any charges for ordinary registration term extensions made through the "RENEW" command.

There is a one-month minimum charge for any service order, including a request to move an anniversary date to a day later within the current expiration month. The registry will not charge the registrar for days moved within the new calendar month of expiration.

The following is an example of how the maximum prices apply based on a registrant with five domain name registrations, as listed in the chart below:

Registration Current Expiration Date Desired Anniversary Date New Expiration Date Calendar Months Moved Days Moved Within Month Maximum Fee
Domain A 1-Mar-03 15-Sep 15-Sep-03 6 14 US$ 8.00
Domain B 25-Jun-05 15-Sep 15-Sep-05 3 -10 US$ 5.00
Domain C 15-Sep-03 15-Sep 15-Sep-03 0 0 0
Domain D 10-Sep-04 15-Sep 15-Sep-04 0 5 US$ 3.00
Domain E 5-Oct-03 15-Sep 15-Sep-04 11 10 US$ 13.00

The registrant in the example above wishes to synchronize all five registrations under the anniversary date of DOMAIN C. In this example, the registrant requests a move of anniversary date for DOMAINS A, B, D, and E to September 15. Following the fulfillment of the service order, the five anniversary dates are synchronized to September 15. The service will be billed based on a move for DOMAIN A of 6 calendar months and for DOMAIN B of 3 calendar months. DOMAIN D will be billed for a move of one calendar month, which is the minimum charge for a change to anniversary date. DOMAIN E will be billed for a move of 11 calendar months, because the date cannot by moved backwards to synchronize. For registrations moved at least one calendar month, no additional charge is added for the move of days forward within September. Likewise, the charge is not prorated based on a move of days backwards within the month, as with DOMAIN B. (Note: the above dates are used for illustration purposes only; a registrant can select any desired date – including or other than the current anniversary date of an existing registration.)


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 02-Jun-2003
©2003 The Internet Corporation for Assigned Names and Numbers. All rights reserved.