ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

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


Bruce,

I'd like to support Rick's nomination of himself.

Regards,
Nikolaj

> -----Original Message-----
> From: Rick Wesson [mailto:wessorh@ar.com] 
> Sent: 7. oktober 2002 07:01
> 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-ap
> pc-16apr01.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-02jul01.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-ap
pc-16apr01.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.
>


<<< Chronological Index >>>    <<< Thread Index >>>