Proposed ICANN "Expedited Transfer Reversal Policy" could disrupt secondary market (part 2)

[George Kirikos <gkirikos@xxxxxxxxx>]

Proposed ICANN "Expedited Transfer Reversal Policy" could disrupt secondary 
market (part 2)

Since it's clear some members of the working group plan to ignore all comments 
that were made in the WG mailing list by me, I'm reposting them below "on the 
record."

Sincerely,

George Kirikos
President
Leap of Faith Financial Services Inc.
http://www.leap.com/

P.S. They are divided by letter, A], B], C], D]......Z], with links to the 
originals on the WG mailing list.

A] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00326.html

I saw some interesting comments on Twitter from an ordinary user in
relation to GoDaddy's so-called "opt in" hold. It should perhaps serve
as a reminder why rules about transfers between registrars were
created originally:

http://twitter.com/wedschilde/status/16429902106

@godaddy FAIL. having to fight to transfer domain for
threecrowpress.com. giving 24 hours. ICANN complaint already filed.
#godaddyfail

http://twitter.com/wedschilde/status/16430649817

@Beshter @brk_nlssn i hate having to fight for something that's mine.
major #godaddy fail. sighs.

http://twitter.com/wedschilde/status/16430757083

@Hoshiko_Malfoy i need a tweetwar. godaddy (@godaddy) doesn't want to
release my domain name. i demand it release the hostage.

http://twitter.com/wedschilde/status/16430802773

@Beshter i've already filed an ICANN. they do this all the time. it's
commonplace. & in @godaddy math, 8.10.10 is 60 days from now.

http://twitter.com/wedschilde/status/16431350059

@brk_nlssn Holding threecrowpress.com hostage because for "internally"
opt-in security rules. i told them no. release it. bad @godaddy

I think this example goes directly to points (c) and (d) of the charter:

"c) Whether special provisions are needed for a change of registrant
when it occurs near the time of a change of registrar. The policy does
not currently deal with change of registrant, which often figures in
hijacking cases;

d) Whether standards or best practices should be implemented regarding
use of a Registrar Lock status (e.g. when it may/may not,
should/should not be applied);"

and in particular, whether some registrars use a creative
interpretation of "opt-in" to a process which registrants can't
opt-out of, except via a denial of service (which doesn't make it
"opt-in" at all).

What are the "costs" to the public vs. the benefits? These are real
costs in terms of inconveniencing real users.


B] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00329.html


On Fri, Jun 18, 2010 at 9:58 AM, Michael Collins <mc@xxxxxxxxxxxxxxxxx> wrote:
> Welcome to the IRTP group. There has been much discussion about this issue.
> I understand the frustration. I have personally been inconvenienced by this
> policy. As usual, there is a delicate balance between security and
> convenience. One thing that came up in discussions is that hijackers will

Thanks for the welcome. I've read all the discussion, and I don't
think it's been deep enough, as I'll detail once the official comment
period opens up. But, consider this a "preview" (in addition to what
I've posted elsewhere, e.g. on DomainState). Please note you've
acknowledged that there is a "balance" (i.e. cost and benefit), as
I'll refer to this below.

> often make a registrant change immediately before an inter-registrar
> transfer. This leaves the hijacking victim without the ability to use TDRP
> or our proposed ETRP to recover a hijacked domain name because they are not
> the registrant at the time of the inter-registrar transfer.

Yes, some hijackers do this. But, a *lot* of legitimate registrants
also change the WHOIS before moving the domain name. Remember,
registrants have an ICANN-mandated obligation to keep WHOIS accurate
at all times. Recall:

http://www.icann.org/en/announcements/advisory-10may02.htm

"3.7.7.2 A Registered Name Holder's willful provision of inaccurate or
unreliable information, its willful failure promptly to update
information provided to Registrar, or its failure to respond for over
fifteen calendar days to inquiries by Registrar concerning the
accuracy of contact details associated with the Registered Name
Holder's registration shall constitute a material breach of the
Registered Name Holder-registrar contract and be a basis for
cancellation of the Registered Name registration."

Notice there's a 15 day time period there (and keep an eye on words
below). Note that GoDaddy even offers a "Domain Transfer Validation
System", see:

http://www.godaddy.com/iPhone/Legal.aspx?document=DOMAIN_TRANSFER

to lock-down the so-called "at risk" "very valuable" domain names
(notice that even refers to a 5 business day period). As does VeriSign
through it's Registry Lock service (and 2-factor authentication), see:

http://www.icann.org/en/registries/rsep/

(2009005 and 2009004) So, all the "high value" domains *can* be
protected, right now. Let's repeat that -- there's no excuse for high
value domains to be at risk anymore. MarkMonitor has blogged about
this:

http://www.circleid.com/posts/domain_registry_locking_why_not_use_it/

Notice the lines in the WHOIS about "server transfer prohibited",
"server delete prohibited", etc. That's the signal. So, for example,
Facebook.com is not going anywhere, as it's protected via that service
(at MarkMonitor):

http://reports.internic.net/cgi/whois?whois_nic=facebook.com&type=domain

Same for Google.com, Yahoo.com. Other registrars are able to offer
this. (I can privately send you a list of some of my domains, that are
protected. I obviously own a multi-million dollar portfolio of elite
domains and websites, as most of you know --- if anyone should be
concerned about protecting their domains from hijacking, it's me.)
*That's* where the emphasis should be. Indeed, go back and read the
recommendations for *2005* on hijackings, which appear to not have
been read by everyone in this group (as some appear to be
rediscovering the wheel):

http://www.icann.org/en/announcements/hijacking-report-12jul05.pdf

Every solution was spoonfed to the public 5 years ago, but the report
just sat there. I'll just pick out a couple for now (there were a lot
more, but I don't want to flood the group -- I'll save that for my
formal comments later -- I had 30 pages of notes that need to be
condensed).

"5)     Consider measures to improve authentication and authorization used
in all registrar business processes, but especially in these sensitive
change processes:
i)      change of delegation information, ii)
changeofcontactdetails(credentials), iii) change of registrant
(selling the name), and iv) change of registrar. (page 36)"

"ICANN should publish additional consumer information that explains
the domain transfers policy and processes, and identifies the areas of
risk for a registrant. ICANN could provide a list of questions a
registrant can ask a registrar to determine the level of
authentication and protection mechanisms used to manage domain names.
(page 38)"

It's bad enough that one major report was overlooked. But, it's worse.
Take a look at the report from August 2009:

http://www.icann.org/en/committees/security/sac040.pdf

where once again, the solutions are spoonfed to everyone:

Registration verification.  (page 14)
Improve password-based authentication system.  (page 15)
Multi-factor authentication. (page 15)
Multiple, unique points of contact. (page 16)
Change notifications or confirmations. (page 17)
Multi-recipient notifications (page 17)
Multiple delivery methods for critical correspondence. (page 18)
Periodically verify contacts. (page 18)
Finding (4) Registrar services (and registrants) place greater
confidence on the single factor authentication for login to accounts
than the method merits.  (page 22)
Finding (7) Registration service providers rely more heavily on
unconfirmed email to deliver security-related correspondence (e.g.,
change notifications) than email delivery assurance and security
characteristics merit.  (page 23)
Recommendation (1) Registrars are encouraged to offer stronger levels
of protection against domain name registration service exploitation or
misuse for customers who want or need them.  (page 24)

It's all there! It's hilarious I have to join this group to point it
out. IT'S ALL THERE!

> A 60-day lock increases the opportunity for the registrar or victim to
> discover a hijacking before the domain can be transferred away. Despite the

How? Why 60 days? Why not 5 business days (the GoDaddy contract), not
15 days (the RAA requirements?). What do people think is going to
miraculously happen during those 60 days? Indeed, why do people need
to "discover" this by a miracle, by magic, etc., when the means exists
to *proactively* involve them, when the change is made? Consider:

http://gnso.icann.org/meetings/transcript-irtp-b-pdp-13oct09-en.pdf

"If they need to transfer then they should do the transfer first and
then make the change at the new registrar." (page 24, Tim Ruiz)

"But what normally happens is if someone does complain and we’re able
to do some separate confirmation or whatever their situation were
where we’ll let the domain name go." (page 25, Tim Ruiz)

So, complaining lets you trigger the "separate confirmation". It
*begs* the question, why doesn't that separate confirmation take place
*before* the registrant change? It's such an obvious question, one
that was basically spoonfed in not 1 but 2 ICANN reports. Why? Plus,
if the name was valuable, it could have had that stronger lock, in any
case.

Or, basically you can avoid the 60 day "lock" by changing at the new
registrar. That's considered the "best practice". But, under the ETRP,
it could be clawed back? No way.

> potential inconvenience to registrants, I thought we should consider making
> the lock mandatory for all registrars. My desire is to reduce sales of
> hijacked domains and I thought this might help. The majority of the group
> prefer leaving this and other security measures up to the registrar.

Now, go back to the earlier point you attempted about the "delicate
balance." If your only metric is to "reduce sales of hijacked domains"
and think this "might help", you need to think again.

(1) reducing sales of hijacked domains is an unbalaced metric. You
need to talk about that "balance". You could reduce sales of hijacked
domains quite easily --- just eliminate sales of ALL domains. That
would also completely eliminate sales of hijacked domains, too. If
that's the success metric, you'd have achieved a perfect result. But,
it's obviously a result with many unintended consequences and with a
lot of collateral damage.

(2) It "might help" compared to what? There are many alternatives,
spoonfed from 5 years ago. I could give you my email address
passwords, and you'd not be able to hijack my protected domains. Why?
Because I've done my job to protect my domains. Why aren't more
registrars and registrants doing this? That's what this workgroup
should have focused on, i.e. the education, implementing the
recommendations from 5 years ago, etc.

(3) The half-baked ETRP. Here's where I saw red. Folks had 5 years
with the answers sitting in front of them, and they come up with this?
Sheesh. I could write for ages on the effects on the secondary market
of creating uncertainty over title to a domain for 6 months. But,
let's focus on the mechanics of the ETRP.

The "old registrant" is going to make some sort of claim through their
old registrar that the domain was hijacked, to start the process.
Presumably, the registrar has to validate that request. Hello? This
demonstrates it's *possible* for the old registrar to *validate* the
request, possible for them to validate the domain transfer, change of
registrant, etc. Why are they doing this "AFTER THE FACT", instead of
*PROACTIVELY*, before the domain name is transferred, change of
registrant, etc. Hello???

I'm going to stop here, because I hope by now I've demonstrated my
point. I'm against domain hijackings and have helped numerous
registrants recover their domains. This is not the solution, but is
worse than existing solutions, and leads to unintended consequences
and collateral damage far greater than the actual problem (i.e. we can
go over how many unresolved domain hijackings occur; the problem is
small, and there are other emergency solutions, e.g. going to the
courts). The "delicate balance" is destroyed by the ETRP. The
proactive solutions were discussed years ago, and are already being
implemented. Those are far superior, and raise security for everyone.

