<<<
Chronological Index
>>> <<<
Thread Index
>>>
[gnso-irtp-b-jun09] EAC Abuse
- To: "ITRP-B Mailing List Mailing List" <Gnso-irtp-b-jun09@xxxxxxxxx>
- Subject: [gnso-irtp-b-jun09] EAC Abuse
- From: "James M. Bladel" <jbladel@xxxxxxxxxxx>
- Date: Tue, 03 May 2011 05:59:00 -0700
<html><body><span style="font-family:Arial; color:#000000;
font-size:10pt;"><div><span><span style="font-family: Arial; color: rgb(0, 0,
0); font-size: 10pt; clear: both;"
mce_style="font-family:Arial;color:#000000;font-size:10pt;"><div>Per our
discussion, I am concerned about the potential for registrars to abuse the EAC
for non-emergency issues, or to claim EAC messages did not receive a timely
response. This latter scenario would put the Registry in the position of
evaluating conflicting registrar claims before executing a transfer
undo.</div><div><br></div><div>Therefore, I believe we need an "objective
observer" to the EAC exchange. I promise I'm not seeking to
over-complicate this mechanism, but if both registrars simply copied or
emailed the Registry support address when initiating or responding to an EAC
request, then this would close that loophole.</div><div><br></div><div>I spoke
briefly with Barbara, and while we both recognize that this is an extra step
in the process, it would effectively remove the need for the Registry to
determine which party was telling the truth.</div><div><br></div><div>For our
"Phase II" strategy, we should recommend that this function be added to RADAR
(or a separate <a target="_blank" href="http://EAC.ICANN.ORG";
mce_href="http://EAC.ICANN.ORG";>EAC.ICANN.ORG</a> system be deployed).
The basic functionality would be that registrars log in to send or respond to
an EAC, with both transactions copying ICANN and the Registry and being
timestamped. But it is not practical to expect this at the
outset.</div><div><br></div><div><br></div><div>Thanks--</div><div><br></div><div>J.</div></span></span><br
mce_bogus="1"></div></span></body></html>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|