DNSO Mailling lists archives


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

[nc-udrp] Re: [nc-deletes] Revised draft recommendations


These are helpful comments, but I'm not sure what they mean in practice.

If the UDRP Case Manager tells the challenger that the domain is about to
expire, but there is no mechanism for the challenger to pay for the domain,
the information isn't all that useful.  Similarly, unless we have some
notion of how a registrar is supposed to act once a challenger has paid for
a domain, we could very easily end up with the situation you describe below
in which we just give the expiring name to the challenger.

The high level description of the proposal is:  "Inform the challenger the
name is going to expire, and let them pay for the renewal if the registrant
is not going to."  As always, the details get a bit more complicated than
that, but I'd rather think about some of the details now than when the types
of problems you describe start to crop up.


On 12/12/02 2:25 PM, "John Berryhill Ph.D. J.D." <john@johnberryhill.com>

> That is correct, and in parallel with this effort, I have suggested a "no
> contest" response to be included in the UDRP.
> The thing is, if the Respondent doesn't renew during a dispute, that fact
> does not entitle the UDRP Complainant to obtain registration of the domain
> name.
> To one way of thinking, one could say, "Oh, then, just give it to the
> Complainant".   But whether or not the Respondent responds at all, the
> Complainant has to prove their case under the Policy in order for the Panel
> to order a transfer of the domain name to the Complainant.
> If you say, "Oh, then, just give it to the Complainant", then what you have
> is not the UDRP.  What you have is, in fact, a way of short-circuiting the
> Wait List Service.  You see, if you want an expiring domain name, and you
> find that someone has already taken the WLS slot, then your solution is
> simple - you file a UDRP complaint.  Now, who gets the domain name?   The
> person who already paid to be the first in line when it expires?  Or the
> person who wanted it badly enough to pay more for a UDRP - even if they
> *don't* have a trademark of any kind.
> I know that many of the good-hearted people here, and on the UDRP Task Force,
> don't tend to normally think about how well-intentioned rules can be
> perverted to work odd results... But there is reason to believe there are
> situations where the UDRP - even as it is - has been used collusively between
> "complainants" and "respondents" for purposes that are not apparent on the
> surface.  Turning the UDRP into "Wait List Plus" is an unintended result of
> problem that can simply be handled by making it the Case Manager's
> responsibility to check the expiration date and notify the parties.  UDRP
> Case Managers are really good at following and enforcing rules - that's their
> job.  Registrars' jobs should be to simply run a simply understood system.
> Keeping registrars out of the rule interpretation business is good for
> everyone.
> Another example of the law of unintended results at work here is if you
> combine whois-accuracy deletes with the Wait List Service.  You want to keep
> fake whois data?  Okay, that's simple.  You register your fake domain *and*
> you take out the WLS slot on that name.  Now, you want to complicate the
> deletion process by making sure that whois-accuracy deletions can't be
> rescued by the miscreant.... So what?  The miscreant gets the same name back
> through the WLS, and immediately takes out the same WLS slot again.  It is
> okay if you want to set up the system that way, but it is going to be the
> same people who are making the same complaints next year, when they realize
> it takes about five minutes to figure out how to get around the policy that
> it took them five months, and imposed complicated rules on the registrars, to
> formulate.
> Keep it simple.
> Some of these "solutions" sound like a plastic surgeon contemplating the next
> operation to "fix" Michael Jackson's nose.  You know how a nose gets that
> way?

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