RE: [gnso-irtp-b-jun09] Expedited Transfer Reverse Policy (eTRP) (Draft)

["James M. Bladel" <jbladel@xxxxxxxxxxx>]

Mike:

Thanks for your questions / comments.  Many of the issues you raised
were discussed during today's call, so I think you're hitting on some of
the same themes.  There is still work remaining, but the idea of
formalizing a process that is currently ad-hoc has appeal for folks
across the ICANN spectrum.

I've tried to address some of your questions in-line, but am probably
not doing justice to our lengthy discussions.  I recommend checking out
the MP3 and/or transcript as well.

Thanks--

J.


-------- Original Message --------
Subject: RE: [gnso-irtp-b-jun09] Expedited Transfer Reverse Policy
(eTRP) (Draft)
From: "Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>
Date: Tue, April 13, 2010 8:53 pm
To: "'IRTP B Mailing List'" <Gnso-irtp-b-jun09@xxxxxxxxx>


Thanks James and team for the thoughtful work. However I think this
raises more questions for me than it solves at this point:

-- Should we suggest a minimum verification protocol here? 3.4.2
Documentation that the PTRr has verified the identity of the
pre-transfer registrant, in a manner conforming to local law and
practices.

JMB:  Open to ideas on how this can be phrased, without being over
prescriptive.


-- Section 3.6, why delete the requirement to restore the NS?

JMB:  Our discussion was that there could be scenarios in which the data
was changed (unauthorized) prior to the IRTP, so we wanted to leave some
flexibility here to address all possible incidents.  Once the Ry
restores the PTRr, they can effect whatever change is required /
requested by the registrant.


-- Seems there must be a mechanism for the newly-gaining
Registrar/Registrant to object to the eTRP transfer-back? What if there
is proof of written authorization from the prior registrant? That
situation seems to unravel this entire process and make it a potentially
very bad idea to implement. "Cold feet" cannot be enough to reverse a
previously authorized transfer 60 days later, so what mechanisms can we
suggest to ensure the eTRP cannot be used for that purpose?

JMB:  This is an open topic. Open to your ideas on the next call.


-- Section 4.14, how would the PTRr know if litigation was pending
anywhere in the world? 

JMB:  This is also an open question from today's call.


-- Section 4.3, "fraudulent" is a very loaded legal term, requiring
proof of at least five elements under US law, varying in other
countries. It can be criminal and/or civil. It ought not be proved
merely by the self-serving declaration of the alleged victim, so again,
how do we prevent abuse of this system?

JMB:  An interesting point.  Originally, we used "Fraudulent or
Erroneous," but the latter term was too broad.  So, the former is a hold
over from this earlier phrase.  Suggest we replace all instances to
"Unauthorized."


-- Section 4.4, seems to give registrars far too much discretion, which
most of them I believe do not even want to have, as it can subject them
to liability.

JMB:  Registrars are already addressing hijacks, albeit in an ad-hoc
manner and with inconsistent results.  We're seeking to clean this up
and formalize the process / outputs.


So, maybe I am back to square one on this issue, what is the harm we are
trying to solve, how has it been documented to date, and is this really
the best way to mitigate it without causing a much bigger problem?



Mike Rodenbaugh
RODENBAUGH LAW
tel/fax: +1 (415) 738-8087
http://rodenbaugh.com 

-----Original Message-----
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of James M. Bladel
Sent: Monday, April 12, 2010 9:04 PM
To: IRTP B Mailing List
Subject: [gnso-irtp-b-jun09] Expedited Transfer Reverse Policy (eTRP)
(Draft)

Team:

Attached, please find two documents:

 * A draft of the Expedited Transfer Reverse Policy (eTRP). This is a
draft recommendation for a new policy, and very much a work in progress.
 But the general structure has been developed and reviewed by various
stakeholders in the GNSO community.

 * A spreadsheet capturing feedback received from Registries,
Registrars, and ICANN Policy & Legal teams. Many of these items were
received as comments to an earlier draft, and this version (Apr 11) has
been modified to reflect some of the feedback received. Other items were
specifically deferred for discussion by our group as a whole.


I look forward to discussing these during our next call.

Thank you,

J.