RE: Regarding registrar LOCK for panix.com

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

Bruce Tonkin wrote:

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.

Good. Thank you! Early on in the process, Eric Brunner claimed you
were a decent guy, or so I interpreted it.

We know how to do 3-way handshakes. Rather a fundamental of the
Internet. So quickly folks forget....

We knew in advance that the VRSN/NetSol/whatever protocol was terrible,
and that the ICANN policy change was not going to be helpful.

I think the notification process should parallel what anybody competent
would expect in a communications protocol. Retry. Several times. (Admittedly, I've been involved in protocol design for 28+ years, thus
have a tendency to see things that way.)

At the retry limit, declare the peer to be "down".

In this case, the peer being down means taking all their domains away
and revoking their registrar status and the performance bond.

Accountability. Responsibility.

I agree with you on this 100%. ICANN needs to enforce there current
policies. Look at totalnic/pacnames. They have been refusing transfer
requests years now until very very recent. What has ICANN done about
all those complaints and violations that has been well documented?
nothing!

ICANN needs to stop just accepting money and start enforcing policies...