ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

RE: [gnso-irtp-b-jun09] 60 day lock following registrant change

  • To: "George Kirikos" <icann@xxxxxxxx>
  • Subject: RE: [gnso-irtp-b-jun09] 60 day lock following registrant change
  • From: "James M. Bladel" <jbladel@xxxxxxxxxxx>
  • Date: Tue, 06 Jul 2010 09:34:45 -0700

George and Team:


Not surprisingly, I disagree with George's interpretation of this policy
and our practice, and what constitutes "opt-in" vs. "opt-out."  

Setting that aside, however, the primary issue that this group is
wrestling with is the balance between Domain Security vs. Domain
Portability.  

As a Domainer, George tends to support Domain Portability.  And this is
also true of Go Daddy.  We believe that, given a choice of registrars, a
large number will choose Go Daddy because of our pricing, services, and
associated products.  Some will not, but this is why we have a
competitive marketplace.

But in our quest for portability, we must acknowledge that reasonable
safeguards against fraud and theft are required.  And that these
safeguards will represent an inconvenience (but should not become an
impediment) to portability.

In his introduction today, George mentioned that he is the registrant of
several high-profile domain names.   Registrants of these names are
probably aware that their registrations are prime hijacking targets, and
should consider their response if/when one of these names were suddenly
transferred to an unresponsive registrar in China.  Some may respond
that this is impossible, because they "only use Registrar X" or "only
operate according to Best Practice Y."  But this is naive, and
disregards the fact that no registration is simultaneously 100% secure
and 100% portable.  

In this scenario, the affected registrars / registry _may_ be able to
help, but are not obligated to. And some of those remedial mechanisms
could take months or even a year to run their course. 

 Which brings us back to ETRP.  In its current form, I can't support the
proposal due to the lengthy (6 month) window and the impracticalities of
the "Title / Token" system.  But I know that, in the here and now, our
internal 60-day lock is a good (not perfect) prophylactic against
hijacking.   

Absent the opt-in lock and absent an ETRP would open all registrars'
vaults to the bad guys, and severely undermine (if not totally undo)
_both_ the Primary domain name industry and the Secondary aftermarket.



J.




-------- Original Message --------
Subject: Re: [gnso-irtp-b-jun09] 60 day lock following registrant
change
From: George Kirikos <icann@xxxxxxxx>
Date: Tue, July 06, 2010 10:23 am
To: "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>


Hello,

> We understand GoDaddy.com’s 60-day lock is a voluntary opt-in process where
> registrants are made aware of and agree to the restriction that the domain
> name is not to be transferred for 60-days following the completion of
> transfer. As such, this practice is not prohibited by the transfer policy.
>  Registrants are free to transfer to different registrars if they're not
> satisfied with either the service or terms of service provided by their
> current provider (i.e., registrant "A" could transfer the name to a new
> registrar and then request the change of registrant to "B" at a registrar
> that is willing to offer that service without asking the new registrant to
> agree to reject transfer requests).

This is where I believe ICANN has it wrong, and is misinterpreting the
policy. The transfer policy says transfers can be denied in the
instance:

http://www.icann.org/en/transfers/policy-12jul04.htm

"Express written objection to the transfer from the Transfer Contact.
(e.g. - email, fax, paper document or other processes by which the
Transfer Contact has expressly and voluntarily objected through opt-in
means)" (Section 3, Reason 6)

To be "opt-in", it cannot just be an agreement that a registrant makes
on a *blanket basis* without the ability to later decide to expressly
opt-out of. For example, a registrar might put into its terms of use
that a domain name can't be transferred for 50 years. What prevents
that, if ICANN's interpretation above is correct? Would that trump
ICANN "minimum standards", which are protections for registrants from
abusive registrars? My position would be that the ICANN minimum
standards are *rights* for registrants which are above the provisions
of the registration agreement (many of which might be contracts of
adhesion, in any event).

In this case, the "fundamental right" is that for a registrant to
choose the registrar they wish to use. Quoting from the above, ICANN
shows its inconsistency when it says "Registrants are free to transfer
to different registrars if they're not satisfied with either the
service or terms of service." That should be an absolute right (i.e.
except subject to the 60 days from creation"), not one that can be
"negotiated away" as some registrars seem to believe.

Even if one nominally "opted-in" to a more secure process, e.g.
executive lock, etc., one should be able to equally opt-out again as
easily as it was to opt-in in the first place. e.g. I might agree with
my registrar "reject all transfers unless you get a counter-signed fax
from me expressly removing this lock." Later, I should be able to
opt-out of this by using the counter-signed fax to cancel prior
restrictions.

So, let's give an example, I buy example.com from Party A and do a
change of registrant at GoDaddy on August 1, 2010, and the creation
date is 1995 (so 60 days from creation is not a factor). I decide, for
whatever reason, on August 20, 2010 (less than 60 days since change of
registrant), that I want to transfer to Moniker. I should have the
right to do so. GoDaddy might say "well, on August 1, you agreed that
you wouldn't transfer for 60 days." However, on August 20, I would be
revoking that supposed "express written objection" that GoDaddy is
relying upon (and they could authenticate it all they want). In other
words, I'm opting out.

Indeed, the gaining registrar might have an affidavit from me
expressly *desiring* the transfer, and that should trump the older
"opt-in." The older "expression written objection" is no longer valid.

Recall why the transfer policy even exists -- it's because there was a
desire for "portability" of domains, just like telephone numbers. If
we allow every registrar to start suggesting that they can incorporate
their own supposed "opt-in" procedures (which are not really opt-in,
if they can't be opted-out of), this would be a slippery slope that
would reverse the gains registrants have made, and would permit abuse
against registrants.

Anyhow, under the status quo (without the ETRP), this becomes moot on
a practical level, because most folks in the secondary market will
initiate a transfer from their favourite registrar, and never be a
registrant at the "undesirable" registrar. This all changes, though,
if the ETRP is adopted as currently proposed, because it would put
those kinds of transfers (which I'd consider "best practices") at huge
risk, as the domains could be unilaterally "clawed back" without any
due process.

If the ETRP existed (as currently proposed), one might consider doing
the registrant change at the "undesirable" registrar first, and then
transferring to one's preferred registrar (as then the only person who
could initiate the ETRP would be yourself). However, if each registrar
is reinterpreting the Rules to basically hold those names hostage, one
can be at even greater risk at the "undesirable" registrar with their
ad hoc interpretations of "rules" and "policies."

In the end, registrants have a legitimate need for their domains to be:

(a) irrevocably transferred to them so that they have clear title (or
at least subject to much due process if challenged), and
(b) at their preferred registrar

ICANN policies (and those of certain registrars) should not be
thwarting these simple needs.

Sincerely,

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





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

Privacy Policy | Terms of Service | Cookies Policy