Dear all, 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 here<http://audio.icann.org/gnso/gnso-irtp-d-20131216-en.mp3>. Many thanks and best wishes, Lars
From an ICANN Compliance point of view Scenarios (under IRTP as it stands) in which ICANN Compliance has the authority to act:
Regarding the loosing registrar: Auth-code related: - 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) - 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 - the registrar sends the Auth Code to someone who is not the registered name holder - the registrar does not even send it at all FOA related: - the registrar does not send the FOA - sends it to someone who is not a Transfer Contact Unlocking of the domain name: - 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) Regarding the gaining registrar: Auth-code related: - 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) FOA related: - the registrar does not send the FOA - the registrar sends the FOA to someone who is not a Transfer Contact - the registrar allows the transfer without receiving confirmation after sending the FOA