Michael and I share a lot in common in terms of wanting to protect
registrants, so I hope he'll withdraw his support for the current
report, and rethink the issue. Same for other members of this
workgroup. It'll  save me the trouble of writing a 50 page "minority
report" comment, and make the summer easier for everyone, rather than
spend 6 months doing an "oops" and having to pull a 180-degree turn
about this ETRP. Everyone I've talked to about it sees the problems
immediately that ETRP would cause. If folks go back to the basic
questions that they thought they answered, this group would be steered
in a proper direction, in my opinion. Folks should not get emotionally
attached or "invested" in the current report, as in my opinion it
leads much to be desired, and frankly I'll lose a lot of respect for
folks who continue to support it after they've had an opportunity to
think more deeply about what the report stands for.

C] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00330.html

On Fri, Jun 18, 2010 at 10:10 AM, Matt Mansell
<matt.mansell@xxxxxxxxxxxxxxx> wrote:
> Whilst we like our friends at Go Daddy and fully understand why they do
> it,  this policy creates an effective monopoly of customers stuck in
> this loop they can't get out of.  ICANN has two remits, promoting
> competition and protecting security. I'm surprised such a level of
> anti-compete has been allowed to run for so long as what is essentially
> a breach of the transfer policy, albeit dodged with technicalities.

Agreed. I've stood up for GoDaddy, as they're generally one of the
"good guys", but not with this ETRP or hostage policy in the name of
"security." (or not doing enough to protect registrants and due
process in the URS under the IRT, as they likely know).

> I listened to a call from our support guys the other day (One of many
> I'm told) from a perfectly pleasant single domain owner who had wasted
> an afternoon trying to deal with her transfer to us. The end conclusion
> was quite literally that she was told only "Bob Parsons" could remove
> this 60 day lock despite her request to have it removed.

She was misinformed, if that's what she was told. I've had no problem
getting the GoDaddy 60-day lock waived in the past, because I know who
to "ask nicely." But, hey, why should I even have to ask? I don't like
to have to beg for "special treatment" -- it should be there for
everyone. Good security should be there for everyone (i.e. all the
proactive security measures, 2-factor, out-of-band notifications, that
people know about for 5 years, or even the VeriSign lock).

> I'm of the opinion that ICANN should take action against such a policy,
> at the very least to help the 99% of good consumers who are being caught
> up in this and locked to a registrar they don't want to be.

Just to show I'm also pragmatic, recall that there was some "debate"
when one of the registrars unilaterally locked all client domains (I
think it was around the time EPP codes were introduced, several years
ago). Was it NSI? I can't remember...in any event, I said to others,
Tucows should do the same! (that's my "home" registrar, where all my
domains eventually end up) Lock 'em all down (as long as it's easy to
get the EPP code, unlock, etc.). I think nearly every registrar did
just that. It was a one time event. That was a simple pragmatic step
that unilaterally raised everyone's security, with little if any
collateral damage.

D] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00331.html


http://twitter.com/wedschilde/status/16443332949

"thank you @godaddy. i appreciate your releasing threecrowpress. thank
you for calling back! and working w/ me."

How'd they do it? They *called back." So, telephone verification.
That's an "out of band" solution, oh, the kind that was talked about
*5 years ago* in that report (and long before that elsewhere, i.e. the
5 year old report wasn't inventing anything new that people didn't
know for years).

What was the "cost" --- VOIP outgoing calls, a couple of cents/minute?
It can be automated, using PIN codes when they first sign up for a
domain. Even less if you use SMS. If you want to involve humans,
$20/hr (might be high) can probably validate 10 or 20 people per hour.
Say 10, that's $2 more for the human validation.

If one built-in very proactive security from the beginning (i.e. what
the reports all suggested, not "reactive solutions"), the costs are
even lower.

E] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00333.html

The ITRP just had a conference call, and I was basically ganged up on
for pointing out all the flaws in the proposed ETRP (Expedited
Transfer Reverse Policy).

How will businesses and consumers be affected when folks can simply
undo a legitimate transfer "at will", without due process, within 6
months? How will an escrow work if the prior owner can simply claim
"hijacking" and undo a transfer, when it's simply a case of seller's
remorse? We see irrevocable transfers in the real estate industry, and
that market works fine, because people are *proactive* about security.
Here, the folks pushing for this flawed proposal seek to implement a
*reactive* policy that *will* be misused.

I'm totally appalled at how they want to create a huge loophole in
policy, that will have collateral damage which is much bigger than the
"problem" they're trying to solve.

A transcript of what went down should be available later at:

http://brussels38.icann.org/node/12502

To see why this policy is flawed, consider the following scenario:

1. Example.com is registered at GoDaddy, to Party A.
2. Party B agrees to buy the domain name for $1,000, and transfers it
to Tucows legitimately.
3. Party B builds up a large website, investing millions of dollars
(perhaps it was Microsoft, who has bought domain names like kin.com
and docs.com in the aftermarket, or B&N, who bought nook.com in the
secondary market).
4. 6 months later, Party A gets seller's remorse, and decided to
invoke the policy, claiming the domain name was hijacked, and the
domain name is returned immediately to GoDaddy (the original
registrar), under the full control of Party A again.
5. Tucows (the new registrar) and Party B can't do anything about it,
to dispute the use of this policy, as its currently proposed!

(there exists a "TDRP" Transfer Dispute Resolution Procedure in place
now that *does* have due process, but some folks seem to think it's
not good enough)

Fact: If there's a real dispute, one side is lying! It should be up to
a court to decide, not simply getting involved and undoing a
legitimate transfer! Remember, the original registrar (GoDaddy in the
example above) had every opportunity to authenticate Party A's desire
to transfer the domain name to Tucows (where Party B wants it to be)
BEFORE the domain name transfer took place! The domain could be
unlocked only after talking to Party A by phone first, for example. Or
some other "executive lock" procedure (VeriSign lock is just one
example of many). The EPP code could be sent by SMS, for example.
There are myriad ways to be proactive about security, and I'm 100% in
favour of those.

The workgroup pretends fraud exists only by "domain hijackers", and
seems incapable of seeing fraud within the community of domain
sellers. One need only look at the case of Nelson Brady and SnapNames,
to see what kinds of frauds are possible. It's bad enough when you
have to deal with that kind of fraud, but then to add a brand new
risk, of legitimate transfers being undone simply upon a *claim* of
hijacking??!!? (not *proof* or a court order or some other due
process)

I find it simply unreal that these serious concerns are not being
taken seriously, and are being brushed aside by this workgroup.

F] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00334.html

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.

G] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00346.html

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

H] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00349.html

Fraud by a buyer is easy for you to manage -- insist upon a wire
transfer. It's your choice to use credit cards or other risky forms of
payments. All registrants who are doing things properly shouldn't have
to suffer to subsidize your business model or credit practices (most
NameMedia marketplace names are owned by NameMedia, so their desire to
clawback names that have a chargeback are clear). We saw how the 5 day
add grace period was abused, too.

Fraud by a seller is also easy for you to manage -- you need to
properly authenticate the seller. In most cases, that is yourselves.
When it's not yourselves, there's the WHOIS (where there are accuracy
requirements). If you only use an email address to authenticate,
that's your business model's fault. If others are authenticating using
stronger methods, we shouldn't be penalized.

Given fraud can happen from both buyer and seller, what happens when
the seller commits fraud *after* a sale, by undoing it on a whim,
using the current ETRP proposal (where the allegation alone makes the
domain name come back to the prior registrar)? That ability to undo
without due process would put severely undermine the marketplace you
speak of. It creates a severe risk for the buyer that is impossible to
manage/hedge.

Why would I buy a domain name from NameMedia for $100,000, for
example, when 3 months later you can simply take it back without due
process? I'd have to discount the price to reflect that risk of a
clawback (and the resultant legal costs to undo the clawback), just
like merchants adjust their prices to reflect chargebacks by
consumers. Notice it's a definite devaluation of all domain names (for
both buyers and sellers, i.e. all registrants) --- not having clear
title to a domain name for a period of up to 6 months after a
registrant name change (if the ETRP exists) is always a liability, and
that liability reduces the value of the asset. Having the domain name
at an insecure/undesirable registrar for 60 days is also a liability
that reduces the value of the asset.

On Tue, Jul 6, 2010 at 12:34 PM, James M. Bladel <jbladel@xxxxxxxxxxx> wrote:
> Setting that aside, however, the primary issue that this group is
> wrestling with is the balance between Domain Security vs. Domain
> Portability.

Agreed, that's the primary issue. However, we disagree as to how to
achieve domain security. A 60-day lock/hostage situation is not the
way. Good security happens *before* the registrant change takes place,
and doesn't wait only until after a change.

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

If those "reasonable safeguards" were proactive, instead of reactive
(like the proposed ETRP), we would strongly support them. Recall,
there were multiple reports on this topic:

http://www.icann.org/en/announcements/hijacking-report-12jul05.pdf

https://st.icann.org/data/workspaces/irtp-partb/attachments/irtp_part_b:20090826085921-0-20170/original/sac040.pdf


which had many proactive measures that registrars and registrants can
use to ensure their security (e.g. out-of-band authentication, not
relying on emails for everything, etc.). All those recommendations and
best practices appear to have been ignored, with the ETRP presented as
some "magic bullet" that will solve a lot of problems. It won't --
it'll cause more problems than it solves.

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

