Skip to main content
Resources

Message from Louis Touton to GNSO Council Regarding Deletes Task Force Report

Subject: [council] Concerns Regarding Report of Deletes Task Force
Date: Fri, 11 Apr 2003
From: Louis Touton
To: GNSO Council

To the GNSO Council:

The agenda for the Council's next meeting (17 April 2003) includes the following item:

"6. Vote to approve the Deletes Task Force recommendations and report for submission to the ICANN Board."

Because the Deletes Task Force commenced work before the GNSO PDP came into effect on 15 December 2002, a Staff Manager has not been assigned and the Task Force has not otherwise had significant staff involvement/support to date. As part of the overall process of transitioning to the PDP, Dan Halloran and I have just reviewed the Deletes Task Force's Final Report, as posted at <http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report.html>.

Based on that review, we have concerns regarding some aspects of the report. The purpose of this message is to alert the GNSO Council to the staff's concerns with the recommendations as currently framed.

Concern A: The Proposed Mandatory Deletion Policy Does Not Allow for Extenuating Circumstances

In its current form, the report makes two recommendations that require registrars to delete domain-name registrations within 45 days after they expire. These recommendations appear to apply absolutely, not allowing exceptions for various extenuating circumstances under which deleting registrations by that deadline could harm innocent registrants or result in loss of DNS nameservice for other domains.

The recommendations are 3.1.1 and 3.1.2:

"3.1.1 Domain names must be deleted if a paid renewal has not been received by the registrar from the registrant or someone acting on the registrant's behalf by the end of the Auto-renew Grace Period (generally forty-five days after the domain's initial expiration). As a mechanism for enforcing this requirement, registries may elect to delete names for which an explicit renew command has not been received prior to the expiration of the grace period."

"3.1.2 Domain names must be deleted within 45 days of the expiration of the registration agreement between the registrar and registrant, unless the agreement is renewed."

It appears that a registrar has no ability to delay deletions past 45 days in extenuating circumstances. Here are a few hypothetical situations intended to highlight the serious problems such an unqualified rule could cause:

Hypothetical #1: Shortly before the 45-day deadline, the registrar discovers that its contact data for the registrant has been altered due to hacking or some other incident in the registrar's systems. The registrar concludes that, as a result of the alteration, a renewal notice was never sent to the proper address for the registrant, so that the registrant has never paid a renewal fee and has never entered into a renewed registration agreement. Nonetheless, the registrar is required by 3.1.1 and 3.1.2 to delete the registration, resulting in DNS service to the registrant being shut off. The service can only be restored, after some delay, through restoration under the redemption grace period.

Hypothetical #2: The registrant's main office is located in a building that has suffered a disaster due to flood/fire/earthquake/war/terrorism/etc. The renewal notice was sent to that address, but it appears doubtful that the registrant would have been able to complete the renewal process by the deadline. Nonetheless, the registrar is required by 3.1.1 and 3.1.2 to delete the registration, resulting in DNS service being shut off.

Hypothetical #3: A registration is the subject of court proceedings over who is the proper domain-name holder. The court issues an order requiring that the registrar "freeze" the domain registration, to prevent any changes. The registrant does not pay the renewal fee, putting the registrar in the position of either violating the court order or breaching 3.1.1 and 3.1.2 (and therefore its accreditation agreement with ICANN).

Hypothetical #4: A registrar has submitted a "registrar certificate" to a court concerning a domain name that is currently involved in court proceedings. In the registrar certificate, the registrar has submitted the registration to the court's jurisdiction and has promised not to modify, transfer, or delete the registration during the court proceedings. No renewal takes place within 45 days after expiration, so that 3.1.1 and 3.1.2 require the registrar to act contrary to the registrar certificate.

Hypothetical #5: A domain name registered through a registrar is used to support the host names of nameservers that provide secondary nameservice for 20,000 domains held by other customers, which are registered through many different registrars. The registration is not renewed. As a result, nameservice for the 20,000 other domains must be migrated to other hosts. This is not accomplished in 45 days, and as a result 20,000 domains disappear from the Internet.

Hypothetical #6: Shortly after the expiration date of a registration, the registrar is informed that the registrant has filed for bankruptcy. The registrar's legal advisors have cautioned the registrar to refrain from terminating services to the bankrupt registrant without court permission. Recommendations 3.1.1 and 3.1.2, however, require the registrar to delete the registration.

