[ga] Re: [ncdnhc-discuss] Two Names Council Messages

[Jeff Williams <jwkckid1@ix.netcom.com>]

Danny and all,

  As you already know Danny disenfranchisement is a Hallmark of the
ICANN varied and confused processes.  It has been almost from the
beginning.  It has only gotten worse not better.  I am sure such
processes will worsen still more if that is at all possible.

DannyYounger@cs.com wrote:

> 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@icann-ncc.org
> http://www.icann-ncc.org/mailman/listinfo/discuss

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html