Yes, we get attacked all the time, so I'm acutely aware of these
issues (and have helped others recover stolen domains). Some of my
domains are on VeriSign Lock, for example, as are elite domains like
Google.com, Facebook.com, etc. (as MarkMonitor has blogged about on
CircleID, and which I've previously discussed on this list). Those
domains aren't going to be hijacked unless there's an inside job by
the registrar in cooperation with VeriSign. I'll take my chances in
the courts if that happens. If these proposals were actually going to
*improve* my security, why would I be so against them?

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

Depending on the "urgency", a court can act much more swiftly to
return a hijacked domain name. I previously cited the example of
Microsoft taking down botnets with domains registered at multiple
registrars (some outside the USA). A newer example is where the US
Feds last wek shut down various websites/domains accused of movie
piracy:

http://www.nydailynews.com/news/national/2010/07/01/2010-07-01_feds_zap_bootleg_film_sites_in_sting.html


and some of those domains were at international registrars (e.g.
zml.com is at a Chinese registrar, Bizcn.com Inc.). Notice www.zml.com
says they went to US District Court for the Southern District of NY
(which presumably VeriSign accepted as a jurisdiction, even if it was
outside Virginia).

A court is much more likely to give due process than the current ETRP
proposal, and can act just as swiftly.

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

Both you and Bob, suggest this "60 day lock" is a good thing. What do
folks imagine is going to happen in that 60 days? Only a registrar
with poor authentication of requests would benefit from that 60 day
lock, to believe that it's of any benefit to security.

Let's imagine where it might be of use. Bad Registrar X has
example.com, and relies on very poor authentication to allows Bad Guy
to steal the domain, but keeps it at Registrar X due to a 60-day
"rule" after a registrant change. The innocent registrant (Good Guy)
notices the name is stolen, and contacts the registrar. He/she screams
a bit, jumps up and down, and is asked to present documentation to
authenticate their identity. Then the innocent registrant (once
authenticated) needs to convince Registrar X that the name was indeed
stolen. Bad Guy might disappear, in which case the job is easier. But,
what if Bad Guy disputes it, and denies it was stolen at all? Then,
it's a judgement call, with no set process --- basically willy-nilly
at each registrar. God forbid the Good Guy doesn't notice the name is
stolen in the first 60 days.

Suppose  that example.com was instead at Good Registrar Y, with strong
authentication. When Bad Guy tried to do an internal transfer
(registrant change) of the domain name from Good Guy, he fails
immediately! The domain name doesn't get stolen in the first place.
Why? Because Registrar Y did the proper checks *before* the registrant
change occurred. (Registrar X only did the proper checks *after* the
name was claimed to be stolen).

I want all registrars to be like Registrar Y. Registrar Y doesn't need
the ETRP, or the 60 day lock, because they did the checks properly
*before* the registrant change. What's there to dispute at that point?
Nothing. (or if there is, it's a decision best left to courts)

Why do registrars exist like Registrar X? Money, basically. Good
security, good design of systems, etc., costs money. Some registrars
cut corners in design and security. If a "good guy" registrant chose
to keep his valuable domain name at Registrar X in the first place, he
has himself partly to blame (and also the registrar, and also to ICANN
for not mandating higher minimum standards). He had the ability to
manage that risk (e.g. use one with Executive Lock, VeriSign registry
lock, etc.), but chose not to do so. If the domain name gets stolen,
the costs (e.g. legal costs) rightly fall upon him, for not doing
things properly in the first place (i.e.maybe he chose to save $2/yr
by going with a less secure registrar)

So, I leave these questions to Bob, James, and anyone else who wants
to join the debate:

(a) If we have properly authenticated registrant changes (i.e. like
Registrar Y), do we need the 60 day lock after a registrant change? If
so, what purpose does it serve? (besides holding the name hostage, and
perhaps allowing registrars to make an extra renewal fee margin 1/6th
of the time)

(b) If we have properly authenticated registrant changes (i.e. like
Registrar Y), do we need the ETRP as currently proposed? If so, what
purpose does it serve? (besides allowing reverse hijacking to take
place due to seller's remorse, or outright fraud by sellers who undo
legitimate transfers without any remorse)

(c) If I'm buying a valuable domain name, can you understand why I, as
a sophisticated and risk-averse registrant, want to move the domain
name away from "bad" Registrar X as soon as possible (i.e.
immediately!), and into good "Registrar Y"? How do I benefit
whatsoever from keeping my domain name even 1 day at a registrar I
don't want the domain name to be at?

(d) Would you support consumer choice in allowing registrants to
opt-in to Irrevocable Transfers, e.g. see:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00334.html

(i.e. this really should be the best practice in the status quo, where
transfer/change authentication is done properly *before* a
transfer/change). If not, why not?

I] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00357.html

Perhaps you should do more research into payment systems. Wire
transfers are considered the most secure form of payment.  See:

http://www.cdnpay.ca/publications/general_lvts_payments.asp
http://www.federalreserve.gov/paymentsystems/lowvaluepay/lowvaluepayments.pdf

and search the pages for the words "irrevocable" or "secure."
Escrow.com, for example, isn't going to accept a large payment unless
it's by wire transfer:

https://www.escrow.com/support/payment.asp

While it's *possible* in very obscure circumstances to recall a wire
transfer, it's definitely not guaranteed. And it's a lot more serious
to undo a wire transfer falsely.

If you truly believe that you can unconditionally recall a wire (or
even a cheque) 2 years later, feel free to wire me $100,000 (in
exchange for a low quality domain name, and we'd have a written
contract that is binding), and then try to undo it 2 years from now.
Let me pick a new bank, so I can guarantee that I close the account
the week after I've received the funds, too. :-)

>> Given fraud can happen from both buyer and seller, what happens when
>> the seller commits fraud *after* a sale, by undoing it on a whim,
>> using the current ETRP proposal
>
> The proposal to provide a *registrar* with the ability to "recall" a
> transfer isn't about fraudulent sales of domains - that's a change of
> *registrant* - it's about fraudulent transfers to another registrar which
> the registrar has to believe was done without the registrants consent.

For all intents and purposes, it's the old registrant who is recalling
it (why would a losing registrar not cooperate with their old client?)
with the registrar cooperating with them do initiate the command to
the registry. If there's no "change of registrant", then the
registrant has actual control of the domain at the new registrar! They
can just transfer it back, as there's no theft.

The change of registrant often happens around the same time as a
transfer. Read item (c) of this workgroup's charter. It's common for a
purchaser to want the domain to end up at their favourite registrar.
If the purchaser completes the deal by initiating a transfer to the
gaining registrar,  which is then accepted by the prior owner at the
losing registrar, the WHOIS at the new registrar will immediately
change to the purchaser when the transfer is complete. That
transaction will then be caught and affected by the ETRP proposal
(i.e. prior owner, at losing registrar, can invoke the transfer
reversal).

[If the purchaser does the change of registrant entirely at the old
registrar, with the desire to them move it to their favourite
registrar, then they'd have to deal with situations like that at
GoDaddy, where potentially the name is forced to stay there for 60
days, or more.......(ICANN hasn't said why *60 days* is magical, and
why one can't "opt-in" to a 50 year lock when presented with that
option by the old registrar) and subject to its own set of "risks"
(e.g. not being in a desirable legal jurisdiction, or being subject to
a registrar's ad-hoc procedures)]

>> not having clear title to a domain name for a period of up to
>> 6 months after
>
> My personal opinion is that 6 months is too long a window.
>
>> Depending on the "urgency", a court can act much more swiftly to
>> return a hijacked domain name.
>
> Or not as the sex.com debacle showed.

Mr. Kremen was compensated financially for his losses. Perhaps
NSI/VeriSign care to comment.

http://www.prnewswire.com/news-releases/sexcom-settles-monumental-case-against-verisignnetwork-solutions-72557542.html

http://www.circleid.com/posts/sexcom_settles_monumental_case_against_verisign_network_solutions/


That settlement, if registrars/registries were rational, should have
caused them to be more proactive about security. It should have been a
"teachable moment." But, I guess not, since the Panix.com incident was
*after* that. Let's go back to the report from 5 years ago:

http://www.icann.org/en/announcements/hijacking-report-12jul05.pdf

top of page 14 says:

"Such a mechanism would require a determination of what qualifies as
urgent, how to determine whether the allegation of fraud is valid, and
who is authorized to make this determination."

That language shows some balance. Contrast that with the proposed ETRP.

(a) ALL cases are considered "urgent" (i.e. absolutely zero
qualification is made)
(b) ALL allegations are considered "valid" (shoot first, ask questions later)
(c) ONLY the losing registrar (the one who had weak "security" to
begin with) is authorized to make the determination

Now, continue on page 14 (and, the rest of the document was also
prepared with great care and balance, unlike the workgroup report),
which notes:

"One means of dealing with the hijacking question would be to assign
the financial and legal risks associated with fraudulent hijacking to
the party most able to control the risk: the registrar closest to the
wrongdoer. Holding registrars accountable in this manner would create
incentives for registrar to take whatever steps are necessary to
prevent the occurrence of fraudulent hijackings."

That's really the "elephant in the room". Holding the registrars
responsible both financially and legally creates the proper
incentives. Why didn't the workgroup go down this route -- perhaps
because registrars/registries have so much voting power in the GSNO,
in contrast to lowly registrants? The ETRP? All the wrong incentives.

> And if the domain is moved to an "unhelpful" registrar (as the group is
> often referring back to certain unresponsive Far-East providers) do you
> really think even with a judgement, you'll be able to get it enforced ?

You don't move against the registrar, that's just dumb. You enforce it
with the registry (VeriSign), in the good old USA (realistically, most
hijackings of any importance occur in .com). The examples I provided
(Microsoft botnet, movie piracy) all involved foreign registrars that
were trumped by seeking an order from VeriSign. VeriSign might be able
to add some color and fill in the details? I could probably go into
PACER and download the relevant orders for "proof", though, but
perhaps Barbara can save me the 8 cents/page.

> Having to (rather than having the *option* to) go through the court method
> for a registrant to obtain their transferred domain back IMHO means you're
> restricting this to a very small subset of potential registrants - I firmly
> believe that *all* registrants should be taken care of, not just those with
> fatter cheque books.

You're suggesting once again that *all* cases are equal. That wasn't
what even the report from 5 years ago said about "require a
determination of what qualifies as urgent." Remember, the TDRP already
exists, and that has due process.

If you want all registrants to be "taken care of", the best way to do
that is to raise minimum standards at all registrars, taking the best
practices that were recommended in the past reports (which have mostly
been ignored; you know, 2-factor security, out-of-band
communications.....I sound like a broken record, perhaps, but I'll
keep repeating them until folks explain why those recommendations have
not been implemented, which proactively reduce hijackings).

Let me leave a couple of analogies. Suppose we had a world where
payment systems varied in their level of security, from the low
security of credit cards to the highest security of wire transfers.
The ETRP would be the equivalent of outlawing wire transfers, and
forcing everyone to only accept credit cards. What would be the
result? It would undermine the financial system, because folks would
no longer be able to rely upon the irrevocability of payments, and
would need to deal with credit risk in *every* transaction (i.e.
chargebacks, etc.). The ETRP would be permitting "domain clawbacks",
essentially, a new risk for those involved in the secondary market.
When ICANN mandates that all registrars *must only* accept credit
cards, and must cease using wire transfers, then it might be able to
make a case for the ETRP --- both policies would be equally dumb
(given the number of registrars that go out of compliance for not
paying their bills, perhaps ICANN needs to learn more about credit
risk....).

Here's the other analogy for the geeky crowd. Various operating
systems allow one to do 'dangerous' things from a shell or logged in
as root. Stuff like deleting all the fieles on your hard disk, for
example (rm -rf / ). The ETRP would be the equivalent of saying "no
one can use a shell, you shall all only use a file manager." (or, "you
shall all switch to Mac, and further use of Windows is not permitted")
For some (or even a large class of) users, these kinds of broads
restrictions would cause real damage. If you want to be a nanny to a
certain class of users (who in a competitive system certainly have the
incentives and ability to choose secure registrars, if security is
important to them), you shouldn't do so at the expense of another
class of users who need certain functionality (the functionality in
the domain name transfer system being the irrevocability, or at least
due process like the TDRP offers). For those who know what they're
doing, we should be able to continue, e.g. with a parallel
"irrevocable transfer procedure" as per:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00334.html

without suffering the economic damage that would be felt by those
caught by the policy.

************ IMPORTANT BELOW ***************

When all is said and done, if you want to solve the domain name
hijacking issue, it's simple. Go to section 3.3 of the Workgroup
report's Annex C, where it says (page 51):

"3.3 PTRa must obtain an ETRP Authorization from the Registrant to
initiate a ETRP."

To solve the domain name hijacking issue, all you need to do is
require that registrant changes and outgoing transfers have the
identical standard! (of course, one also needs to look at section 3.4,
including 3.4.2, to say the form of that authorization) Instead of
wasting everyone's time on a *clawback* procedure, that can and will
be *misused*, why not focus on the actual problem, authenticating the
real transfers and registrant changes? That's the other "elephant in
the room."

If *that* had been the focus of the workgroup, it would be on the
right track, and I wouldn't be here. I'd be applauding the report,
instead of picking it apart.

J] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00363.html

There *is* an interaction between various issues, so one can't simply
treat them as separate. For example, just to pull an unrelated
example, why would I care about new TLD pricing (e.g. when they tried
to eliminate price caps on biz/info/org, and continue to try to do
that in DAGv4)? I don't plan to register any new TLD domains, as
they're garbage. I do care, though, because there's the "equal
treatment" clauses in the .com agreement, so if something happens in
.shop, it suddenly has an impact on me in .com. Or, to pick another
issue, how so many things regarding abuse policies, etc., interact
with WHOIS policies.

> The group's report states; "The WG agrees that there should be a mechanism
> to dispute an ETRP but has not reached agreement on how such a mechanism
> might work." Please continue to encourage the WG to include a dispute
> provision and even help to design it. However, we should discuss item C
> without using an incomplete ETRP as the primary basis for your position. If
> you remove it from your example, the effect of a 60 lock do not seem so
> onerous. One could, as GoDaddy suggests, transfer the domain to a preferred
> registrar before a registrant change.

(1) I didn't just read and rely upon the report, I read *all* public
discussions and transcripts related to the workgroup (unfortunately
for the public, much discussion on the ETRP was closed off in private
sub-groups). When you have folks saying stuff like:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00285.html

"In short, I think we should consider going forward with an alternate
version that doesn't include a means to dispute the ETRP.  I say this
with full acknowledgment to the problems that Michael, Kevin, Barbara
and others have identified, and the efforts of the Working Group to
address them.  But the "ETRP Dispute" contains some fundamental flaws
that could derail our entire proposal."

or

http://gnso.icann.org/meetings/transcript-irtp-b-27apr10-en.pdf

"Good points Mikey and Marika. I would agree with one qualifier is
that I think that when initial reports are released they do tend to
take on a certain degree of inertia. And while they do change between
the initial and the final I think that they probably are 80% of the
recommendations are contained in one (unintelligible) other. (page 5)"

and combine that with the enormous lethargy that I've seen in this
group to date, it raises alarm bells.

(2) The 60-day lock *is* onerous, on its own. And not just to me, but
to others (see the links I've posted in prior messages). On special
request, one can avoid it, but one shouldn't *have* to beg for that
special request -- it should be (and my opinion is) a fundamental
right. The registrar should be doing the proper checks *before* the
registrant change takes place. This was one of the 4 questions I asked
at the bottom of:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00349.html

(i.e. see (a) there) I'll repeat it here. Why is the 60 day lock
required, if the registrar is properly authenticating registrant
changes (as they should already be doing!)?

(3) The "best practice" of transferring to a preferred registrar
*before* the registrar change is thwarted by the ETRP, i.e. a direct
interaction between the policies. At least under the status quo, I can
"route around the damage" of the 60-day lock by making a smart choice
as how to effect the change of registrant. I wouldn't be able to route
around the damage anymore.

> If the group moves away from creating an ETRP dispute mechanism that it
> agrees is needed, then I support your argument of the combined effects of
> these decisions. For now, I would prefer you help create an acceptable
> dispute provision. It is not an easy task!

Why invest hundreds or thousands of hours in a bad idea, trying to
"polish the turd" so to speak? One shouldn't become emotionally
attached to the ETRP, and instead focus on the *real* issue, which is:

REAL ISSUE: How do we effect a secure change of registrant/registrar?

That's the fundamental issue. See the bottom of my prior post at:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00357.html

where I wrote ******IMPORTANT BELOW*****. Isn't it hilarious that the
WG would spend time tryign to answer "how do we make sure that the
ETRP is of a proper form, and authorized" when whatever it came up
with could just be applied directly to the *fundamental issue*, i.e.
making sure that registrant changes and registrar transfers are of the
proper form and authorized?? I'm sitting here dumbfounded as I type
this ---- what is everyone else in the workgroup thinking???!!!!???
Why take a circuitous route and develop the world's most secure
process for authorizing and authenticating an ETRP request, when
instead one could just focus on the actual problem directly?

> You bring up one point that causes me to rethink our decision about item C.
> What is to prevent a registrar from using a lock longer than 60 days? A 60
> day lock does not seem onerous to me, but a 360 day lock might be. I doubt
> that a 50-year lock would fly with compliance, but I am not sure of that. In
> light of this concern, should we reconsider prohibiting a lock when there is
> a registrant change, specifying an appropriate lock period or even requiring
> a 60-day lock for all registrars?

I'm glad to see you're coming around. Hopefully others begin to feel
uncomfortable with the ramifications of ICANN's current
interpretation, because it would lead to bad places.

**** IMPORTANT BELOW **** COULD BE PUT INTO NEW THREAD******
I believe another route to attack ICANN's current interpretation is
via the word "voluntarily" in the transfer policy, i.e. it says:

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

(emphasis added for "voluntarily")

There are various definitions of "voluntarily" or "voluntary", but I
think the most apt one is #7 at:

http://www.merriam-webster.com/dictionary/voluntarily
http://www.merriam-webster.com/dictionary/voluntary

"acting or done of one's own free will without valuable consideration
or legal obligation"

I believe that destroys GoDaddy and ICANN's interpretation, because
one simply *cannot* opt-in via a *binding legal contract* to something
that is *voluntary*. I ask that ICANN's compliance take another look
at this. If something is truly voluntary, the "express written
objection" can be revoked at *any time* and is thus not permanent or
binding in any way legally (perhaps I should start a new thread on
this, just this focused legal language for ICANN's consideration?).
**** IMPORTANT ABOVE **** COULD BE PUT INTO NEW THREAD******

When I'm reading the contracts/policies, etc. I'm always looking to
see what the loopholes are, as I expect that someone will try to
exploit them (that's why price caps were so important, because
otherwise it would have led to .tv style tiered pricing; simply
removing all references to prices created a loophole). In this case,
ICANN suggesting that registrants could "opt-out" of a fundamental
right (the fundamental right being the right to transfer to one's
registrar of choice at any time past the first 60 days measured from
creation date) would create a brand new loophole that more malevolent
registrars could exploit and abuse (i.e. far worse than what GD is
currently doing), thereby hurting registrants.

The funny thing is, on request GD will waive the 60-day lock, and
folks like myself have never been denied that request. Even the guy I
wrote about last month who was whining on Twitter about
threecrowpress.com was able to get his transfer done:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00331.html
http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00326.html

So, GoDaddy can be reasonable (even though I might appear to be
"picking on them" sometimes, they're big enough to take it, I'm sure;
it's not like I have any power over them; they're much larger
financially). So the question for GoDaddy, or anyone else is the same
as I asked yesterday at the bottom of:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00349.html

(a) If we have properly authenticated registrant changes (i.e. like
Registrar Y), do we need the 60 day lock after a registrant change? If
so, what purpose does it serve? (besides holding the name hostage, and
perhaps allowing registrars to make an extra renewal fee margin 1/6th
of the time)

(and all the rest) Those should be simple, straightforward
questions.....the silence is deafening. In even more direct terms, if
"special" folks have been able to get the 60-day lock waived at
GoDaddy, why isn't *everyone* special? Here are 2 answers that I would
*expect* that they (or other registrars) might reply with (and I'm
sure James or Tim will jump in to correct me, but might not feel brave
enough to simply answer directly):

(i) "It would cost too much time/money! It would cut into margins to
"do security right" for *everyone*, or it would raise prices." This
would be a useful answer, as it least it would lead to avenues of
discussion like: What are the actual costs? Can some folks opt-in to
pay those higher costs directly (i.e. like my irrevocable transfer
policy proposal)? Should ICANN have minimum standards/expectations of
registrars? Should business models be supported that "cut corners" (or
is that the root of hijacking to begin with?)? What can
ICANN/registries/registrars do to lower actual costs for everyone?
etc.

(ii) "We don't believe fraud was involved in your registrant change so
we let the name go." Recall from the transfer policy:

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

the first reason for a denial is "evidence of fraud." Deconstructing
this answer, what it would really reveal is a "60 day hold" is in
reality being used as a weak test for fraud. This goes back around to
(i), though, i.e. what test did you use because I was "special", to
know fraud wasn't involved, and that it was a legitimate transfer, and
why can't you do the same for everyone" --- money!

(iii) No one has yet raised the "voluntary" issue before (see above),
and we don't want ICANN to quash our current interpretation of the
"opt-in" procedure.

Anyhow, I hope some of the above gets the mental juices flowing.....

K] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00367.html

In November 2009, David Giza of ICANN provided an interpretation of
the GoDaddy 60-day lock after a registrant change which has been
suggested to be "opt-in". This was posted to the IRTP-B working group
at the bottom at:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00345.html

recently, and led to some discussions. I believe this interpretation
needs to be looked at again, as it did not appear to fully consider
the meaning of "voluntarily" in the language of the transfers policy.
See below for points pulled from that prior thread (with a few
editorial changes and cleanup):

I believe another route to attack ICANN's current interpretation is
via the word "voluntarily" in the transfer policy, i.e. it says:

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

(emphasis added for "voluntarily")

There are various definitions of "voluntarily" or "voluntary", but I
think the most apt one is #7 at:

http://www.merriam-webster.com/dictionary/voluntarily
http://www.merriam-webster.com/dictionary/voluntary

"acting or done of one's own free will ***without valuable
consideration or legal obligation***"

*** = emphasis added

I believe that conflicts with GoDaddy and ICANN's interpretation,
because one simply *cannot* opt-in via a *binding legal contract* to
something that is *voluntary*. I ask that ICANN's compliance take
another look at this. If something is truly voluntary, the "express
written objection" can be revoked at *any time* and is thus not
permanent or binding in any way legally.

I think this point warrants further examination by ICANN and this
workgroup, to clarify exactly what can or cannot be "opted-in" to,
i.e. what is a minimum standard, what are a registrant's inalienable
rights?

One can see further discussion on these latter points in the posts at:

http://forum.icann.org/lists/gnso-irtp-b-jun09/

in the "60 day lock following registrant change" thread, in particular:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00346.html
http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00360.html

Can, for example, a registrant "opt-in" to a binding and irreversible
360 day lock or a 50-year lock that *cannot be undone* at a later
date? If so, how would that be "voluntary"?

L] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00370.html

> take a look at my little drawing...  that's what i'm basing all this stuff 
> on...

I appreciate that Mikey put a lot of effort into this, however it's
beginning to resemble an Escher painting.

I don't have the tools to edit the drawing, but here's what one might do:

(1) Take the little box in the 2nd column which says "Verify Identity
of Losing Registrant" and put it on a blank page.

(2) Put an arrow next to it, and connect it to the box in the bottom
right of the picture which says "Finalize Transfer".

That's it. 2 boxes, instead of *14*!

I certainly think most folks would prefer the elegance and simplicity
of my picture of the domain transfer world, rather than the vision
that has evolved to date in this workgroup. But, feel free to explain
what's "wrong" with the 2-boxes picture. I'd really love to know.

Remember the K.I.S.S. principle!

http://en.wikipedia.org/wiki/KISS_principle

M] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00371.html

As I had a question from someone off list, the following additional
details might help ICANN (and the working group) in their analysis.

In my post I reference the definition of "voluntary"

"acting or done of one's own free will ***without valuable
consideration or legal obligation***"

Note the latter part, which is really referencing an agreement or
*contract.* (i.e. what GoDaddy is relying upon to *bind* someone, i.e.
not making it voluntary)

And here's the "smoking gun" that goes directly to that issue which
was in a transcript from 2009 (where GoDaddy was trying to explain the
policy):

http://syd.icann.org/files/meetings/sydney2009/transcript-irtp-b-brainstorming-session-21jun09-en.pdf


"And so, one thing is we want to make sure that we have a registration
agreement in place with the new registrant. So, we have a process that
you go through if you're going to do that, that both the losing
registrant and the gaining registrant is made aware of the fact that
this is a service that we're going to provide to you. We provide it
free under the condition that once completed, the domain name, you
agree that you won't transfer the domain name for 60 days.
And then we explain if that's not going to work for you, the option is
transfer the domain name first and then complete the change of
ownership at the new registrar. And so, if they complete the process,
they've been fully informed and then the domain name is held locked
for 60 days."
" (page 18, Tim Ruiz)

Note words like:

"a service we're going to provide to you" = legal consideration
"under the condition"
"you agree"

And also what the alternative is "if that's not going to work for you"
-- transfer it elsewhere. So, it's a classic "take it or leave it"
contract of adhesion, not negotiable by two equal parties. The promise
not to transfer is an integral part of the binding agreement, and is
not some "voluntary" after thought.

In other words, one simply can't do the registrant change at GoDaddy
unless you also supposedly "opt-in" "voluntarily" to their 60-day
lock. That's clearly not "voluntary" under the definition of the word
above. There's both valuable consideration and a *legal obligation*
attached to the agreement to the 60-day lock, which means it's not
voluntary.

N] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00378.html

