ICANN/GNSO GNSO Email List Archives

[registrars]


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

RE: [registrars] FYI re: Transfers


The new guy that buys the domain from an existing owner has no ability to
opt-out of Godaddy. There is no opt-in for this guy. He is stuck there for
60 days.

Perhaps facilitating an assignment of the registration agreement should be
required by all registrars because it is not offically in the RAA. It seems
EVERY registrar offers it for free. So using assignment as an excuse should
be mute.

We need a consense policy that says, "Every registrar will facilitate the
assignment of a registration agreement". Does anyone else think this should
be an offical policy?

What registrar doesn't allow this. Network Solutions circa 1999 perhaps. But
Network Solutions circa 2005 allowed it. But Network Solutions 2007 has
followed suit with GoDaddy and now does the same assignment hurtle as a
barrier to leaving.

-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx
[mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
Sent: Saturday, September 22, 2007 2:45 PM
To: 'Registrars Constituency'
Subject: RE: [registrars] FYI re: Transfers


> Forcing the registrant of the domain to stay 
> doesn't seem right.

We are not forcing anyone to do that. We offer a service (not required
by the RAA or any policy) to facilitate an assignment of the
registration agreement and assist with the transfer of a domain name
from one Registered Name Holder to another. We offer that service for
free with certain conditions the user agrees to up front. The
alternative is to transfer registrars first, then perform the transfer
to a new Registered Name Holder. The user decides which works best for
them.


Tim 


-------- Original Message --------
Subject: RE: [registrars] FYI re: Transfers
From: "Jay Westerdal" <jwesterdal@xxxxxxxxxxxxx>
Date: Sat, September 22, 2007 3:25 pm
To: "'Registrars Constituency'" <registrars@xxxxxxxxxxxxxx>


A registrant is often transferring after a sale. That is
why a change occurs right before a transfer. Forcing the
registrant of the domain to stay doesn't seem right.

I would suggest Godaddy handle the closer scrutiny and
caution to an internal team that calls the current or
previous owner and lets them know. But in no way interferes
with a transfer unless they believe it is against the wishes
of the registrant. Blocking everything simply will not fly.
People have been complaining about this for years.

I would love to see a log of every transfer that was blocked
and how many of those where because the registrant was being
hijacked.

-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx
[mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of elliot noss
Sent: Friday, September 21, 2007 6:56 PM
To: Registrars Constituency
Subject: Re: [registrars] FYI re: Transfers


except the FAA has set a standard and some airports have taken it 
upon themselves to not only engage in additional, intrusive security 
measures that slow down travel and commerce but also cause the 
traveler costs in time and money that they would otherwise not incur.

the fact that it makes those airports more money may or may not be 
relevant.

I do, however agree with your statement "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." I would encourage you to try and find an approach that 
satisfies both goals. I would look forward to supporting that as a 
change in policy.

Regards
Elliot Noss

On Sep 21, 2007, at 4:23 PM, Tim Ruiz wrote:

>
>> 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 >>>