ICANN/GNSO GNSO Email List Archives

[registrars]


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

RE: [registrars] FYI re: Transfers

  • To: Registrars Constituency <registrars@xxxxxxxxxxxxxx>
  • Subject: RE: [registrars] FYI re: Transfers
  • From: Tim Ruiz <tim@xxxxxxxxxxx>
  • Date: Fri, 21 Sep 2007 13:23:01 -0700
  • List-id: registrars@xxxxxxxxxxxxxx
  • Reply-to: Tim Ruiz <tim@xxxxxxxxxxx>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • User-agent: Web-Based Email 4.10.24

> trying to correct them by restricting transfers 
> in violation of policy as above is like strip 
> searching every customer leaving wal mart in an 
> attempt to stop shoplifting!

Given the impact of a hijacking on the victim, I think a better analogy
might be making all passengers pass through security at the airport
before allowing them to board the plane. While the vast majority are
perfectly harmless, I for one certainly wouldn't want to see that
change.

That said, I'm not really concerned about minor changes to contact info.
It is the complete transfer or assignment of the registration agreement
to an entirely new entity followed by an immediate registrar transfer,
or one shortly thereafter, that should at the least garner closer
scrutiny and caution. 


Tim 

-------- Original Message --------
Subject: Re: [registrars] FYI re: Transfers
From: elliot noss <enoss@xxxxxxxxxx>
Date: Fri, September 21, 2007 2:48 pm
To: <john@xxxxxxxxxxxxxxxxx>
Cc: Registrars Constituency <registrars@xxxxxxxxxxxxxx>


> Is there a "Deadbeats and Hijackers Constituency" driving these
> "clarifications"?

john, try the "average users who get screwed out of using the 
provider of their choice" constituency. membership is extremely large.

comments inline.

On 21-Sep-07, at 12:08 PM, John Berryhill wrote:

>
> Here is the utterly incomprehensible phrase that jumps out twice in 
> this
> document:
>
>> the domain name is in the registration
>> period after expiration,
>
> What is the "registration period after expiration"?
>

I will not excuse the tortured syntax but I suspect you are smart 
enough to know this refers to the registrar-defined period, not to 
exceed 45 days, after expiry and before RGP.

>
>
>> 2. A registrant change to Whois information is not a
>> valid reason to deny a transfer request.
>
> So, Registrars are to verify whois data UNLESS the Registrant 
> providing
> fraudulent whois data is requesting transfer of the domain name. 
> In that
> case, forget about verifying whois data, and let the hi-jacker, who 
> obtained
> the account login information and changed the WHOIS yesterday, run 
> with the
> name.
>

again, I think you well know that the advisory is intended to deal 
with minor changes in the whois that are used to create an excuse to 
deny transfers. the typical situation that we encounter is the 
combination of these two "security-friendly" provisions:

- renewal time approaches;
- registrant, often a small business, wants to change suppliers and 
realizes that their whois info needs to be updated (they moved, 
employee has left/was fired, etc.) and makes the change and then 
initiates a transfer;
- "security-friendly" policy 1 --------> sorry, you made a change and 
now you can't transfer the name for 60 days. of course this puts them 
past expiry leading to.......
- "security-friendly" policy 2 --------> sorry you are past expiry, 
you can now only renew not transfer.

a few things are important to note. first, what ICANN is reiterating 
is the current policy. now I am the last guy to say "a rule is a rule 
is a rule" but let's be clear that these ARE the current rules, are 
the result of consensus policy inside the ICANN process (one of the 
very very few things to actually make it through the process) and 
were put in place to facilitate registrants freedom to work with the 
supplier of their choice.

second, numerous registrars simply flout the existing policy and 
ignore it. ICANN has done nothing. I, and others, have complained 
about this loudly and publicly. they should be commended (ICANN I 
commend you!) for issuing an advisory. now they need to follow that 
with enforcement.

third, the security issues that are raised can be dealt with in a 
number of alternative ways, too numerous to enumerate here.

fourth, the inability to transfer because of the policy violations 
happens orders of magnitude more often than hijacking attempts.

last, the industry has done a FANTASTIC job of rectifying wrongdoing. 
when there is a hijacking of a name of any value registrars work 
together to rectify. in 2000 I created the indemnity system to allow 
us to cover NSI's often exposed ass. the network of compliance groups 
(bigger registrars) and operators (smaller registrars) does an 
amazing job of righting wrongs. there are simply more efficient and 
fair ways to do this than by denying transfers in violation of ICANN 
consensus policy.

the issues raised as "security concerns" are always about fraud. no 
question these happen on an exceptional basis. trying to correct them 
by restricting transfers in violation of policy as above is like 
strip searching every customer leaving wal mart in an attempt to stop 
shoplifting!

Regards
Elliot Noss






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