[gnso-irtp-b-jun09] i'm offering another approach to the ERTP thingy
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">hi all,<div><br></div><div>i've shamelessly edited the document we reviewed last week, making it even simpler but i think also better. i'd like to take a few minutes on the call to review this idea. here's the gist of it.</div><div><br></div><div>the problem with ETRP and all of it's related kin is that it:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>a) forces the registrar and/or the registry to judge the merits of a hijacking claim at lightening speed -- and essentially makes them dispute-resolvers in a situation of imperfect information.</div><div><br></div><div>b) that high-speed judgement also leaves the process open to gaming by disgruntled sellers looking to "claw back" a domain name.</div></blockquote><div><br></div><div>preventing these two problems leads to all kinds of complexity and, as we discovered, eventually gets too heavy for its own weight. so let's step back…</div><div><br></div><div>what if we:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>a) recommend enacting the Emergency Action Channel proposed in SAC007</div><div><br></div><div>b) remove the judgement-call/dispute-resolution by registrars/registries</div><div><br></div><div>c) make the criteria for urgent-return be factual and externally-verifiable -- "the gaining registrar does not respond to an Emergency Action request within X hours"</div><div><br></div><div>d) remove the changes to the TDRP, since the return is being done for non-disputable reasons</div></blockquote><div><br></div><div>this way, neither the losing registrar nor the registry have to evaluate anything to do with the claim of hijacking, they simply are provided a way to get a domain name returned to its prior state in the case where the gaining registrar is not communicating. presumably, since registrars are pretty confident that they can resolve most of the hijacking problems if they can actually *talk* to the other party, this would address some pretty large proportion of the problem.</div><div><br></div><div>what say you? i've attached the slashed up version of the draft for you to review.</div><div><br></div><div>mikey</div><div><br></div><div></div></body></html> Attachment:
IRTP and TDRP - urgent-return tweaks v.0.6.doc <html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div></div><div><br></div><div><br><div> <div><div style="font-size: 12px; ">- - - - - - - - -</div><div style="font-size: 12px; ">phone <span class="Apple-tab-span" style="white-space: pre; "> </span>651-647-6109 </div><div style="font-size: 12px; ">fax <span class="Apple-tab-span" style="white-space: pre; "> </span>866-280-2356 </div><div style="font-size: 12px; ">web <span class="Apple-tab-span" style="white-space: pre; "> </span><a href="http://www.haven2.com";>http://www.haven2.com</a></div><div style="font-size: 12px; ">handle<span class="Apple-tab-span" style="white-space: pre; "> </span>OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)</div></div> </div> <br></div></body></html>
|