ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

RE: [gnso-irtp-b-jun09] Recommended Modifications to the Latest ERTP Recommendation

  • To: "'Steele, Barbara'" <BSteele@xxxxxxxxxxxx>, "'IRTP B Mailing List'" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: RE: [gnso-irtp-b-jun09] Recommended Modifications to the Latest ERTP Recommendation
  • From: "Michael Collins" <mc@xxxxxxxxxxxxxxxxx>
  • Date: Wed, 19 May 2010 17:19:13 -0400

Hi Barbara and all,

 

Thank you for your work on this. It is good to remove erroneous assumptions
about TDRP from ETRP. I am disappointed that the TDRP cannot be used to
resolve a potential dispute between registrars and their customers that
results in an ETRP. I am not sure that it is within our mandate to suggest
any changes to TDRP, though it does not seem to work well in practice
according to some members of our group.

 

It was my desire for the domain to stay in the control of PTRa during a
dispute. However, if we are going to accept that a claim of hijacking (ETRP)
is cause to reverse a transfer, we should accept that a claim that an ETRP
was filed in error (Disputed ETRP) as cause to restore a transfer, not just
when PTRa agrees. PTRa should not be put in the place of deciding a dispute
between PTRa and the gaining Registrar. Both claims (ETRP and Disputed ETRP)
must present the same level of explanation, identification and
indemnification and lacking any dispute resolution mechanism should be
treated with equal actions. 

 

It is my opinion that most hijackers will not want to reveal their identity
and indemnify their registrar, so most ETRPs caused by hijacking will not
result in a Disputed ETRP. PTRa could still file a TDRP to resolve an ITRP
dispute, but it would not get to decide the dispute in a TDRP.

 

Would the group like to discuss this before I attempt to edit the document
to make these changes?

 

Best regards,

Michael Collins

 

 

From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Steele, Barbara
Sent: Wednesday, May 19, 2010 2:47 PM
To: IRTP B Mailing List
Subject: [gnso-irtp-b-jun09] Recommended Modifications to the Latest ERTP
Recommendation

 

All,

I have incorporated my recommended modifications into the latest version of
the document.  Because this proposed policy is intended to augment existing
policies, I have deleted the language relating to option to dispute a
disputed ERTP using the TDRP.  Also, the registries will not want to be in
the middle of the communications that ensue between the PTRa and the new
Registrar should the new Registrar elect to dispute the ERTP.  The
registries would add little to no value in that activity.  To the extent
that the PTRa, upon receipt of a Disputed ERTP case from the new Registrar,
agrees that the domain name should not have been transferred via the ETRP,
then they would forward the Disputed TDRP to the appropriate Registry
Operator and the Registry Operator would restore the domain name to the new
Registrar within 5 days (I changed this from 30 days as the IRTP calls for
the following in Part A, Section 6: 

"The Registry Operator must undo the transfer within five (5) calendar days
of receipt of the notice except in the case of a Registry dispute decision,
in which case the Registry Operator must undo the transfer within fourteen
calendar days unless a court action is filed. The notice required shall be
one of the following:

i. Agreement of the Registrar of Record and the Gaining Registrar sent by
email, letter or fax that the transfer was made by mistake or was otherwise
not in accordance with the procedures set forth in this policy; 

ii. The final determination of a dispute resolution body having jurisdiction
over the transfer; or

iii. Order of a court having jurisdiction over the transfer."

Please let me know if any of my recommended edits do not make sense.  Many
thanks.

<<...>> 

Barbara Steele

Compliance Officer / Director of Policy

VerSign, Inc.



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

Privacy Policy | Terms of Service | Cookies Policy