ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

[registrars] Deletes TF draft recommendations


The current draft of the Deletes TF recommendations can be found at:

http://www.dnso.org/clubpublic/nc-deletes/Arc00/msg00079.html

I am asking for your feedback in regards to the current recommendations.

Also, please see Ross' comments copied below. He raises some very good
points.

An updated draft of the TF recommendations should be available yet this
week. But there has been some further discussion in the TF on two of the
issues Ross refers to, and a third issue that I would especially like to get
your views on.

UDRP Exceptions:
http://www.dnso.org/clubpublic/nc-deletes/Arc00/msg00077.html

Another solution was proposed (by the IPC rep actually) that I personally
think makes more sense:

1. When a UDRP is filed, the UDRP Case Manager notifies the Challenger of
the expiration date of the domain name along with the other pertinent
information that they are already pulling together.

2. The Registrar is notified of the UDRP dispute as usual. The registrar
locks domain and deals with the situation as they currently do. No change
here.

3. If the Challenger wishes to make sure that the name does not get deleted
if the current registrant chooses not to renew, they go to the current
registrar and pay the renewal fee (non-refundable).

4. If the UDRP dispute is still unresolved at the time of expiration and the
current registrant does not renew, but the Challenger has paid the
non-refundable renewal fee, then the domain is renewed, put on Hold, and the
Whois information is changed to reflect that it is currently on hold pending
resolution of a UDRP dispute.

5. If neither the current registrant or the UDRP Challenger pay the renewal
fee, the domain is treated as any other expiring domain.

Uniform Reallocation of deleted/dropped names:

The TF does not want to side step this issue. But we are limited by the time
frame we have to work within given our original charter. The TF Chair will
be addressing this with the Names Council at their next meeting. What we are
hoping to do is confirm in this report that a uniform reallocation process
is desirable. If that is indeed the consensus, and it does appear to be, we
will then ask that the TF either be re-charted, or have our charter
extended, so we can give the issue the time it deserves and needs.

Uniform Deletes Policy for Registrars:

Please refer to the first 3 points of Issue 1 in the draft recommendations
and provide any comments.

Some on the TF have suggested that how/when registrars delete names "during"
the auto-renew grace period should also be uniform. My concern with that is
that it may conflict with the business models and legitimate practices of
some registrars. I personally believe that requiring the name to be deleted
no later than the end of the grace period should suffice.

Tim


-----Original Message-----
From: Ross Wm. Rader [mailto:ross@tucows.com]
Sent: Tuesday, December 10, 2002 12:21 PM
To: registrars@dnso.org
Cc: 'Tim Ruiz'
Subject: Draft Delete Recs & General Comments


Just getting caught up on the work of the deletes task force - here are
some general comments for the benefit of the TF rep and the membership.

...

UDRP Exceptions:

I must say that this is one of the more involved, least sensible
proposals that I have seen since WLS was put forward as a solution to
the "add-storm" issue.

http://www.dnso.org/clubpublic/nc-deletes/Arc00/msg00077.html

Specifically, I cannot understand why it would be important, desirable
or even appropriate to force a registrant to extend a contract because
of an outstanding dispute.

What is it specifically that this proposal is attempting to achieve? If
it is simply to pander to a narrow range of IP oriented interests, might
I be so bold as to suggest that this might not be worth the trouble that
it took to put it into words? Never mind whether or not it is worthy of
further consideration.

"Undo":

Regarding issue #4 here:
http://www.dnso.org/clubpublic/nc-deletes/Arc00/msg00079.html

Undo is an important function. The task force can and should deal with
the issue on a policy level. Dodging the hard question by characterizing
this as an IETF issue does the registrar and larger community a huge
disservice. "Undo" represents a purely administrative function begging
for policy analysis and correction - the technology can follow later
once the requirements have been spec'd through the policy process.

Re-allocation:

To V.3 here
http://www.dnso.org/clubpublic/nc-deletes/Arc00/msg00082.html
(reallocation): predictable processes are hugely valuable to my business
and my customers. Please don't sidestep this important issue - it begs
to be dealt with as well.

                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog

Please review our ICANN Reform Proposal:
http://www.byte.org/heathrow







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