RE: [registrars] Registrars representative required for new Deletes Task Force

["Tim Ruiz" <tim@godaddy.com>]

I would enjoy the opportunity to represent the RC on this TF.

Tim Ruiz
Go Daddy Software, Inc.

-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Ross Wm. Rader
Sent: Monday, October 07, 2002 8:57 AM
To: Bhavin Turakhia; registrars@dnso.org
Subject: Re: [registrars] Registrars representative required for new
Deletes Task Force


No offense to Rick - but it would be nice to see some fresh faces on these
task forces. Any other volunteers?


                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog

Please review our ICANN Reform Proposal:
http://www.byte.org/heathrow



----- Original Message -----
From: "Bhavin Turakhia" <bhavin.t@directi.com>
To: <registrars@dnso.org>
Sent: Monday, October 07, 2002 9:16 AM
Subject: RE: [registrars] Registrars representative required for new Deletes
Task Force


> I second Rick for the position too
>
> bhavin
>
> > -----Original Message-----
> > From: owner-registrars@dnso.org
> > [mailto:owner-registrars@dnso.org] On Behalf Of Rick Wesson
> > Sent: Monday, October 07, 2002 10:31 AM
> > To: Bruce Tonkin
> > Cc: 'registrars@dnso.org'
> > Subject: Re: [registrars] Registrars representative required
> > for new Deletes Task Force
> >
> >
> > Bruce,
> >
> > Rick Wesson would be happy to serve in this capacity if there
> > are no objections.
> >
> > -rick
> >
> >
> > On Mon, 7 Oct 2002, Bruce Tonkin wrote:
> >
> > > Hello All,
> > >
> > > At the Names Council meeting on 3 Oct 2002, it was decided
> > to form a
> > > task force to look at deletes issues.
> > >
> > > See below for a discussion paper on deletes that was posted
> > on 19 Sept
> > > 2002.
> > >
> > > There were four main issues identified:
> > > - uniform delete practice after domain name expiry by registrars
> > > - Deletion following a complaint on WHOIS accuracy
> > > - Registry delete process
> > > - Deletion required to Reverse renewal transactions
> > >
> > > The Registrars constituency needs to nominate a
> > representative to the
> > > task force. The task force work should be conducted over
> > approximately
> > > 100 days.
> > >
> > > Perhaps those that would be interested in volunteering
> > could indicate
> > > this to the list. If there are multiple volunteers I assume
> > we would
> > > hold a vote to select our representative.
> > >
> > > 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-16apr
> > > 01.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-02jul0
> > > 1.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-16apr
> > > 01.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.
> > >
> >
> >
> >
>