ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

RE: [registrars] Possible Transfer Procedure Solution?


see below...

> -----Original Message-----
> From: Larry Erlich [mailto:erlich@domainregistry.com]
> Sent: Friday, June 08, 2001 4:09 PM
> To: Paul Stahura
> Cc: registrars@dnso.org
> Subject: Re: [registrars] Possible Transfer Procedure Solution?
> 
> 
> 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. 

OK I should have said "I have no *efficient* way to verify"

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

1) all of these (except email) require at least some manual process
2) All of them take time on the order of at least days
3) Many email addresses in the whois do not work, even though
the rest of the information may be perfectly valid.
4) Which contact do you use?
5) If for example, you use the email address of the
admin contact, then what you are saying is that whoever
has accesses to that email account has the authority
over the name, *plus* the registrant email, *plus* whoever
answers the phone, or has accesses to the fax number in the whois,
etc.

But the biggest problem is what do you do
if you cannot get a hold of the person by whatever
method? 

The good thing about this "Registrar Lock" method
is that you can use whatever method you want
to veryify the user's identity.  It is just that
*I* dont have to rely on your method.


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

The password, in my opinion, should be the definitive
method.  This is effectively what the EPP protocol uses.
I would guess the key held at the EPP registry
would be difficult to guess.

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

So you would not be *sure* it was they guy who has
the authority.  It could be my ex-wife or a disgruntled
employee, or I could have changed that phone number and
forgot to update the whois record, inadvertantly giving a random
person the authority over the domain.  Plus calling
a phone number is not cost-effective.

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

You are correct.  I didn't put everything in my original 
message to try to keep it short and to try not to confuse everyone,
because I know this Lock thing is not easy to get.  
But... what we (eNom) do in this case is to take away
the ability for the registrant to unlock it
until the issue (legal thing, non-payment, whatever)
is straightened out.

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

If they want to perform DNS changes, we automatically
unlock it, make the change, then quickly lock it again
in one process.  So while they may not
have the ability to unlock it for a long period of time
(ie to transfer it during a legal proceeding), 
DNS changes can still occur.

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

See my statement above for the solution to this.
We have been utilizing this method for
over a year, BTW, with little, if any problems.
Another solution, but one that would require 
effort by the registry and a change to the RRP spec,
is to add another command,
maybe something like "allow transfer" that would
perform the same function as "lock" but allow
changes to be made even if transfer was not allowed
on the name. This would then not overload the
definition of "registrar lock"

No matter what, me thinks it will require some
effort by someone to solve the transfer issue
we are all facing.

> 
> Not in favor of this solution. Sorry.

No problem, thanks for the feedback.

Paul

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


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