Deletes Task Force (Fwd: Re: [ncdnhc-discuss] Two Names Council Messages)

[Adam Peake]

Appropriately inspired, thanks Danny 
(<http://www.unitedmedia.com/comics/dilbert/archive/dilbert-20021005.html>), 
I'll volunteer.  But, to be honest (like the rest of the 
constituency?) I'm not very excited by the issue.

Thanks,

Adam

Adam Peake
GLOCOM Tokyo
<http://www.glocom.org>

"The best way to use a megabit of bandwidth is to deliver a kilobit 
of data in a tenth of a second?"


>Delivered-To: ajp at glocom.ac.jp
>From: DannyYounger at cs.com
>Subject: Re: [ncdnhc-discuss] Two Names Council Messages
>To: hfeld at mediaaccess.org, discuss at icann-ncc.org
>Sender: discuss-admin at netaction.or.kr
>X-BeenThere: discuss at icann-ncc.org
>X-Mailman-Version: 2.0.3
>List-Help: <mailto:discuss-request at icann-ncc.org?subject=help>
>List-Post: <mailto:discuss at icann-ncc.org>
>List-Subscribe: <http://www.icann-ncc.org/mailman/listinfo/discuss>,
>	<mailto:discuss-request at icann-ncc.org?subject=subscribe>
>List-Id: Discussion List of Non-Commercial Domain Name Holders 
>Constituency  <discuss.icann-ncc.org>
>List-Unsubscribe: <http://www.icann-ncc.org/mailman/listinfo/discuss>,
>	<mailto:discuss-request at icann-ncc.org?subject=unsubscribe>
>List-Archive: <http://www.icann-ncc.org/pipermail/discuss/>
>Date: Mon, 7 Oct 2002 11:18:29 EDT
>
>Dany Vandrome earlier posted a copy of the preliminary NC Deletes Issue Paper
>for comment.  At that time, no one in the constituency chose to offer a
>comment.  In view of Harold's request that the constituency identify a
>representative to participate in the Deletes Task Force, I am reposting the
>Issue Paper.  The issues that this task force will tackle are of great
>importance to many members in the General Assembly that will no longer either
>have an Assembly nor will have representation on any task forces (thank you
>Alejandro for your stalwart efforts to further disenfranchise these members
>of the community), so we are forced to rely on this constituency's efforts to
>protect the registrant in the ICANN process (as we know we can't count on any
>other constituency to act to safeguard our interests).
>
>I hope that someone will eagerly volunteer to take on this responsibility.
>
>
>
>Hello All,
>
>The attached issue paper has been prepared by a small team comprising:
>
>Bruce Tonkin
>Alexander Svensson
>Ross Wm. Rader
>Ram Mohan
>Jordyn A. Buchanan
>Liu, Hong
>
>The intent of this paper is to stimulate discussion within the DNSO
>constituencies, and will be used as a basis for the Names Council to
>determine whether to initiate a policy development process for this issue.
>The Names Council will discuss and vote on this issue during the
>teleconference of 3 October 2002.   Please forward this paper to the
>relevant constituency and GA mailing lists.
>
>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.
>_______________________________________________
>Discuss mailing list
>Discuss at icann-ncc.org
>http://www.icann-ncc.org/mailman/listinfo/discuss


--