ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

Re: [gnso-irtp-b-jun09] 60 day lock following registrant change

  • To: "Gnso-irtp-b-jun09@xxxxxxxxx List" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: Re: [gnso-irtp-b-jun09] 60 day lock following registrant change
  • From: George Kirikos <icann@xxxxxxxx>
  • Date: Thu, 15 Jul 2010 08:56:16 -0400

Hello,

On Thu, Jul 15, 2010 at 6:39 AM, Michele Neylon :: Blacknight
<michele@xxxxxxxxxxxxx> wrote:
> This working group is  discussing transfer _policy_
>
> Transfer policy needs to be applicable to _ALL_ registrants - not just those 
> who are willing to pay a premium for extra levels of security etc
>
> Also, the Verisign and Neustar registry locks did not exist when this WG 
> started

Following that logic, one also shouldn't be tailoring "policy" to the
*least* security-conscious registrants, those who are posting their
registrant username/password directly on their Facebook page with a
note "please steal my domain name" and then later want to undo their
domain name transfer because the name was "stolen" via some emergency
procedure.

UDRP isn't "free", by the way. That's an example of a policy option
that isn't open to the "poor" or those who don't wish to pay
anything....respondents also pay a "premium" if they want a 3-person
panel.

So, I'm not sure what you're arguing....is it that a "one-size fits
all" policy can exist that is going to make everyone happy?? Or that
registrars should be encouraged to have the lowest possible level of
security....and that should be incentivized through bad policy?

Here's a simple fact: not all domains are equal! This was explicit in
the issues report of last year, as I pointed out on Tuesday when I
wrote about "urgency" in a new thread:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00384.html

Note how "magntitude of the harm" was explicitly put into that report.
Magnitude of the harm recognizes that there's differences in economics
of registrants, and that one should not write a policy that is
intended for *all* domain hijackings. Some hijackings are more
important than others. If a claimed "emergency" is affecting Yahoo.com
and jkghkjhsjkhg.org (a random worthless domain), any policy for
"emergencies" might only be applicable for the first domain name, and
not the second. If some folks are unwilling to accept that, then
perhaps that's why this workgroup has been going in the wrong
direction.

Let me put it another way. A fire happens at a hospital, and at an
empty house. Is it any surprise when the single fire truck has to make
a choice of only helping one, it goes to the hospital (and lets the
empty house burn down)? The magnitudes of the harm differed greatly.
And the owner of the empty house could have invested in a sprinkler
system (but chose not to do so). As another example, if your "damages"
don't exceed a certain level (say $10,000), the FBI isn't going to
look at your case....that's an explicit realization that economics
*must* be used to prioritize policies.

The VeriSign/Neustar locks are just one option of high
security....registrars differ in the security choices they offer their
customers. Those customers explicitly consider security when they pick
a registrar. One (albeit unscientific) survey ranked security as the
2nd most important factor (behind price):

http://domainnamewire.com/2010/02/08/survey-price-security-most-important-when-choosing-domain-registrar/

with security being the #1 factor for large domain name holders (who
are presumably more sophisticated).

So, suppose that security is heterogeneous across registrars. Are we
supposed to ignore that consumers made an actual choice in their
registrar, in the level of security they wanted for a certain domain
name? As above, in creating a policy for emergencies, just as the
issues report discussed last year, isn't it supposed to be qualified
to only those situations where the magnitude of the harm is great?

Sincerely,

George Kirikos
416-588-0269
http://www.leap.com/




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

Privacy Policy | Terms of Service | Cookies Policy