On the point of "urgency", the report itself (pages 38 and 39)
documented that stolen domains / hijackings ranked TENTH in importance
in ICANN complaints related to transfers. When the data itself is
arguing this should be a low priority workgroup, I fail to understand
the urgency some are placing on it. If another workgroup needs to be
started in the IRTP series, and this one put in the freezer, one would
see no opposition from me on that point.

O] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00384.html

I've started a new thread) This workgroup, though, is meant to
address cases that *don't* get resolved. If all these cases are
getting resolved, how are they relevant? And even if they weren't
resolved, please quantify "many". Is it 1 million domain hijackings
per year? 5 million? 100,000? How is one supposed to weigh the
positive and negative impacts, without those numbers from registrars,
registrants, etc? Personally, I'd like to see it broken down by
registrar --- which registrars are "vaults" and which ones are
"leaking sieves"? It would probably be very educational, and would
greatly inform this workgroup.

Last week Marika reposted the issues report from last year:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00362.html

Those same kinds of "qualifiers", looking for the data to weigh
policies, were present *in* that report, but seem to have been ignored
by the workgroup's preliminary report:

"Some of the questions that might need further consideration in a
potential policy development process include determining the extent of
the problem and whether it warrants a new policy or policy change"
(page 17)

"determining the extent of the problem" cries out for hard *data*, not
just anecdotal evidence.

