<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Registrars representative required for new DeletesTask 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-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-appc-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
>>>
|