ICANN/DNSO
DNSO Mailling lists archives

[nc-whois]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-whois] Deletes issue Paper for comment

  • To: "Transfer TF (E-mail)" <nc-transfer@dnso.org>
  • Subject: [nc-whois] Deletes issue Paper for comment
  • From: "Cade,Marilyn S - LGA" <mcade@att.com>
  • Date: Tue, 24 Sep 2002 00:26:25 -0400
  • Cc: "NC-WHOIS (E-mail)" <nc-whois@dnso.org>
  • Sender: owner-nc-whois@dnso.org
  • Thread-Index: AcJf1M4k/ra0pTPxTDGYR9GJFd4YgADrTd8w
  • Thread-Topic: [announce] Deletes issue Paper for comment

For your information and any comments you might have. 

For the Transfer TF:  I believe that the present suggestion will be to set up a new TF, with some kind of liaison back to the Transfer TF, or even some degree of overlapping membership, if a constituency chose to nominate the same person. I'll keep you informed, but suggest that you also discuss with your NC representatives regarding your views. 

Since WHOIS accuracy is referenced, I've posted this to the WHOIS TF, as a cc.

 

-----Original Message-----
From: DNSO Secretariat [mailto:DNSO.secretariat@dnso.org]
Sent: Thursday, September 19, 2002 6:26 AM
To: announce@dnso.org
Subject: [announce] Deletes issue Paper for comment



[To: ga@dnso.org; liaison7c@dnso.org]
[To: announce@dnso.org]

The attached issue paper has been prepared by a small team comprising:

Bruce Tonkin
Alexander Svensson
Ross Wm. Rader
Ram Mohan
Jordyn A. Buchanan
Liu, Hong

The intent of this paper is to stimulate discussion within the DNSO
constituencies, and will be used as a basis for the Names Council to
determine whether to initiate a policy development process for this issue.
The Names Council will discuss and vote on this issue during the
teleconference of 3 October 2002.   Please forward this paper to the
relevant constituency and GA mailing lists.

Regards,
Bruce Tonkin


DELETES ISSUE PAPER

Recent policy development activity in relation to studying transfers in
the transfers task force, providing advice on the Verisign Wait List
Service proposal, and in considering the redemption grace period
proposal has highlighted a range of issues associated with current
delete processes within the gtlds.

Issue 1: Uniform delete practice after domain name expiry by registrars
========================================================================

The ICANN Registrar Accreditation agreement
(http://www.icann.org/registrars/ra-agreement-17may01.htm) contains the
following clause:

"3.7.5 Registrar shall register Registered Names to Registered Name
Holders only for fixed periods. At the conclusion of the registration
period, failure by or on behalf of the Registered Name Holder to pay a
renewal fee within the time specified in a second notice or reminder
shall, in the absence of extenuating circumstances, result in
cancellation of the registration. In the event that ICANN adopts a
specification or policy concerning procedures for handling expiration of
registrations, Registrar shall abide by that specification or policy."

The above clause leaves open a deadline for deleting a name (and hence
making it available for registration by others) after a domain name is
not renewed.

For the com/net/org registry, the registry operator auto-renews domain
names at the expiry date of a domain.  There is then a 45 day grace
period following the expiry date, when a registrar may delete a name,
and be credited for the renewal fee.  Most registrars tend to explicitly
delete names before the end of the 45 day period, although some do not,
and often names are retained within the registry for an indeterminate
period of time for various reasons.  Sometimes names are withheld from
the market for periods beyond a few months.

Lack of consistent practice in this area may, amongst other things,
cause substantial potential confusion among registrants.

From
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm
#3

"2.3 Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days
following an auto-renewal. An auto-renewal occurs if a domain name
registration is not renewed by the expiration date; in this circumstance
the registration will be automatically renewed by the system the first
day after the expiration date. The current value of the Auto-Renew Grace
Period is 45 calendar days."

The .biz and .info agreements have similar provisions.

In contrast the .name agreement
(http://www.icann.org/tlds/agreements/name/registry-agmt-appc-5-02jul01.htm)
states:

"The .name Registry Operator does not support an Auto-Renew Grace
Period. Upon the expiration of the term of a domain name registration or
SLD E-mail address registration, the registration is cancelled unless
its term has been explicitly extended by the sponsoring registrar."

Some registrars choose to undelegate a domain name (ie remove it from
the zonefile) so that a registrants email and web services may be
suspended. This often assists in contacting a registrant that has failed
to renew a domain name.  Other registrars may delete the name without
further warning if the name is not renewed.

Some registrars choose not to delete a name even if it has not been
renewed, if there is a dispute (for example UDRP) process underway.
There may be other circumstances where a registrar may not want to
delete the domain name after expiry, even though the renewal has not
been paid.

The end result of the above situation is consumers do not have a
consistent environment for the process of deleting a name.  This applies
to consumers that have a domain name that is expired (they have no idea
how long they have to attempt to renew the name before it is deleted),
and those consumers that desire an existing domain name that is no
longer in use (they have no idea when the name may become available).

Lack of consistent practice in these areas may, amongst other things,
cause substantial confusion among registrants.

A possible policy action is to consider a uniform delete process amongst
gtld registries and registrars.


Issue 2: Deletion following a complaint on WHOIS accuracy
=========================================================

The ICANN Registrars Accreditation agreement
(http://www.icann.org/registrars/ra-agreement-17may01.htm) requires
registrars to maintain the accuracy of WHOIS information, and to require
a registrant to update inaccurate information.  Note clause 3.7.7.2
states:

"3.7.7.2 A Registered Name Holder's willful provision of inaccurate or
unreliable information, its willful failure promptly to update
information provided to Registrar, or its failure to respond for over
fifteen calendar days to inquiries by Registrar concerning the accuracy
of contact details associated with the Registered Name Holder's
registration shall constitute a material breach of the Registered Name
Holder-registrar contract and be a basis for cancellation of the
Registered Name registration."

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.  The introduction of the
proposed Wait List Service may make this a more attractive option.

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.

A possible policy action is to review steps that should be taken by a
registrar to contact a registrant that has not maintained accurate
contact information, which may include a period where the name is first
undelegated before it is deleted, and may include a delete period that
corresponds to grace periods allowed in issue (1) above.


Issue 3 - Registry delete process
=================================

After a registrar issues a delete command to a registry, registry
operators have various methods for actually deleting a name.
Registrants have also developed various approaches for predicting when
the name 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.

Some registrars 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. In addition, some registries would like to see a
standard method for the addition of names, such as a round-robin queue
system, to help alleviate problems from add storms, and to provide an
equitable manner of domain name reallocation.  This may result in a fairer
market for obtaining these names, and may ensure that the "add" storm is
confined to a small
segment of time.

A possible policy action is to determine a uniform process for a
registry to delete and reallocate names that ensures that the market is
equally
informed of the names about to be available, and schedule for when the
names are available.


Issue 4 - Reversal of renewal transactions
==========================================

With reference to the Renew/Extend grace period of the .com Registry
agreement:
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm
(similar wording is in the .biz, .info and .name agreements)

If an error is made during a renew operation, the operation can only be
reversed and the registrar provided with a credit for the renewal, by
deleting the domain name registration.

Given that mistakes can happen, it may be prudent to create a facility that
would allow for renewal commands to be reversed (within a specific time
period after the
initial transaction perhaps) that wouldn't require the deletion and
corrective re-registration of the domain name.

Lack of consistent practice in this area may, amongst other things,
cause a registrant to inadvertently lose their domain name registration.







<<< Chronological Index >>>    <<< Thread Index >>>