Bruce,
Not sure about that. I think in most cases the gaining registrar
would
be well advised to get confirmation of authorisation to transfer. The
"key" is only a mechanism of authentication rather than authorisation.
The key is not an auth code. It is only provided after the losing
registrar has confirmed with the registrant. The gaining registrar does
not need to confirm because a valid key (matches the registry) is
evidence of the confirmation. So in this case it IS authorization.
The gaining registrar must still obtain acceptance of the new terms
and
conditions of the new registration agreement.
Agreed.
If the losing registrar chooses to trust the gaining registrar and
enforcement is available againstbad gaining registrars, the losing
registrar could explicitly confirm all transfers.
Thus not sure that your proposed process in the ideal case is better
than the new transfers policy in the ideal case. In the worst cases
they are also probably equivalent.
That's a pretty big IF Bruce. Losing registrars are never going to
completely trust gaining registrars, they're competitors. And in some
cases local law may not even allow them to.
When there's an unauthorized transfer the damage is done long before it
gets back to where it belongs. I'm still convinced that the losing
registrar is in the best position to accurately confirm, reducing
disputes and reversals.
With the current process you have difficult enforcement and dispute
resolution issues on both ends of the process. With the key system it is
focused on the losing registrar.
You need to look at the transfer process from the time the registrant
desires to transfer until the transfer is complete. I would assume
that
some losing registrars may not provide a key on a timely basis (after
first trying to convince the customer to stay).
I was considering that, and it will still be faster in the majority of
the cases. Right now querying registrars' whois, parsing out the admin
contact, dealing with parse errors, rotating formats, out of date data,
etc. is not an efficient process. Just getting to the point of being
able to actually submit the transfer request takes days and often even
weeks.
After the request is submitted there is most often another 5 days before
the transfer is completed, that's if it isn't denied by the losing
registrar and it starts all over again.
These are process flaws that are not easily solvable in the near future.
The problem with a losing registrar being slow to respond to a key
request is an enforcement issue that is at least as addressable as the
gaining registrar getting proper confirmation.
I am not aware of too
many other cases where a customer must seek some sort of permission
(e.g
transfer code) to move to a competitor.
Interesting spin, but what we're really talking about is the safe and
secure transfer of a service that is often associated with an entity's
livelihood.
As far as whether thick registries are better than thin, I'll leave that
for another discussion, transfers are just the tip of that iceberg. But
it looks like we'll have thin COM/NET for some time to come.
Tim
-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx
[mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Bruce Tonkin
Sent: Sunday, November 02, 2003 9:18 AM
To: registrars@xxxxxxxx
Subject: RE: [registrars] unsanctioned whois concepts (long)
Hello Tim,
If you were referring to the transfer key system I was
proselytizing about, I see some of the benefits as follows:
Eliminates the attempt to double confirm and reduces confusion.
Not sure about that. I think in most cases the gaining registrar would
be well advised to get confirmation of authorisation to transfer. The
"key" is only a mechanism of authentication rather than authorisation.
The gaining registrar must still obtain acceptance of the new terms and
conditions of the new registration agreement.
More reliable and quicker confirmation resulting in fewer
disputes. The losing registrar is in the best position to confirm.
If the losing registrar chooses to trust the gaining registrar and
enforcement is available againstbad gaining registrars, the losing
registrar could explicitly confirm all transfers.
Thus not sure that your proposed process in the ideal case is better
than the new transfers policy in the ideal case. In the worst cases
they are also probably equivalent.
Faster, almost immediate completion of the transfer.
You need to look at the transfer process from the time the registrant
desires to transfer until the transfer is complete. I would assume that
some losing registrars may not provide a key on a timely basis (after
first trying to convince the customer to stay). I am not aware of too
many other cases where a customer must seek some sort of permission (e.g
transfer code) to move to a competitor.
Whois data accuracy improved as it can be collected directly
from the registrant by the gaining registrar. The key
confirms the validity of the transfer so why force the import
of potentially outdated or poorly parsed data?
The problem of the WHOIS data in different formats in a significant one.
I prefer the thick registry model for this reason (although this does
not mean that the data should be made available to the public as is
presently the case).
I prefer centralised WHOIS for the formatting etc reasons - but also
prefer that the data only be made available under specific circumstances
- preferably under the control of the registrant.
A dynamically generated, one use key is more secure than a
static auth code for transfers.
True. Although this code could be generated automatically by a registry
and sent only to the contact stored in the registry. This would remove
gaming from the losing registrar.
Regards,
Bruce