[nc-deletes] Next Call Details

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

Next call details:

1) Time:  14:00 UTC (09:00 Eastern Coast USA; 06:00 West Coast; 23:00 Tokyo)

2) Date:  Friday, December 6, 2002

3) Phone Number:   +1.716.566.6015.  Access Code:  771508

Once again, I'll conference in Dr. Lisse if he can provide me with a number
to reach him at in advance.

On 12/5/02 11:37 AM, "Evelyn Remaley" <Evelyn.Remaley@wcom.com> wrote:

> 
> Hello, Jordyn - Since I will be stepping in for Maggie on the call on
> Friday, would you mind sending me the call-in information?
> Thanks much,
> Evelyn
> 
> Evelyn Remaley
> Internet Law & Policy Group
> WorldCom, Inc.
> 202.736.6454 (voice)
> evelyn.remaley@wcom.com (email)
> 
> -----Original Message-----
> From: Maggie Mansourkia [mailto:Maggie.Mansourkia@wcom.com]
> Sent: Thursday, December 05, 2002 2:36 AM
> To: 'Jordyn A. Buchanan'
> Cc: Tony Holmes (E-mail); Evelyn L Remaley (E-mail)
> Subject: RE: [nc-deletes] Draft recommendations
> 
> 
> Jordyn-
> I will be having a baby within the next several hours and will be on
> maternity leave for a while.  Please add Evelyn Remaley to the task force
> distro.  In light of the baby coming sooner than expected, I suppose I will
> not be able to make the call on Friday afterall, but Evelyn will cover it
> for our constituency.  After Friday, Tony Holmes may choose to appoint
> another person on behalf of our constituency.
> Good luck and happy holidays,
> Maggie
> 
> Magnolia Mansourkia
> Policy Counsel
> Internet Law and Policy Group
> WorldCom, Inc.
> 202-736-6448 (voice)
> 222-6448 (VNet)
> 800-455-3903 (pager)
> 
> -----Original Message-----
> From: owner-nc-deletes@dnso.org [mailto:owner-nc-deletes@dnso.org]On
> Behalf Of Jordyn A. Buchanan
> Sent: Wednesday, December 04, 2002 5:51 PM
> To: nc-deletes@dnso.org
> Subject: [nc-deletes] Draft recommendations
> 
> 
> I suppose in the spirit of some of the other task forces out there, we ought
> to have a whole lot more text, and indeed we'll probably add some.  The
> following text constitutes, essentially, a first draft at the
> recommendations section of the report.  I may get a chance to add some of
> the other stuff tomorrow.
> 
> I think I've highlighted the areas of general agreement, and in brackets
> you'll find placeholders for the issues in which there is still some
> remaining discussion to be had.  I'm certainly open to feedback,
> wordsmithing, etc. on the existing text, as well.
> 
> 
> --
> 
> 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.
> 
> <<<<<Under discussion:  whether or not registrars should be required to not
> delete a name for a portion of the grace period.>>>>>
> 
> 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 the following:
> 
> <<<<<Insert finalized UDRP policy here.>>>>>
> 
> 
> 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.
> 
> <<<<<I'm holding off on re-allocation until we have some more
> discussion.>>>>>
> 
> 
> 
> 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.
>