"Urgency" (and qualifying it) is also hinted at:

"The circumstances which distinguish when an urgent recovery policy
may be a more appropriate action than the TDRP include:
1)      Immediacy of the harm to the registrant if the transfer is not
reversed (e.g., business interruption, security incidents).
2)      Magnitude of the harm, or the extent to which the incident
threatens the security and stability of parties other than the
registrant, including but not limited to users, business partners,
customers, and subscribers of a registrant’s services.
3)      Escalating impact, or the extent to which a delay in reversing the
transfer (and DNS configuration) would cause more serious and
widespread incidents.
The emergency action procedures should be tested to verify they are
resilient to tampering and difficult to exploit. In particular, it
should be difficult or impossible for an attacker to effect a hijack
or interfere with a transfer under the guise of requesting urgent
restoration of a domain." (page 17)

They got it right last year, i.e. "magnitude of the harm", "immediacy
of the harm" all suggest tests to *limit* the procedure, to qualify it
to very narrow circumstances, unlike the ETRP which could be invoked
(as presently proposed) on a whim by any registrant for any domain
simply through a *claim* which could be a lie (irregardless of whether
it's a real "emergency" or not). Furthermore the workgroup did little
to make sure that the ETRP is "difficult to exploit", i.e. "it should
be difficult or impossible for an attacker to effect a hijack or
interfere with a transfer under the *GUISE* of requesting urgent
restoration of a domain."

So, folks were *aware* of the potential for this reverse hijacking
issue, i.e. clawbacks.

Can you now understand why it makes me angry that I even had to join
this workgroup, when it could have dealt with this issue in the
preliminary report, simply following up on that stuff from last year?
But no....instead I read statements like:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00285.html

"In short, I think we should consider going forward with an alternate
version that doesn't include a means to dispute the ETRP.  I say this
with full acknowledgment to the problems that Michael, Kevin, Barbara
and others have identified, and the efforts of the Working Group to
address them.  But the "ETRP Dispute" contains some fundamental flaws
that could derail our entire proposal."

(and one can re-read the entire message, to see if I "pulled it out of
context") How can one reconcile the issues report with the "rush to
push through a half-baked policy", and cut off public input to boot?
That's why I felt compelled to join this workgroup, albeit as a
"second class citizen" in some people's eyes.

So, I'll leave with one question, which should have been asked a long time ago:

(1) Where are all the detailed domain name hijacking statistics?

This goes to the question A of this charter, i.e. "Whether a process
for urgent return/resolution of a domain name should be developed". To
pass that question, it wouldn't be enough to have just the stats,
though. One would also need to demonstrate that no superior process
exists (e.g. court system, choice of a secure registrar to begin with
by the registrant, choice of other security policies that are
proactive rather than reactive, having registrars be held legally
responsible for damages, and other alternative policy choices).

P] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00387.html

According to:

http://www.dnsnews.me/2010/07/14/icann-lose-more-staff---head-of-compliance-le/

David Giza is no longer with ICANN. I'm forwarding the issue re: the
impact of the word "voluntarily" to Pam Little instead, for an
interpretation of the 60-day lock upon registrant change issue.

For Ms. Little: see:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00367.html
http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00371.html

Q] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00395.html

I think before you can define "Change of Registrant", one would need
to fully and carefully define what a *registrant* is first. And it's
not as simple as it might seem, as it would need to capture various
scenarios.

For example, suppose an individual does a legal name change from:
"Jane Smith" to "Jane Doe." The registrant has not "changed", but the
displayed identity has been updated. Same as when a company renames
itself, or even changes its domicile or does an amalgamation.

A little bit more complicated might be when a domain name is held in
escrow by an attorney (e.g. if there's a domain name leasing
arrangement, court process, etc.). If the displayed WHOIS goes from
"Acme Inc." to "Mary Adams, Esq. in Trust" for 5 months, "Acme Inc."
might still be the "true registrant." If the prospective buyer
defaulted, and the displayed WHOIS returns to "Acme Inc.", there
really hasn't been *2 registrant* changes at all....there's also been
a single true registrant with full ownership of the domain name (i.e.
transfer of title never took place to either Mary Adams or the
prospective buyer).

With various proxy services out there too, it becomes complicated. And
there are probably some other scenarios out there that would need to
be encompassed by a definition.

R] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00396.html

This was *explicitly* in the issues report from last year, as I
mentioned yesterday, that being "suspected" is not enough:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00362.html

"The emergency action procedures should be tested to verify they are
resilient to tampering and difficult to exploit. In particular, it
should be difficult or impossible for an attacker to effect a hijack
or interfere with a transfer under the guise of requesting urgent
restoration of a domain." (page 17)

> That only works *if* the gaining registrar agrees, and some of those that
> "aid" in fraudulent transfers are unlikely to do so.