Hypothetical #7: During the 45-day period after expiration, the registrant asserts that it has made a renewal payment to the registrar but the registrar has been unable to complete its investigation into the payment dispute before the 45-day deadline. The registrar is uncertain whether it must delete the registration in order to comply with 3.1.1 and 3.1.2.

Hypothetical #8: The registrar has a long-standing relationship with a registrant; the registrar knows that one of the registrant's domain registrations that has expired is for an important and heavily used name, and suspects that the registrants' failure to renew was caused by an oversight. The registrar is unable to resolve the issue with the registrant within the 45-day period. As a result, recommendations 3.1.1 and 3.1.2 require the registrar to delete the registration, shutting off nameservice for the domain.

Based on a plain reading of the recommendations of 3.1.1 and 3.1.2, in many if not all of these hypothetical cases the registrar would apparently be required to delete names, even though contrary to technical prudence or even other legal requirements. While it may make sense to prescribe a uniform time frame for registrar deletion of expired names, the hypothetical situations described above point to the difficulty of making hard and fast rules without allowing for exceptions in extenuating circumstances.

Concern B: The Recommendations Concerning Mandatory Disclosures Inappropriately Restrict Certain Registrar Business Models

Recommendations 3.1.4 and 3.1.6 seem to prevent registrars from adapting and evolving their service offerings over time since they mandate that policies and prices be provided "at the time of registration", even though the policies and prices may not come into effect until after the registration expires (and after the registrant has the opportunity to transfer to another registrar). These provisions state:

"3.1.4 Registrars must provide a summary of their deletion policy, as well as an indication of any auto-renewal policy that they may have, at the time of registration. This policy should include the expected time at which a non-renewed domain name would be deleted relative to the domain's expiration date, or a date range not to exceed ten days in length."

"3.1.6 Registrars should provide, both at the time of registration and in a conspicuous place on their website, the fee charged for the
recovery of a domain name during the Redemption Grace Period."

It is not clear whether registrars would be able to modify their procedures or prices at any time after initial registration of a domain name.

Also, recommendations 3.1.5 and 3.1.6 seem to obligate all registrars to operate websites. In some business models currently available to registrars, including reseller models and models used in some regions of the world, registrars do not operate principally through websites, but use other means to communicate with prospective and actual customers. There is no current requirement that registrars operate websites, other than for a web-based Whois service. These recommendations appear unnecessarily to restrict these alternative registrar business models.

Concern C: Mandatory "Payment" Policies Could Stifle Registrar Business Models

Recommendation 3.1.1 (and possibly recommendation 3.1.6) appears to require that registrars charge all customers for registration and RGP services. Some registrars operate business models under which some or all registrants are not charged specifically for registration services. In accord with ICANN's mission, Registrar Accreditation Agreement §3.7.10 specifically precludes any policy that regulates registrar prices: "Nothing in this Agreement prescribes or limits the amount Registrar may charge Registered Name Holders for registration of Registered Names." By requiring that renewals be paid, recommendation 3.1.1 contradicts this principle. Implementation of a requirement that a fee be charged for renewals would also raise serious concerns under relevant antitrust and competition laws.

Concern D: Overlap with Whois Recommendations

On 27 March 2003, the ICANN Board adopted four consensus-policy recommendations relating to Whois accuracy and bulk access. One of those recommendations states:

"B. When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period – once implemented – should be applied. However, the redeemed domain name should be placed in registrar hold status until the registrant has provided updated WHOIS information to the registrar-of-record."

This recommendation is currently early in the implementation process.

The Final Report of the Deletes Task Force contains this recommendation on the same topic, but proposing a somewhat different policy:

"3.3.1 The Redemption Grace Period will apply to names deleted due to a complaint on WHOIS accuracy. However, prior to allowing the redemption in such a case, the registrar must update the registration with verified WHOIS data and provide a statement indicating that the data has been verified in conjunction with the request for the name's redemption. The same rules that apply to verification of WHOIS data for regular domain names following a complaint will apply to deleted names."

By proposing overlapping policies so soon after one another, the GNSO would significantly complicate the task of implementing the policies.

Thank you for your attention. Please feel free to contact me if you have any questions.

Best regards,

Louis Touton
General Counsel

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."