[nc-deletes] Draft report

["Jordyn A. Buchanan" <jordyn.buchanan@Registrypro.com>]

Hello all:

Please find attached a draft version of a task force report--the 
recommendations that we've previously agreed upon are not attached, but 
will be in the report we publish.

On tomorrow's call, I'm hoping that we can discuss this report briefly 
to see if there are any areas in which we'd like to supplement the 
report, or make modifications, since this represents a first draft by a 
few task force members plus some edits I've imposed onto the text.

Also, on tomorrow's call, I'm hoping we can get close to consensus on 
the final two points that we've not agreed to in terms of 
recommendations:

1) Whether registrars should be required to not delete names during 
some portion of the renewal grace period.
2) What recommendations we should make with regards to reallocation.

Jordyn

deletes draft report.txt

ISSUE #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 the
hundreds 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
registry renewal plays an important role in protecting domain name
registrants from accidental lapses in service. 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
which 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. (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.


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.  This
new data should be provided as part of the documentation to the registry
in conjunction with the request for the name's redemption.


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.

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.