The gaining registrar might have superior information, to know that
it's just not a "fraudulent transfer" that needs to be undone.  Maybe
the gaining registrar is the actual registrant, for example, or has
received proper documentation from the actual registrant (which the
losing registrar for whatever reason doesn't accept). How many times
does one see false/unsupported allegations in UDRPs, or DMCAs, or
other kinds of complaints? As the above language from the issues
report stated, "it should be difficult or impossible for an attacker
to effect a hijack
or interfere with a transfer under the guise of requesting urgent
restoration of a domain." That "attacker" could be the prior
registrant, for example.

Stepping back, as discussed numerous times, the superior solution is
to make sure that proper authorizations/verifications take place
proactively, before the change is "committed" to the registry. The
losing registrar could and should have done so before allowing the
WHOIS to update, before allowing a domain lock to be removed, and
before releasing the auth_info code.

>> [If the purchaser does the change of registrant entirely at the old
>> registrar, with the desire to them move it to their favourite
>> registrar, then they'd have to deal with situations like that at
>> GoDaddy, where potentially the name is forced to stay there for 60
>> days
>
> Based on your earlier arguments, surely that would be a-good-thing(tm)...

Being stuck at a registrar you don't want to be at? I don't think
that's a "good thing(tm) at all.

> Registrants get fooled by this process used by domain-scum-of-(location),
> and at the point of handing over such details, lose control over/services
> for their domain as a direct result of being "conned" by a "sales-technique"
> which is a criminal offence in UK law.
>
> That is a very real problem, and not one of "security" at the losing
> registrar, but one of sad-but-true stupidity of the registrant.

People sign "bad deals" all the time, and need to take responsibility
for their own actions. If the transfer followed the "letter of the
process", then it should be left to the legal system (police, courts,
etc.) to determine if it's fraud. By all means, improve the "letter of
the process", but at some point "what's done is done" within the
registration system itself, and one must go to an outside authority to
deal with legal disputes.

Furthermore, that still is the case of "security" at the losing
registrar. If the domain was under VeriSign lock, for example (and not
all registrars offer it, i.e. differences in security standards at
different registrars), handing over their account details to an
attacker is not going to be enough to steal the domain name....the
losing registrar would have other out-of-band procedures in place to
contact the registrant, to be very sure about whether they want to get
the name removed from their "special" or "executive" lock. This
out-of-band security can happen even at any registrar, regardless of
whether they use VeriSign lock, by the way. For example,
Fabulous.com's "Executive Lock"

http://domainnamewire.com/2008/12/11/fabulous-executive-lock-would-have-saved-checkfreecom/


where one can have a registrant-defined procedure for changes.

e.g. I might make the procedure be......

(1) phone me up, and ask me 7 questions where only I and the current
registrar know the answer, AND
(2) also ask me to recite a poem that the registrar faxes to a preset
telephone number in Greek AND
(3) also ask me to go on Cisco TelePresence video conferencing and
show a birthmark live on the video chat, while rubbing my tummy in a
circular motion and patting my head at the same time, while hopping on
one foot
(4) AND also give a proper RSA SecurID code during the video
conference while displaying my authenticator in real-time
(5) AND also fly to my head office and physically transfer HALF the
auth-info code to me in a sealed envelope
(6) AND do all the previous things for a 2nd person at my company!

(my soon-to-be-patented procedure for .bank changes) ;-) (well, not
really, but I would suggest parts of #3, #4, #5  and #6 for a .bank,
if I ran it, amongst other things; feel free to use the above ideas to
strengthen all registrations, though)

>> That's really the "elephant in the room". Holding the registrars
>> responsible both financially and legally creates the proper
>> incentives
>
> I've never heard of a completed transfer which didn't follow the procedures
> of the registrars concerned, so what are you expecting to hold them
> accountable for ?

Maybe you've not heard of cases like Baidu and Register.com, where the
employee of the registrar allegedly was duped into making the WHOIS
changes by the attacker.

http://www.betanews.com/article/Baidu-Registercom-replaced-its-DNS-credentials-for-some-guy-in-a-chat-room/1267124527


"Supposedly, he pretended to be Baidu ("Mr. Baidu," perhaps?). And
although records show the support personnel asked him to verify his
identity by sending back the security code that was just sent to the
e-mail address on record as Baidu's authoritative address, the fellow
instead responded with a made-up bunch of numbers...which the agent
then accepted as valid."

"Incredibly, Defendant [Register.com] thus changed the e-mail address
on file from one that was clearly a business address and contained the
name of the account owner, to an e-mail address that conveyed a highly
politically charged message ("antiwahabi"), with the domain name
("gmail.com") of a competitor of Baidu, at the request of an
individual who not only could not produce the correct security
verification, but actually produced false information twice during the
verification process."

Now, that didn't end up being a transfer to a different registrar, but
it could just as easily have been (since the attacker had de facto
control of the domain).

By holding the relevant registrar legally accountable, it's not just
for following their own "procedures", but for doing proper
verification/authentication at all times. e.g. if the losing
registrar's stated procedure is to flash the "auth info" code on the
Jumbotron at Yankee Stadium, should there be any surprise that an
attacker uses that "auth info" to hijack the domain name? If the
"verification" that a registrar does when validating a request to
unlock a domain constitutes flipping a coin and seeing if it's
"heads", that's not good enough either.

Suppose the registrar only offers authentication by email, for
example, and the registrant's email address is hijacked. If the
registrar is *still* held legally accountable for a theft (despite
following all their "procedures"), then that registrar will quickly
either (1) go out of business or (2) be compelled to upgrade their
systems. The proper economic incentives are in place for upgraded
security across the system, because the financial liability is placed
squarely on the parties most capable of improving overall security.

S] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00399.html

Following that logic, one also shouldn't be tailoring "policy" to the
*least* security-conscious registrants, those who are posting their
registrant username/password directly on their Facebook page with a
note "please steal my domain name" and then later want to undo their
domain name transfer because the name was "stolen" via some emergency
procedure.

UDRP isn't "free", by the way. That's an example of a policy option
that isn't open to the "poor" or those who don't wish to pay
anything....respondents also pay a "premium" if they want a 3-person
panel.

So, I'm not sure what you're arguing....is it that a "one-size fits
all" policy can exist that is going to make everyone happy?? Or that
registrars should be encouraged to have the lowest possible level of
security....and that should be incentivized through bad policy?

Here's a simple fact: not all domains are equal! This was explicit in
the issues report of last year, as I pointed out on Tuesday when I
wrote about "urgency" in a new thread:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00384.html

Note how "magntitude of the harm" was explicitly put into that report.
Magnitude of the harm recognizes that there's differences in economics
of registrants, and that one should not write a policy that is
intended for *all* domain hijackings. Some hijackings are more
important than others. If a claimed "emergency" is affecting Yahoo.com
and jkghkjhsjkhg.org (a random worthless domain), any policy for
"emergencies" might only be applicable for the first domain name, and
not the second. If some folks are unwilling to accept that, then
perhaps that's why this workgroup has been going in the wrong
direction.

Let me put it another way. A fire happens at a hospital, and at an
empty house. Is it any surprise when the single fire truck has to make
a choice of only helping one, it goes to the hospital (and lets the
empty house burn down)? The magnitudes of the harm differed greatly.
And the owner of the empty house could have invested in a sprinkler
system (but chose not to do so). As another example, if your "damages"
don't exceed a certain level (say $10,000), the FBI isn't going to
look at your case....that's an explicit realization that economics
*must* be used to prioritize policies.

The VeriSign/Neustar locks are just one option of high
security....registrars differ in the security choices they offer their
customers. Those customers explicitly consider security when they pick
a registrar. One (albeit unscientific) survey ranked security as the
2nd most important factor (behind price):

http://domainnamewire.com/2010/02/08/survey-price-security-most-important-when-choosing-domain-registrar/


with security being the #1 factor for large domain name holders (who
are presumably more sophisticated).

So, suppose that security is heterogeneous across registrars. Are we
supposed to ignore that consumers made an actual choice in their
registrar, in the level of security they wanted for a certain domain
name? As above, in creating a policy for emergencies, just as the
issues report discussed last year, isn't it supposed to be qualified
to only those situations where the magnitude of the harm is great?

T] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00401.html

My point was that simply renaming a person or a company does not
actually change the registrant. It's the exact same human being, for
example, in the case of a name change of an individual. So while the
WHOIS has updated the "Registrant" field from "Jane Smith" to "Jane
Doe", it's the EXACT SAME REGISTRANT. This was my point that one needs
to be careful about how one defines a registrant, because the "label"
one attaches to a certain registrant might change, but it's *not*
considered a change of registrant.

> If the domain is held in escrow or whatever then one would assume that there 
> is some sort of paper trail for this
>
> Whois is only part of the system - it's just the easiest bit to talk about ..

Agreed, that's why I said above, just looking at WHOIS changes doesn't
tell the entire story, at least under the current WHOIS. If one wanted
to bring in a policy that explicitly recognized a "Change of
Registrant", then there would probably need to be a specific piece of
data in the WHOIS like:

Date of Last Change of Registrant: June 1, 2010

which would capture things explicitly. Then when "Jane Smith" changes
her name on July 15, 2010 to "Jane Doe" and updates the WHOIS, the
field above would *not* change, but would remain as June 1, 2010.

>> With various proxy services out there too, it becomes complicated. And
>> there are probably some other scenarios out there that would need to
>> be encompassed by a definition.
>
> Irrelevant
>
> The registrar would have the real contact details

Spoken just like some registrars, who consider input by the public as
"irrelevant." However, it is relevant, because one might want
independent validation of a certain assertion by a registrar. Some
transparency would help. Not all registrars tell the truth. Some might
even lie and revise history.

Suppose a proxy service exists at a certain registrar, for example. A
domain is created, example.com, on May 1, 2000, and the true
registrant ("John Smith") is hidden behind a proxy service's WHOIS
("Acme Registrar Privacy Service"). On June 1, 2004, the TM "Example"
is registered in the class of widgets by some 3rd party, and becomes
very valuable, with lots of traffic to example.com. On September 1,
2008, the registrar decides they want to buy the name from the true
registrant, for their own account. They do so. THE REGISTRANT HAS
CHANGED, BUT THE WHOIS HAS NOT. If there's deemed to be a "change of
registrant", though, the new owner would be at risk, because they
would have lost their "priority date" relative to that registered
trademark (i.e. the domain name might be considered to have been
registered *AFTER* the trademark, because of the change of
registrant). The incentive would obviously exist for the registrar to
lie and revise history, especially if they could avoid being caught.

If you want to see examples of the extent of the "creativity", for
lack of a better word, to which registrars will go, they're not hard
to find. Just look up "Standard Tactics LLC", for example:

http://domainnamewire.com/2008/12/03/standard-tactics-llc-how-godaddy-profits-from-expired-domains/

http://techcrunch.com/2008/12/18/godaddy-moves-to-close-shady-standard-tactics-subsidiary/


Even more "educational" is to search for "Standard Tactics" at WIPO or NAF:

http://domains.adrforum.com/domains/decisions/756892.htm
http://domains.adrforum.com/domains/decisions/820358.htm
http://www.wipo.int/amc/en/domains/decisions/html/2006/d2006-0164.html
http://www.wipo.int/amc/en/domains/decisions/html/2009/d2009-1632.html

especially considering the DAGv4 says:

http://www.thedomains.com/2010/06/01/will-a-domainer-who-lost-a-few-udrps-be-barred-from-owning-or-being-involved-with-a-new-gtld/


"Is the subject of a pattern of of decision indicating liability for
or repeated  practice of bad faith by acquiring domain names for the
primary purpose of selling, renting or otherwise transferring domain
name registrations to trademark or service mark holders or to a
competitor for valuable consideration in excess of documented out of
pocket costs."

We're living in interesting times, folks.

U] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00403.html

