Re: [council] Deletes Task Force draft recommendations

["J. Scott Evans" <jse@adamspat.com>]

Dear All:

A client emergency has arisen on my end.  For this reason, I have a client
meeting beginning at 9 AM EST today.  I may be able to pull away from the
meeting attend the second hour of the conference call.

My apologies to everyone.  In my absence I pass my proxy first to Ellen and
then to Laurence.

J. Scott
----- Original Message ----- 
From: "Jordyn A. Buchanan" <jordyn.buchanan@Registrypro.com>
To: <council@dnso.org>
Sent: Wednesday, January 15, 2003 8:50 PM
Subject: [council] Deletes Task Force draft recommendations


> Hello all:
>
> Prior to our call tomorrow, I wanted to share the draft recommendations
> from the Deletes Task Force in their current form.  These should
> already have been circulated to the various constituencies by their
> task force reps, but I wanted to make sure everyone has a chance to
> review them in conjunction with tomorrow's discussion.
>
> Please keep in mind that these are draft recommendations and may still
> be subject to some refinement.  In the initial task force report, which
> I hope to have released soon, there will be considerably more
> explanatory text surrounding the recommendations.
>
> I look forward to speaking with all of you tomorrow.
>
> Jordyn
>
> ---
> Issue 1: As indicated in the issues paper, the status quo presents an
> environment in which users may not always understand the deletion
> process applied to their domain name.  While recognizing the need for
> registrars to pursue their own business models, the task force
> recommends that certain baseline policies be adopted by all registrars.
>   Specifically:
>
> 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.
>
> 2.  Registrars should 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.  Registrars should provide their deletion and auto-renewal policies
> in a conspicuous place on their websites.
>
> A special case exists for names that expire during the course of a UDRP
> dispute.  In order to prevent the name from lapsing and being
> re-allocated during the dispute, the task force proposes that the
> challenger in the UDRP dispute be provided with the option of paying
> for the renewal of the domain name in the event that the current
> registrant elects not to renew the domain name.  This policy does not
> give the challenger in the dispute any special rights, nor does it The
> policy is described in more detail as follows (it's a bit complicated
> right now; we're working on paring it down while still covering the
> edge cases):
>
> 1. In the event that a domain under UDRP dispute is likely to expire
> during the course of the dispute, the dispute resolution provider will
> notify the challenger 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.
>
> 2. In such an event, the challenger will have the option to pay for a
> one year renewal at the sponsoring registrar's current prevailing rate
> for renewals.
>
> 3. The original registrant will have the option of paying for the
> domain name at any time up to the relevant registry's renewal grace
> period PLUS thirty days (which matches the redemption grace period),
> regardless of whether or not the challenger has paid for the domain's
> renewal.
>
> 3a. In the event that both the registrant and the challenger 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 fee
> paid by the challenger will be refunded.  The order in which the
> payments are received shall not effect this provision.
>
> 4. In the event that only the challenger pays for the renewal of the
> domain name, beginning no later than the duration of the relevant
> registry's renewal grace period after the domain's expiration, the
> registar will:
>
> 4a. Place the name on REGISTRAR HOLD and REGISTRAR LOCK, with the
> result that the name will no longer resolve in the DNS.
>
> 4b. 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.
>
> 4c. If the challenge is terminated prior to a verdict being rendered,
> but after the domain reaches this state, the domain will be deleted.
>
> 5. In the event that the verdict of the UDRP challenge is that the
> domain is to be transferred to the challenger, the registrar shall
> transfer the name in accordance with its regular process for such
> situations.
>
> 6. Notwithstanding #3 above, if the verdict of the UDRP challenge is
> that the domain is to be deleted, the registrar shall delete the name
> in accordance with the usual UDRP process.
>
> 7. In the event that the verdict of the UDRP challenge is that the
> existing
> registration be sustained, AND the relevant registry's renewal grace
> period
> has expired without the original registrant paying for a renewal, the
> domain name will be deleted.
>
> 7a. In the event that the verdict of the UDRP challenge is that the
> existing
> registration be sustained, and the renewal grace period has not
> expired, the
> domain name will be subject to the registrar's usual renewal and
> deletion
> processes.
>
> 8. Provisions #6, #7 and #7a apply regardless of any payment for
> renewal by the challenger.  With the exception of provision #3a above,
> the challenger will not receive a refund for any renewal fees paid to
> the registrar.
>
>
> Issue 2: Many of the problems raised within the issues paper are
> 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: 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 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.
>
>
> Issue 4: 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.
>
>