Regarding registrar LOCK for panix.com

Thu Jan 20 05:49:33 UTC 2005

Hello William,

> 
> Stop blaming the victim!  Stop blaming anybody else.
> 

I at no stage have blamed the victim.   In fact I am sincerely sorry for
the damage caused to panix.com.

The transfer should NEVER have been initiated.   Melbourne IT has
consistently acknowledged the error.

I have however discussed the problem from the point of view of the
overall transfer process, as I want to improve it.   There have been
claims made on the list that the other parts of the system did not work.
I am providing factual information on what happened through the process,
and exposing the process to public review on this list.   
I have pointed out that the process can be strengthened.  This is in no
way blaming the victim.  It is the role of domain name registrars to
educate the registrants on their options.

To reiterate, for a .com name there are two optional checks/mechanisms
that can be used to further prevent an unauthorised transfer (and I will
say again, I agree that the transfer should not have ever been
initiated).

(1) A name may be placed by a registrar on Registrar-LOCK.  This is
optional, and it is up to a registrar to inform their customers of this
option.   The name was not on Registrar-LOCK at the time of the transfer
request.

(2) The Registry must advise the losing registrar of a transfer request.
I believe this happened, as I have a copy of the corresponding email
sent from the registry to the gaining registrar.  This does not mean
that the losing registrar actually received this email.

(3) The losing registrar MAY (ie it is an option available to the losing
registrar but not a requirement) send a confirmation message to the
registrant.   In this case it appears that this did not happen, possibly
because the confirmation message in (2) was never received by the losing
registrar.     There is no end-to-end confirmation in the current RRP
system, for Verisign to be able to confirm that the losing registrar
actually received its notification.

To repeat again, I am not trying to escape any blame, not cast any blame
on any other party.  I am interested from an engineering point of view
in improving the process to avoid it happening again.

Regards,
Bruce