Yet, you replied nonetheless. ;-) Let me give a less extreme example,
if that would make you happy. Suppose Bill owns example.com, and has a
choice of registrars to use. He picks "Leaky Sieve Registrar" that
send usernames/passwords in cleartext on demand via email 100% of the
time, instead of "Vault Registrar" that offers a higher level of
security, perhaps resetting passwords only after a telephone
verification, SMS, etc. Perhaps "Leaky Sieve" charges $10/yr for
domains versus $12/yr at "Vault Registrar."

Policy needs to take into account that these choices do exist in the
marketplace. Charter Question A demands that this be taken into
account, because it's an explicit alternative. "Whether a process for
urgent return/resolution of a domain name should be developed." If a
domain name is valuable enough, and you explicitly made a choice for
weaker security, you should bear some of the responsibility.

If we make policies to help people who make bad choices, that opens up
the entire issue of "Moral Hazard"

http://en.wikipedia.org/wiki/Moral_hazard

and will cause people to engage in even more risky behaviour, and
place the burden upon someone else (the secondary market, for example,
if irrevocable transfers are eliminated). In other words, in
attempting to "help" people who won't help themselves, you make the
situation even worse.

Some folks don't buy health insurance, for example. If society pays
for all health costs unconditionally and "equally", then that policy
can be abused (e.g. by smokers, who might generate higher health
costs, that are paid for by everyone else).

>> UDRP isn't "free", by the way.
>
> Who said it was??

You said "Transfer policy needs to be applicable to _ALL_ registrants
- not just those who are willing to pay a premium for extra levels of
security etc". I was arguing that existing policies and reality don't
apply to *all* registrants regardless of their income/wealth, etc.
Economics are implicit within all policies, whether you like it or
not.

> Yes, but that doesn't mean that other customers should be punished by a lack 
> of policy to assist them
>
> By your logic, if I install a safe in my house and a burglar alarm then I am 
> somehow on a different "level" to someone who hasn't. While the economic 
> levels are obvious that doesn't mean that the crime of breaking into my house 
> is any lessened by the levels of security I may (or may not) have implemented

You assume "policies" are their only option. There are always
alternatives, e.g. courts, they could have been more proactive, etc.

To answer your example of the breaking into a house, they're both
crimes, but one might be more severe, more of an "emergency" than
another. Let's suppose the "damages" were even identical $10,000 in
cash is stolen from both houses, one that had the safe and burglar
alarm, and one that had no security. Why isn't that "Moral Hazard" if
policy treats those cases identically? Indeed, folks might be
incentivized to not buy safes at all, if a policy existed to treat
them identically and cover 100% of the losses. I'm for a society where
people are incentivized to take responsibility for themselves....to
invest in the safes when they have something valuable to protect,
especially when that choice exists in the marketplace. Overall
security would be higher, and there'd be fewer thefts in that society,
as people were being proactive.

> While the study is interesting the audience is too narrow to be of any value 
> ie. Andrew's readers are going to be more "savvy" than your average SME

As I said, it was unscientific. But, the "average SME" isn't going to
be suffering an "emergency", is he/she? This is supposed to be a
policy for "urgent" cases, where there's the potential for the damages
to be of high magnitude. Those owners of high value (i.e. "important")
domains are *supposed* to be *savvy*!

> Normal users make assumptions. If I go to a garage to get my car serviced I 
> assume that the personnel know what they are doing and that they will do it 
> to a certain level. I am not a mechanic, so I don't care or need to know 
> about the "level", but as a consumer I should feel confident that when I pick 
> up my car from the garage that it will be safe to drive
>
> I would be pretty confident that most registrants assume that when they buy 
> domains and / or hosting that a certain degree of security etc., is present.

I've long argued that I'm 100% for higher levels of *proactive*
security. Raise the standards for everyone, that would reduce thefts.
Some folks put a GPS locator device on their car, to be able to track
it if it's stolen. Some invest in "The Club" to lock their steering
wheel.

The "ETRP" is saying, though, that if your car is *claimed* to be
stolen, the police should drop everything they're doing (i.e. impose a
cost on society) to treat your case as an emergency, whether your car
is a 1980 Lada or a 2010 Rolls Royce. Car owners are aware of the
risks, so should domain owners. I'm all for better education.

> Of course bigger companies, tech savvy types etc., might know more and might 
> ask more questions, but let's face it, for most people domains are tools. 
> They enable them to send / receive email etc., They don't view their domain 
> as being of any value to them until their ability to use the domain is 
> removed or hampered in some way.

Educate them, then. That was one of the recommendations from 5 years
ago. Has it been implemented? If not, why not?

>> As above, in creating a policy for emergencies, just as the
>> issues report discussed last year, isn't it supposed to be qualified
>> to only those situations where the magnitude of the harm is great?
>
> Well this is something that we did discuss quite a bit initially
>
> My personal view is that yes - I can see how some entities would place a 
> greater "value" or see a higher "impact" with their domain being taken, but 
> that ultimately even my personal domain name is of value to me.

It needs to be discussed more, then, because the choice to not apply
it only to *urgent* cases means that the cost/benefit calculation
changes, i.e. the "costs" imposed upon others by not properly
qualifying any procedure to true emergencies begin to exceed all
benefits.

e.g. a proper policy limited to "urgent" situations has a benefit of
$5 million and a cost of $100,000. A broader policy that is
unqualified has benefits of $5.5 million (i.e. an extra $500K in
benefits because it applies to more marginal cases), but has greater
costs now of $10 million (because of the increase in "costs",
"burdens" imposed due to greater conflicts caused by that policy,
etc.). I'm arguing that if there's going to be a policy, it should be
like the former, and not the latter.

And I note that no one has responded to the thread that directly asks
those questions, to get a better sense of the actual damages,
statistics, etc.:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00384.html

and to be able to gauge benefits vs. costs. These questions might seem
"difficult", but if they're not going to be answered, then there
should be no further work done, as one would be considering the output
of this group to be "religion-based" rather than
"scientifically-based." (i.e. just taking things on "faith" and
handwaving alone, "think of the children" emotionality vs. being data
driven).

V] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00406.html

And if one wants to start "thinking outside the box" a little bit,
consider how motorists react when traffic lights are *entirely
eliminated*:

http://www.streetsblog.org/2009/05/04/experimenting-with-the-elimination-of-traffic-lights/

http://streetswiki.wikispaces.com/Shared+Space

They begin to take responsibility, and drive more safely.

Instead of thinking "more and more" policies are the solution,
challenge your own assumptions.

W] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00409.html

Why should society bear the costs of other people's irresponsibility?
We see that in the US mortgage market, for example, where some people
entered into "bad deals" and then wanted a "bailout", to be able to
renegotiate their loans, have the government pay their mortgages,
whatever.

When people don't bear some of the responsibility for their own
actions, that's far worse. But, at least your position is explicit.

>> and will cause people to engage in even more risky behaviour, and
>> place the burden upon someone else (the secondary market, for example,
>> if irrevocable transfers are eliminated).
>
> So I'm meant to feel sorry for domainers?

The "secondary market" is not the only example of folks hurt, and the
secondary market is more than just "domainers." It's like suggesting
that the secondary market for housing only consists of "house
flippers." Suppose MarkMonitor or Marksmen does a stealth acquisition
on behalf of Google or Microsoft for a domain name. The name is
acquired, and put to use. What's going to happen when that name is
clawed back immediately by the ETRP, as currently proposed, due to
seller's remorse and lack of due process via a dispute mechanism?

That's why last year it was correctly written that:

http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00384.html

"The emergency action procedures should be tested to verify they are
resilient to tampering and difficult to exploit. In particular, it
should be difficult or impossible for an attacker to effect a hijack
or interfere with a transfer under the guise of requesting urgent
restoration of a domain."

It's not about feeling "sorry for domainers", it's about not opening
up a new loophole that can be exploited, when one attempts to fix a
different problem (same goes for the 60 day lock following registrant
change, how that can be abused by registrars to essentially rewrite
the intent of the transfers policy under the guise of "improving
security"). And as folks clearly know, the loopholes are routinely
exploited, especially by registrars.

>> In other words, in
>> attempting to "help" people who won't help themselves, you make the
>> situation even worse.
>
> You really should join some of the other fun PDPs .. :)
>
> While I can agree with you to a point I'd still disagree. Domain Registry of 
> America, for example, use tactics that have been deemed to be misleading and 
> possibly even illegal. Our clients get hit with their letters all the time. 
> (Rob Golding mentioned them last night)
> Personally I would like to see policy that had the "teeth" to stop this kind 
> of thing.
> So if a small business owner is duped by these kinds of companies they can be 
> seen to have "made a bad choice", but do they have the information available 
> to them to do otherwise?

You don't need a policy that has "teeth" to "stop this kind of thing."
If you're a registrar, you can validate outgoing transfers by
telephone (before unlocking the domain name or issuing an EPP
auth_info code). It's your choice whether or not you want to educate
your customers. Other registrars do educate their customers, e.g.
EasyDNS, to name an example:

http://support.easydns.com/domain.slammers/index.php

If you called the client you're about to lose, and asked them why
they're leaving, you would put a stop to things. Or, if you have legal
standing, go ahead and sue the "bad guys." If a registrar's business
model is 100% electronic, and are never going to pick up the phone to
talk to their own customer, that's their own choice.

>> Economics are implicit within all policies, whether you like it or
>> not.
>
> Again - we have to disagree

Go look at the AOC document:

http://www.icann.org/en/announcements/announcement-30sep09-en.htm

"To ensure that its decisions are in the public interest, and not just
the interests of a particular set of stakeholders, ICANN commits to
perform and publish analyses of the positive and negative effects of
its decisions on the public, including any financial impact on the
public, and the positive or negative impact (if any) on the systemic
security, stability and resiliency of the DNS."

It cannot be more clear. If economics were not implicit (and heck even
explicit), then these policies would be religious edicts, not
carefully balanced policies as they should be. If you only look at
"benefits", your job is only half-done, because you've not weighed the
"costs." (and the job is not even half-done, as even the "benefits"
for this workgroup remain unknown, because of the lack of data to
date)


>> As I said, it was unscientific. But, the "average SME" isn't going to
>> be suffering an "emergency", is he/she?
>
> I don't think you are qualified to judge that

Yes, I am. By definition, a policy meant for "emergencies" is meant
for *extreme* events, not "average" events. If the imaginary "average
SME" could even qualify for an "emergency" (where the damages are high
and return is urgent), then by definition they weren't "average" to
begin with.

For example, in the financial crisis, some banks were *allowed* to
fail. Some were "too big to fail." I'm sure those small banks that got
wiped out felt they were in an "emergency", but there was no systemic
risk due to their failure.

