<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [nc-deletes] Next Call Details
Jordyn,
call me on my cell phone again first, 00264 81 124 6733 so I can tell
you where I will be at the time.
It'll be 16h00 here (ie working hours) and those babies they just
don't want to stay in :-)-O
el
--
Dr. Eberhard W. Lisse \ * / Managing Member, NA-NiC (cc)
<el@lisse.NA> el108 / | NA-NiC is the the .NA ccTLD Registry
Private Bag X5501 \ / NA-NiC, not just like that!
Oshakati, Namibia ;____/ Telephone: +264 81 124 6733 (cell)
Please send DNS/NA-NiC related e-mail to dns-admin@na-nic.com.na only
In message <BA14F896.16A94%jordyn.buchanan@registrypro.com>, "Jordyn A. Buchana
n" writes:
> 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 ough
> t
> > 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 b
> y
> > 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 a
> s
> > 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 Whoi
> s
> > 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, withou
> t
> > 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 reques
> t
> > 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 o
> f
> > 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 deletio
> n
> > 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 thes
> e
> > 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.
> >
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|