<<<
Chronological Index
>>> <<<
Thread Index
>>>
[registrars] Deletes TF Draft Report
The following is the current draft of the Deletes Task Force Report. Please
take some time to review the recommendations and reply with your comments
and concerns.
For reference, the initial RC statement (not a formal position) on these
issues can be found at:
http://www.dnso.org/clubpublic/nc-deletes/Arc00/msg00063.html
Thanks,
Tim
-----Original Message-----
From: owner-nc-deletes@dnso.org [mailto:owner-nc-deletes@dnso.org]On
Behalf Of Bret Fausett
Sent: Tuesday, January 28, 2003 9:04 AM
To: nc-deletes@dnso.org
Subject: Re: [nc-deletes] Revised report (ASCII)
1. INTRODUCTION
There is perhaps no time more critical in the ³life cycle² of a domain name
more critical than its deletion. This moment is fraught with danger for the
existing registrant who has come to use and depend on the domain, full of
opportunity for prospective new registrants interested in the name,
potentially costly for registrars facing the expiration of various grace
periods, and technically challenging for registries facing a surge of
interest in popular names.
1.1 Previous Discussion
Issues related to the deletion of domain names have already been discussed
several times within the ICANN community. Beginning in June of 2001, the
deletion and subsequent reallocation of domain names within VeriSign¹s
com/net/org registry resulted in ³add storms² that significantly impacted
the performance of the registry, and resulted in connection limits on
registrars as well as the separation of certain automated registration
requests into a separate pool of connections. Subsequently, VeriSign
propsed a new ³Waiting List Service² (WLS) for the reallocation of deleted
names, first to the Registrars Constituency in December, 2001, then to ICANN
in March, the WLS was evaluated by the Transfers Task Force in July, 2002,
and then approved by the ICANN board in August, 2002.
In parallel to the discussion of the WLS, in February, 2002, ICANN proposed
the creation of a ³Redemption Grace Period², to allow registrants to reclaim
domain names deleted in error for up to thirty days after deletion. The
concept was endorsed by the ICANN board in March, 2002, and further explored
by a technical steering group, which posted its report in June, 2002. The
ICANN board approved the Redemption Grace Period in June, 2002, and it was
implemented by VeriSign in the .com and .net registries in January, 2003.
1.2 Genesis of the Deletes Task Force
Following discussion of the WLS by the Transfers Task Force, the Names
Council determined that a number of broader issues related to the subject of
the deletion of domain names existed, and should be explored in greater
depth. In order to identify the relevant issues, the Names Council ordered
the creation of an issues group during its teleconference on September 12,
2002 . The issues group posted its report on September 19, 2002, and
identified four issue areas: (1) uniform delete practice after domain name
expiry by registrars, (2) deletion following a complaint on WHOIS accuracy,
(3) registry delete process, and (4) reversal of renewal transactions.
On October 4, 2002 the Names Council voted unanimously to create a task
force to formulate policy recommendations in the four topic areas identified
by the issues paper, and the terms of reference for the task force was
adopted by the Names Council at its Shanghai meeting on October 29, 2002.
1.3 Terms of Reference
The Deletes Task Force was chartered with the following Terms of Reference:
1. determine whether a uniform delete process by gtld registrars following
expiry is desirable, and if so, recommend an appropriate process
2. determine whether a uniform delete process by gtld registrars following a
failure of a registrant to provide accurate WHOIS information upon request
is desirable, and if so, recommend an appropriate process
3. determine whether a uniform delete and re-allocation process by
registries following receipt of a delete command from a registrar is
desirable, and if so, recommend an appropriate process
4. determine whether a uniform process for reversing errors in renewal
commands without requiring a delete operation is desirable, and if so,
recommend an appropriate process
1.4 Overview of Recommendations
This report provides policy recommendations on the first two topic areas
identified by the issues paper and the task force¹s Terms of Reference.
The task force also believes that further work needs to be pursued on the
subject of a uniform registry reallocation policy, and notes that some
interest has been indicated in the subject of warehousing of domain names by
registrars. With regards to the fourth issue, relating to the reversal of
errors in the renew command, the task force believes that no alternations in
current policy or practice are required at this time.
2. FINDINGS ON EACH ISSUE
2.1 Uniform delete practice after domain name expiry by registrars
Although most domain names are renewed year to year, a significant number of
registrations in the gTLD registries (numbering in thehundreds of thousands,
if not millions, each year) are not renewed by the current registrant and
are eligible for deletion. The reason a non-renewed name has to be
affirmatively ³deleted² (as opposed to lapsing on its own) is that the
registry automatically renews a domain name for another year on the date it
is scheduled to expire (and bills the associated registrar the annual
registry fee). This automatic In current practice, if the registrant has
failed to pay its renewal fee or otherwise indicated that it does not wish
to renew the name, the registrar for that domain name has 45 days after the
automatic renewal in which to send a ³delete² command to the registry asking
to have the domain name deleted. If the ³delete² commend is sent within the
45 day window, the registrar is credited back the annual registry fee from
the gTLD registry.
Given these facts, you would assume that when a registrant fails to renew a
domain name, the registrar would make sure to delete the name within the 45
day window so the company would not be charged the registry fee. While that
happens much of the time, it doesn¹t always happen. In many cases, a
registrar will decline or fail to issue the delete command within the 45-day
window. This results in a domain name that is neither registered to any
individual or company nor registerable by any individual or company through
the majority of the registrars. This is not a rare phenomenon. At various
times over the past year, the number of unregistered domain names held by
registrars has been in the hundreds of thousands.
From the perspective of a registrant, this presents a conundrum. A domain
name that a company wants to register may not be currently registered by
anyone else but, at the same time, it¹s not eligible for a new registration.
The prospective registrant for such a name is left with no information on
how to proceed or even any idea of when the domain name might be deleted
(some domain names have been held by registrars for years). In some
instances, whois information from the original registrant remains in the
whois database, even though that registrant no longer wishes to own the
domain name.
To solve these and other associated problems, the task force recommends that
registrars should be required to delete domain names that a customer has
failed to renew before the end of the renewal grace period. (ICANN¹s new
30-day ³redemption grace period² would apply to all such deletions.)
Additionally, in order to provide registrants with a complete understanding
of registrars' deletion and renewal policies, the task force recommends that
registrars inform registrants of those policies at the time of registration,
and maintains them in a conspicuous place on their website.
2.2 ISSUE #2: Deletion following a complaint on WHOIS accuracy
The current ICANN Registrar Accreditation agreement requires registrars to
maintain the accuracy of WHOIS information, and to require a registrant to
update inaccurate information. Recent pressure on registrars to comply with
the clause above in response to complaints about the accuracy of WHOIS data,
may have the unintended consequence that it could be exploited by those that
want to obtain a domain name from a current registrant.
Given that registrars often have trouble contacting registrants at the time
of domain name renewal due to a registrant not maintaining up-to-date
contact information, the 15 day period may be inadequate and out of
proportion to typical 45 day grace periods available during the renewal
process following expiry.
Much of this problem is already under consideration by the Whois task force.
In order to avoid overlap between the two task forces, the Deletes Task
Force determined that:
1. The scope of the Whois Task Force is to determine under what
circumstances a domain name should be deleted for reasons relating to the
domain's Whois data.
2. The scope of the Deletes Task Force is to determine what happens to a
domain name once it has been deleted for reasons relating to the domains'
Whois data.
In most respects, a name deleted for reasons relating to inaccuracy of Whois
data is treated identically to a name deleted for any other reason.
However, it is important to prevent registrants from using the Redemption
Grace Period to simply re-instate names once they have been deleted, without
providing accurate Whois information. In order to prevent this, the task
force recommends that registrars require that registrants of such names
provide new, verified Whois information. The registrar should then provide
a statement indicating that the data has been verified in conjunction with
the request for the name¹s redemption.
2.3 ISSUE #3: Registry delete process
Currently, when a registrar issues a delete command to a registry, registry
operators have various methods for actually deleting the name. As a result,
registrants have developed various approaches for predicting when deleted
names will actually become available for registration - although this isn't
an exact science. Typically some registrants (or registrars/resellers on
their behalf) scan changes in the zonefile for an early warning that a
domain name is about to be deleted. They then send repeated add commands to
the registry when they believe that the name may become available. Over
time this has led to performance issues for both the registry operator and
registrars, as many commands are executed to try to obtain a deleted name.
This current situation leads to two possible issues to address.
Registrars and internet users have suggested that they would like to see a
uniform process for the actual deletion of a domain name. In this process
they would like to see the registry operator periodically publish a list of
names that are scheduled for deletion, and an exact time or time range when
the deletion will occur.
The task force believes that the recently adopted Redemption Grace Period
not only provides registrants with crucial protection in the event of
inadvertent deletion or misunderstanding of deletion policy, but also
provides significant transparency into the deletion process as lists of
names to be purged from the registry's system are published on a regular
basis. The task force feels that the Redemption Grace Period, along with
the existing Add Grace Period, provides an adequate level of consistency and
transparency in terms of registry deletion policy, and does not recommend
any other specific steps be adopted at this time. A possible implementation
would be as follows:
i. If the domain is within an Add Grace Period when a delete is
issued, then it will be deleted immediately. If the domain is within an Add
Grace Period and a Renew Grace Period (i.e. it is explicitly renewed within
the Add Grace Period), then it will be deleted immediately.
ii. If a domain name is deleted within any other Grace Period, the
registrar will receive an immediate credit and the domain name will be
immediately placed in the Redemption Grace Period.
iii. If the domain is deleted outside of any Grace Period, a successful
delete request should always place the domain name in the Redemption Grace
Period.
iv. Registries must implement the Redemption Grace Period as defined in
the Technical Steering Group's proposal of June 7, 2002 found at:
http://www.icann.org/bucharest/redemption-topic.htm
Once names are deleted, the process by which they are re-allocated is
currently resource-intensive and may seem to be inequitable. VeriSign, the
only gTLD registry currently processing a significant number of deletions
and subsequent re-registration of domain names, proposed a "Waiting List
Service" in March, 2002, in which potential registrants would be offered the
opportunity to subscribe to a waiting list for a particular domain name. In
the event that the name were deleted while the waiting list subscription
remained active, the domain would not simply return to the pool of available
names, but would be automatically registered by the waiting list subscriber.
Although this service was given provisional approval by the ICANN board in
August, 2002, it has still not been implemented by VeriSign. There may also
be alternative approaches to the reallocation process that are fairer, less
resource-intensive, or both, than the current reallocation mechanism.
Unfortunately, these alternatives are not necessarily well defined and there
is very little real-world experience with any reallocation mechanism, so the
task force has been unable to make specific evaluations or recommendations
to date.
The task force believes that there is significant interest in further study
of uniform reallocation of deleted names. However, the task force does not
believe that this issue can be satisfactorily resolved within the time frame
of our original charter. The task force requests that upon acceptance of its
initial report, the Names Council recharters the task force to perform a
more extensive analysis of this particular issue.
2.4 ISSUE #4: Reversal of renewal transactions
In order to correct errors in billable transactions, the various registries
provide certain grace periods in which these transactions can be reversed
and the cost of the transaction credited back to the registrar. For
example, registries generally provide registrars with a 5 day "add grace
period" in which a name registered in error can be deleted, causing a full
credit for the domain's registration to be provided to the registrar.
Unfortunately, the situation is somewhat more complicated in the area of
renew transactions. Because both the RRP and EPP protocols lack an "undo"
function, a registrar that performs an accidental renew command has no way
to directly reverse the transaction. The domain name can be deleted,
resulting in a credit for the renewal, but for domains that must remain
active, this is not an acceptable solution.
The task force has found that this issue is primarily technical in nature.
Although both the RRP and EPP protocols lack an "undo" function that would
allow for the direct reversal of a renewal without deleting these domains,
registries generally have administrative procedures in place that allow for
such transactions to be reversed out-of-band. As a result, the task force
sees no need to take action on this issue.
In the event that registries or registrars desire this capability to be
added to the EPP protocol, the task force believes that these changes are
best pursued through technical fora such as the IETF.
3. RECOMMENDATIONS
As indicated above, specific policy recommendations are limited to two of
the four issues identified within the original Issues Paper: Issue #1
(Uniform delete practice after domain name expiry by registrars) and Issue
#2 (Deletion following a complaint on WHOIS accuracy). Recommendations
related to Issue #1 have been separated into two sections; the first
pertains to uniform deletion practices for all domain names, while the
second outlines policy recommendations specific to names subject to a
pending UDRP dispute.
3.1 Uniform deletion practice after domain name expiry by registrars
3.1.1 Domain names must be deleted if a paid renewal has not been
processed 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 registry, unless the
agreement is renewed.
3.1.3 These requirements retroactively apply to all existing domain name
registrations beginning 180 days after the adoption of the policy.
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.
3.1.5 Registrars must provide their deletion and auto-renewal policies
in a conspicuous place on their websites.
3.2 Registrar deletion practice after domain name expiry for domain names
subject to a pending UDRP dispute
3.2.1 In the event that a domain the subject of a UDRP dispute is likely
to expire during the course of the dispute, the dispute resolution provider
will notify the complainant of the impending expiration either at the time
the dispute is filed, or no later than 30 days prior to the expiration of
the domain.
3.2.2 In such an event, the complainant will have the option to pay for
a one year renewal at the sponsoring registrar's current prevailing rate for
renewals.
3.2.3 In the event that the complainant paid the renewal fee prior to
the domain name¹s expiration, the original registrant will have up to thirty
days after the end of the relevant registry¹s renewal grace period in which
to pay for the renewal of the domain name.
3.2.4 In the event that both the registrant and the complainant pay for
the renewal, the name will be renewed on behalf of the original registrant
in accordance with the registrar's usual policy, and any renewal fee paid by
the complainant will be refunded. The order in which the payments are
received shall not effect this provision.
3.2.5 In the event that only the complainant pays for the renewal of
the domain name, the registrar will:
3.2.5.1 Place the name on REGISTRAR HOLD and REGISTRAR LOCK, with the
result that the name will no longer resolve in the DNS.
3.2.5.2 Modify the Whois entry for the domain name to indicate that the name
is the subject to a UDRP dispute, and to remove all specific ownership
information for the Whois record.
3.2.5.3 If the complaint is terminated prior to a verdict being rendered,
but after the domain reaches this state, the domain name will be deleted.
3.2.6 Where only the complainant paid the renewal fee for a domain name
the subject of a UDRP action and the complainant¹s UDRP case fails, if the
relevant registry¹s normal renewal grace period has expired, the domain name
will be deleted.
3.2.7 In all other cases, the registrar shall comply with the outcome of
the UDRP dispute in accordance with its regular policies. No provision of
this policy should be taken to override the decision in the UDRP dispute.
3.3 Deletion following a complaint on WHOIS accuracy
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.
4. OTHER ISSUES
4.1 Domain name warehousing
In the task force¹s discussion of registrars¹ deletion practices, the
subject of warehousing of domain names by registrars was raised. Three
specific modes of warehousing were identified:
(1) The registrant allows the domain name to lapse, but registrar fails to
delete the domain name during the grace period, resulting in a paid renewal
to the registry. The registrar subsequently assumes ownership of the domain
name.
(2) The registrant purchases the domain name through fraud and the
registrar assumes ownership of the name to resell in order to minimize
losses.
(3) The registrar purchases the domain in its own name outright.
The task force believes that its current set of recommendations deals with
the first scenario described above. The other scenarios are not clearly
subject to the task force¹s terms of reference, and have not been fully
explored by this group, nor have any policy recommendations been made in
their regard. The Names Council may wish to explore these issues
separately, or recharter this task force to explore one or both of these
scenarios.
5. IMPACT OF RECOMMENDATIONS
Registrars
Registries
Registrants
UDRP Providers
6. OUTREACH EFFORTS
A number of outreach efforts have been performed to date:
· All task force activities have been documented on the public mailing
list maintained at http://www.dnso.org/clubpublic/nc-deletes/Arc00/
· Task force members have circulated draft recommendations to their
various constituencies.
· The draft recommendations and status of the task force¹s work has been
communicated to the Names Council.
Additional outreach efforts will begin with the publication on this report.
The task force will welcome public comments, which will be considered prior
to the publication of a final report. Constituencies will also be
encouraged to submit formal comments to the task force during this time.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|