> We, Blacknight, are an SME. If blackreg.com were hijacked it would cause a 
> LOT of headaches for us and our clients, which we would classify as an 
> "emergency"
>
> In any case an "emergency" is subjective
> The key thing is that there is one and there is urgency

1) You don't get to self-declare that "we're in an emergency" -- it
has to be according to a 3rd party standard (i.e. one this workgroup
was *supposed* to develop, to distinguish between "urgent" and
"non-urgent" cases). Otherwise, *every* case becomes an "emergency",
which subverts the policy.

2) Just because something is "subjective" doesn't mean one "gives up."
One applies rules, makes judgments about "subjective" things *all the
time.* If you can't come up with a standard, leave it to someone who
can, i.e. an independent court.

3) Simply saying "there is one" and "there is urgency." doesn't make
it one. Go back to the "too big to fail" example. Some are bigger than
others, and one has to draw a line somewhere. If one is incapable of
drawing that line anywhere at all, then perhaps one shouldn't be a
decision-maker, and leave it to those who can make the tough
decisions.

>> Educate them, then. That was one of the recommendations from 5 years
>> ago. Has it been implemented? If not, why not?
>
> How?

Registrants are educated via WHOIS reminders to keep their WHOIS up to
date. There are advisories by ICANN. Registrars can proactively hold
seminars. They can blog, as MarkMonitor has done about VeriSign Lock
on CircleID, etc.

People learn, e.g. Facebook and privacy, whatever.


>> And I note that no one has responded to the thread that directly asks
>> those questions, to get a better sense of the actual damages,
>> statistics, etc.:
>
> Don't take it personally, but not all of us have the time to do our dayjobs 
> and answer each and every post on every single list we're on  ..

Yes, but that's one of the most fundamental questions, that questions
the entire basis for this workgroup. You don't need a policy if there
are no benefits, or if the benefits are miniscule (i.e. because
there's only a small number of hijackings that are serious and not
undone in a timely manner) relative to the costs. That will need to be
answered at some point (before a final report, although it should have
been done before the preliminary report!), one can be sure, otherwise
it leaves the policy to be challenged due to Paragraph 4 of the AOC
via a reconsideration request, etc. If you can't analyze the positive
and negative effects, then I repeat this is just a religious
endeavour, and not a scientifically-based data-driven policy group.

X] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00411.html

It also forces people to be at a registrar against their will,
undermining the purpose of the transfers policy. That affects not only
"domainers" but anyone with a registrant change (if it's allowed to
stand).

> So a GoDaddy or Enom is expected to somehow remove all the automation and 
> convenience that they give their clients so that they can somehow know about 
> each and every transfer and validate them manually?
>
> That doesn't scale
>
> I'd also suspect that you'd be one of the first to complain if we all started 
> charging 100 euro / year for a .com (regardless of its perceived value)

It's their choice. How is it Fabulous can offer "Executive Lock",
without charging any extra? Or ask Moniker how much "MaxLock" costs,
or how much VeriSign Lock costs MarkMonitor clients, etc. That's a
choice that the registrant is fully in control of, for the "important"
domains.

Remember, I proposed an "Irrevocable Transfer Procedure", for those
who want transfers / registrant changes, etc. to be "final" (as they
should be).

As for automation....sending SMS codes can be 100% automated (e.g.
password recovery of Gmail accounts). Sending faxes can be 100%
automated. Using 2-factor security can be 100% automated. Sending an
email to 10 different email addresses if there's any domain change can
be 100% automated. Some registrars will find excuses, others seek
solutions.

If some registrars can't compete, they should be allowed to fail, to
go out of business. Trust me, I have no sympathy for "bad registrars".
Am I supposed to feel "sorry" for them? If you consider yourself a
"good registrar", you should welcome the opportunity for the bad
registrars to be forced out of the business.

> I'm reading the same paragraph as you and I do not interpret it as that at all
> "any" financial impact does not mean that all policies will have an impact
>
> It only means that there should be consideration *if* there is one .. if 
> there isn't it's completely moot

Nearly every policy has some financial impact. A 60-day lock, where
you can't be at the registrar of your choice most definitely has a
financial impact on registrars. Why else do you see them complaining
when registrars are holding their names "hostage"? Does this sound
like a "happy customer"

http://twitter.com/chiefted/statuses/18527676833

If I'm willing to pay $X to get out of that 60-day lock, for example,
or to opt-out of the "clawback" procedure, that's a direct measure of
the financial impact to me of some of the policies.

Suppose Mikey owns Bar.com, for example, and wants to sell it to me. I
might have paid $1,000,000 if the current policies (i.e. irrevocable
transfer) existed. If I had to buy it and risk him executing a ETRP
six months from now, or risk it being held for 60 days at a registrar
that I consider undesirable, for whatever reason (e.g. bad
jurisdiction, doesn't provide all the services I desire, doesn't offer
VeriSign lock, has strange TOS that nickel and dime me, etc.), I might
only be willing to pay $800,000. Consider that across *all* domains,
and it begins to add up.

In a financial example, people from time-to-time rage against
"short-sellers" or " high frequency trading" or whatever cause celebre
exists amongst the short-sighted and uninformed/misinformed. So they
start talking about imposing various trading restrictions, etc., that
cause far more damage than they purport to fix. It might make them
"feel good" that they're "doing something", but it causes far more
damage by undermining markets (e.g. it decreases liquidity, raises
bid-ask spreads, makes legitimate hedging costlier, etc.). Sound
policy needs to be more than just reactionary, "gotta do something",
"think of the children" kind of emotional stuff.


>>>> As I said, it was unscientific. But, the "average SME" isn't going to
>>>> be suffering an "emergency", is he/she?
>>>
>>> I don't think you are qualified to judge that
>>
>> Yes, I am.
>
> Based on what exactly?

I said so in my prior email....the fact that they are *average* makes
it impossible. See:

>> By definition, a policy meant for "emergencies" is meant
>> for *extreme* events, not "average" events. If the imaginary "average
>> SME" could even qualify for an "emergency" (where the damages are high
>> and return is urgent), then by definition they weren't "average" to
>> begin with.
>>
>> For example, in the financial crisis, some banks were *allowed* to
>> fail. Some were "too big to fail." I'm sure those small banks that got
>> wiped out felt they were in an "emergency", but there was no systemic
>> risk due to their failure.
>
> An American  viewpoint again
>
> Over here none were allowed to fail

I'm Canadian. :-) Yes, and we've seen how the market has voted --- the
Euro has been killed. You want the domain system to be a "nanny
state".....I don't think everyone else does.

>>>> Educate them, then. That was one of the recommendations from 5 years
>>>> ago. Has it been implemented? If not, why not?
>>>
>>> How?

You have an "excuse" for every educational tool. Yet, somehow you
don't apply the same critical standards to the workgroup's report.
It's "perfect", isn't it? :-)

>> Registrants are educated via WHOIS reminders to keep their WHOIS up to
>> date.
>
> Which are often treated as spam ..

How often? Show me the data. Certainly registrars can educate via
their web interfaces, oh, I don't know, when they're going to
*register* the domain name in the first place, or renew it, or make
any changes to it? If some registrars can put up 10 screens to "up
sell" before a "checkout", they can certainly design systems to
educate their own clients, if they wanted to. Some registrars prey on
their own customers' ignorance, though, and take advantage of them
(e.g. grabbing their customers' domains after expiry). I can see why
some registrars might not *want* to educate their own customers.

>> If you can't analyze the positive
>> and negative effects, then I repeat this is just a religious
>> endeavour, and not a scientifically-based data-driven policy group.
>
> Show me one that is?

The new gTLDs process is having attempts at economic reports. It's one
of the overarching issues. When folks talk about UDRPs, folks attempt
to measure the number of cases per year (if they're going up or down,
how they compare to the total number of registered domains, etc., when
arguing for/against the URS, or the GPML, etc.).

You implied above that certain security would cost "100 Euro/year".
How is it Gmail can implement SMS codes for account security, and do
it on a completely free service? How is it that PayPal can issue
security key fobs (2-factor security) for $5 (one time fee,
irregardless of account balances).

https://www.paypal.com/securitykey

(and obviously this scales beautifully, as it would be $5 whether I
own 1 domain or 100,000 domains, if applied to DNS)

> Most of the ICANN PDPs (not all) come from a perceived issue being identified 
> and a group of volunteers trying their best to come up with some kind of 
> solution (or not) to whatever the problem is
>
> In the case of IRTP we have had some hard data from ICANN Compliance, so 
> claiming that there was none at all is a misrepresentation of the facts.

Yes, that data was a small number of complaints to ICANN (something
like 50 cases, total, of claimed "hijackings"), making it rank 10th in
importance. And that "data" didn't list the domains involved, weigh
the actual "urgency" for each case, the damages, which registrars were
involved, and so on. Which ones were resolved, and which ones weren't.
Where are all the TDRP decisions, for example, so one might compare
actual cases where transfers are in dispute, to see if there are
failures of that policy? Is there a trend (e.g. one can count the
number of annual UDRP cases, court cases involving cybersquatting,
etc.)?

Garbage-in, garbage-out. There might have well have been "none", when
the "data" is of so low quality, and the registrars that claim there's
a "real problem" won't provide their data. e.g. how many domains are
being hijacked from NSI, GoDaddy, etc. on a daily basis? What were the
root causes of those hijackings? Don't you think that should *guide*
policy? Or are registrars too embarrassed to disclose the real numbers
and real facts? Too embarrassed that if we actually looked at the
cases of theft, that the blame might fall upon them (while dumb
registrants might not read ICANN Security Reports, aren't registrars
supposed to keep up from recommendations from 5 years ago?), instead
of the so called "dumb registrants" who "don't know any better" that
you're trying to "nanny."

Y] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00412.html

And just in case anyone didn't "get" that reference to being
"Canadian"...no Canadian banks *needed* to be bailed out, because
Canada had the best *proactive* policies and didn't suffer any
financial crisis. QED.

It's Canada who has been fighting against all the crazy "reactionary"
financial policy ideas out there like bank taxes, Tobin taxes, etc.,
from the folks who "got it wrong" before and want to "do
something....to save the children!"

Z] http://forum.icann.org/lists/gnso-irtp-b-jun09/msg00425.html

I've come to realize my contributions and expertise aren't being
respected in this workgroup. So, I'm leaving. Please remove me from
the mailing list.

The ones that think they've produced a "perfect" report will
eventually have to deal with the fact that they've left in many
loopholes that will be exploited by bad guys. I'm not going to bother
pointing out all the gaps in the report, just to have my comments be
ignored by folks who have been sloppy and don't want to admit it. It's
better that you produce the bad policy, let the worst happen, and deal
with those consequences, with your names on the report, not mine. I
have the financial resources to route around your bad policies,
unfortunately most people don't.

So, farewell. It was a pleasure working with some of you.