<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif; color: rgb(0, 0, 0); "><div><div>Dear all,</div><div><br></div><div>Following Monday's call, please fine below's summary of the points that Carlos from ICANN Compliance raised during the call. In case you did not attend the call or would like to listen again, you can find the MP3 recording <a href="http://audio.icann.org/gnso/gnso-irtp-d-20131216-en.mp3">here</a>. </div><div><br></div><div>Many thanks and best wishes,</div><div>Lars</div><div><br></div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><b>From an ICANN Compliance point of view</b></div><div>Scenarios (under IRTP as it stands) in which ICANN Compliance has the authority to act: </div></div></span><div><br></div><div><b>Regarding the loosing registrar:</b></div><div><br></div><div><u>Auth-code related:</u></div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">- the registrant was not able to retrieve the auth code from the control panel, then the registrant requested the registrar to send it but it was not sent within the required 5 days ----- (the breach in this case is when both conditions are present)</div></span><div>- the means provided by the registrar for the registrant to retrieve the auth code are more restrictive than the means provided for the registrant to update its contact or name server information</div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">- the registrar sends the Auth Code to someone who is not the registered name holder</div></span><div>- the registrar does not even send it at all</div><div><br></div><div><u>FOA related:</u></div><div>- the registrar does not send the FOA</div><div>- sends it to someone who is not a Transfer Contact</div><div><br></div><div><div><u>Unlocking of the domain name:</u></div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">- the registrant did not have the means provided by the registrar to unlock the domain name, then the registrant requested the registrar to unlock the domains and the registrar did not unlock them within the five days ----- (the breach in this case is when both conditions are present)</div><div><br></div></span></div><div><b>Regarding the gaining registrar:</b></div><div><br></div><div><u>Auth-code related:</u></div><div>- the registrar allows the transfer without receiving the Auth-code - which would be technically impossible but can theoretically happen (in a scenario also involving registry error)</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><u>FOA related:</u></div><div>- the registrar does not send the FOA</div><div>- the registrar sends the FOA to someone who is not a Transfer Contact</div><div>- the registrar allows the transfer without receiving confirmation after sending the FOA</div></div></span></div></body></html>