Re: [registrars] Possible Transfer Procedure Solution?

[Larry Erlich <erlich@domainregistry.com>]

Paul Stahura wrote:
> 
 file).
> 
> With the .com net and org registry it is up to
> each individual registrar to verify the identity
> of their customers.  I have no way to verify the identity
> of one of my competitor's customers. 

I don't agree. 

If you can believe the information in
the whois (which the registrant must maintain
as accurate) then you can verify the identity.
And the registrant has the responsibility to maintain
that information as correct.

> This is the problem
> with transferring names: how do I know for sure a person is the
> registrant of the name he wants to transfer?

You could call them at the phone number listed
in the whois, you could email them. Or you could
write them a letter which they could fax back.

> Only
> my competitor can truly verify the identity of a registrant
> of a name that is not at eNom.

If the whois information is coreect, 
the above is all that the current registrar
would do other than password which could 
be stolen or guessed in many cases.

I could pick up the phone can call you (Paul)
at 425-883-8860 and if someone on the phone
said they were Paul Stahura I would have to believe
them. Of course it could be the janitor claiming
to be you or something like that but...

>  Therefore I'm suggesting
> that we utilize registrar lock as the mechanism whereby
> the losing registrar verifies the identity of the registrant,
> and the registrant signals his willingness to accept a transfer
> (instead of replying to an email).

Unfortunately, there are other reasons to lock a
name other than what you have mentioned. There are
legal proceedings, there is non payment issues etc.
So if you give customers the ability to "unlock" names
so that they can make DNS changes and other changes
how are you going to prevent them from doing things
that you don't want them to do?

The answer would be that you could easily program
around that with other mechanisms. But unfortunately,
at least the way our system is setup, we are not
in a position to modify our system to use registrar
lock for the reasons that you are mentioning. 

> 
> Simply:  if the name is on registrar lock then that means
> that the registrant has not authorized a transfer.

And it could mean other things as mentioned.

Not in favor of this solution. Sorry.

Larry Erlich

http://www.DomainRegistry.com

>  If the
> registrant wishes to transfer the name, the registrant
> would go to the losing registrar (who verifies the registrants
> identity by whatever method they are currently using)
> and take the name off lock, then to the gaining registrar
> to initiate the transfer.
> When the transfer request occurs, the losing registrar
> would know the intentions of the registrant
> because the name is not locked.
> 
> Benefits include:
> 1) the gaining registrar knows it did not transfer in real-time because
> the transfer request is immediately denied by the registry for names on
> lock.
> The gaining registrar could immediately inform the registrant
> to take the name off-lock at the losing registrar in order to continue the
> transfer process,  thereby improving service to all of our customers.
> 2) If the name is accidentally/maliciously transferred/slammed, the losing
> registrar
> is not as liable because the registrar gave the registrant the opportunity
> to lock it.
> 3) It is easy for a registrar to implement
> 
> Negatives:
> 1) registrars must take names off-lock to change name servers
> 2) registrars must provide a method for registrants to lock
> and unlock their names.
> 
> eNom currently utilizes this procedure.  We currently allow (ACK)
> all outgoing transfer requests from the registry without question, because
> we only receive transfer requests from the registry for names that the
> registrant has signaled to us he/she wishes to transfer.
> 
> Paul

-- 
-----------------------------------------------------------------
Larry Erlich - DomainRegistry.com, Inc.
215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com
-----------------------------------------------------------------