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

["Bhavin Turakhia" <bhavin.t@directi.com>]

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.
> >
> 
> 
>