RE: [nc-deletes] Draft report
Jordyn,
Excellent draft. I
have only a few comments/suggestions.
ISSUE #1, first
paragraph, delete the third sentence. The same thing can be accomplished by
provided a grace period during which the name is not auto-renewed but is not
immediately deleted unless an explicit delete command is issued by the
sponsoring registrar. In fact, this is currently being considered by
VeriSign.
ISSUE #1, second
paragraph, we may want to provide something concrete from registrars or
registries to back up the statistic in the last sentence.
ISSUE #1, last
paragraph, I recommend that we add "before the end of the grace period" for
clarification.
ISSUE #2, last
paragraph, I recommend that we either define the documentation or request an
extension to address it. However, I have been involved on the WHOIS TF Report
Implementation Committee and it appears that there is a move toward defining
this in that report. We should discuss that.
ISSUE #3, fourth
paragraph, it should be noted that VeriSign's approval for WLS included a
provision that they cannot implement WLS no sooner than six months following the
implementation of the Redemption Grace Period. So we may want to reword this so
it doesn't sound as though VeriSign is procrastinating on the WLS. It might also
be interesting, but not necessary, to speak with VeriSign about it and determine
if they are still determined to move forward with the WLS. Or that might be best
kept for the further analysis we are recommending on this
issue.
Tim
------------------------------------------------------------
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.
|