General Counsel's Briefing Regarding Proposed
Revisions to .com and .net Registry Agreements to Reflect Services Introduced
25 January 2003
General Counsel's Analysis of VeriSign Global Registry Services' Request for Amendment to Registry Agreement
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:
The purpose of the agenda topic is to authorize updating the .com and .net registry agreements to reflect these changes.
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:
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:
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.
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.
I recommend that the Board authorize revision of the .com and .net registry agreements to reflect this service.
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:
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.
The text below would be added as a new part 7 of Appendix C of the .com and .net Registry Agreements.
* * *
7. Additional Services Descriptions
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:
Detailed Implementation Command
The implementation of the Redemption Service involves one command:
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:
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.
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.
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:
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:"
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 Fees for ConsoliDate Service
The registry fee for the ConsoliDate service is set forth in Appendix G to the Registry Agreement.
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:
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:
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:
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 email@example.com.