ICANN/GNSO GNSO Email List Archives

[registrars]


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

[registrars] Transfers discussion

  • To: <registrars@xxxxxxxx>
  • Subject: [registrars] Transfers discussion
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Mon, 3 Nov 2003 23:01:44 +1100
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • Thread-index: AcOhyV6GJzfn2J9sTe2wMSCiYH0S5gAN2pVA
  • Thread-topic: Transfers discussion

Hello Tim,

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

That sounds like authority to transfer away from the losing registrar,
rather than authority to transfer to another registrar.  To transfer to
a gaining registrar implies acceptance of the gaining registrars terms
and conditions.




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

Sure - but the converse also applies - ie gaining registrars won't trust
losing registrars.
This is the heart of the transfer problem - there is a lack of trust
between the three entities
(registrant, gaining registrar, losing registrar).

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

In many cases the registrant is leaving the losing registrar because
they are unhappy with the service provided.  You model assumes a trusted
relationship between the registrant and the losing registrar - this is
often not the case.

The new transfers policy assumes a trusted relationship between the
registrant and the gaining registrar - this is normally the case when a
customer chooses a different supplier.



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

Surely the enforcement and dispute resolution issues are similar?


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

Agreed.  Although this is a problem with WHOIS rather than the transfer
process.

Incidently there is nothing stopping the following scenario in the
existing EPP protocol.
(1) Registrar periodically could generate a different auth-code (e.g
daily, weekly, monthly, yearly etc)
(2) Registrant could retrieve auth-code at the time they need to use it
- with a time-to-live value

Basically I would be OK with your model IF the auth-code can be
automatically retrieved, without interference from the losing registrar.


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

Agreed.  I think the problems are roughly equivalent.



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

Agreed.  The key in either model is enforcement.


Regards,
Bruce




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