ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

[gnso-irtp-b-jun09] Proposal: Irrevocable Transfer Procedure (ITP)

  • To: "Gnso-irtp-b-jun09@xxxxxxxxx List" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: [gnso-irtp-b-jun09] Proposal: Irrevocable Transfer Procedure (ITP)
  • From: George Kirikos <icann@xxxxxxxx>
  • Date: Wed, 23 Jun 2010 18:52:57 -0400

Hi folks,

So, I was talking with a few others, and here's a possible way to make
everyone happy, in a simple and market-based solution.

If  the ETRP is going to cause all standard transfers to suddenly be
undoable just on the basis of a "claim" that anyone can make without
proof, what's really needed is a separate optional "irrevocable
transfer procedure" (I'll call it the ITP for now -- that's a 3-letter
acronym that appears to be unused in the world of ICANN!) whereby
folks can opt-in to irrevocable transfers, just as people can make
wire transfers (which are irrevocable, as most folks are aware). e.g.
in Canada:

http://www.cdnpay.ca/publications/general_lvts_payments.asp

Under an irrevocable transfer, the registrant would be opting in
explicitly to be unable to apply the ETRP. Then, the market would be
able to decide which type of transfer they want for a given
transaction.

If I'm buying a high-value domain, I would insist upon the current
owner transferring the domain name to me via the "Irrevocable Transfer
Procedure." The losing registrar could charge a premium, etc. for the
authentication (just like a bank charges a few extra bucks to send a
wire transfer), etc. Once it's at the gaining registrar (Tucows for
me), the transfer can't be reversed by the ETRP, because the ETRP
would not apply to transfers done using the ITP.

If a "normal" registrant wants to use the supposed "protection" of the
ETRP, they can opt for the current system. E.g. if they know the
transfer is to themselves, from one registrar to another, they might
stick with the standard process, to save money.

Then, we'd let the market decide, and see which system actual
registrants would decide to use. Sophisticated, security-conscious
people in the secondary market would use the ITP, you can be assured
about that.

However, this proposal would be taking things backwards in the
registration system, a step backwards in domain portability, because
it would basically authorize losing registrars to hold the existing
domain name hostage, and thwart the transfer of domain names securely
and irrevocably to a new registrar. In essence, the losing registrars
would be imposing a "tax" on every irrevocable transfer. Thus, for
this proposal to work, this "tax" needs to be capped, say at twice the
standard registration cost, or some other figure (e.g no more than the
RGP fee).

There's really no need for this 'tax' at all, because it's the
procedures of the losing registrar that dictate how/when they give out
the EPP code (and how they unlock the domain name). Losing registrars
who give up that code too easily, or who don't really know their
clients, or who don't offer their customers good security --- well,
they're the ones to blame for hijackings. But, it'll be a tax that's
ultimately passed on and paid by registrants who choose to go with bad
registrars, and reputation loss will hopefully ensure that those
registrars who gouge will lose market share, as registrants realize
that sales proceeds from domains located there will have that higher
transaction cost compared to other registrars who don't hold domains
hostage.

For those who want the certainty of an irrevocable transfer, the
option should continue to be available. Indeed, it's what we have
right now!

Later, when the ETRP gets abused and misused, when seller's remorse
reigns,  and folks see the history of the debate, then they can
eliminate the ETRP at that point. But, don't impose it on everyone
today on a *production* system.

If that seems like a reasonable compromise, let me know.

Sincerely,

George Kirikos
416-588-0269
http://www.leap.com/



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

Privacy Policy | Terms of Service | Cookies Policy