[gnso-irtp-b-jun09] FW: [Registrar-announcements] IMPORTANT NOTICE - Changes to Transfer Policy Effective 1 June 2012
Dear All, For your information, please find below and attached the notice that was sent to registrars yesterday with regard to the changes to the IRTP as a result of the recommendations of the IRTP Part B PDP. Thanks again for all your hard work! Only three more IRTP PDP's to go ;-) Best regards, Marika On 2/29/12 2:13 PM, "Tim Cole" <Tim.Cole@xxxxxxxxx<mailto:Tim.Cole@xxxxxxxxx>> wrote: Note: This notice is provided below in plain text. A PDF version is also attached. 29 February 2012 ICANN Notice Registrars: Changes to Inter-Registrar Transfer Policy Go Into Effect on 1 June 2012 Dear Registrar, This is a notice to formally inform you that ICANN has adopted several changes to the Inter-Registrar Transfer Policy (³IRTP²) based on the ICANN Board Resolution adopted on 25 August 2011 (http://www.icann.org/en/minutes/resolutions-25aug11-en.htm#1.2). The amended policy will be posted shortly at http://www.icann.org/en/general/consensus-policies.htm. As a consensus policy under the RAA, all registrars must comply with the new obligations and revised provisions as explained below within three months of this notice and in any event, no later than 1 June 2012. The changes to the IRTP include: 1) A new requirement for Registrars to provide a Transfer Emergency Action Contact (³TEAC²), updating Section 4 and Section 6 of the IRTP. Under this requirement the messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer. 2) A modification to Section 3 of the IRTP requiring that the Registrar of Record/Losing Registrar notify the Registered Name Holder/Registrant of the transfer out. 3) A modification to the #6 Reason for Denial under Section 3 of the IRTP, which requires that the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis. 4) The deletion of the #7 Reason for Denial under Section 3 of the IRTP. These changes modify the language of the IRTP as follows: TEAC Requirement New Text added to Section 4: Registrars will establish a Transfer Emergency Action Contact (³TEAC²) for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes. Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN RADAR system. Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain. Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer. The losing registrar will report failures to respond to a TEAC communication to ICANN Compliance and the registry operator. Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section 6 of this policy and may also result in further action by ICANN, up to and including non-renewal or termination of accreditation. Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request. This documentation will be retained in accordance with Section 3.4 of the Registrar Accreditation Agreement (RAA). Users of the TEAC communication channel should report non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic tests of the Registrar TEAC communication channel in situations and a manner deemed appropriate to ensure that registrars are indeed responding to TEAC messages. New Text added to Section 6: A new option for communicating an undo request to the Registry Operator has been added: 6.iv Documentation provided by the Registrar of Record prior to transfer that the Gaining Registrar has not responded to a message via the TEAC within the timeframe specified in Section A.4. Revised Text to Section 6: The term ³domain name² in the second sentence of the fourth paragraph in Section 6 of the IRTP has been revised to ³Registrar of Record field² as follows: ³The Registry Operator shall undo a transfer if, after a transfer has occurred, the Registry Operator receives one of the notices as set forth below. In such case, the transfer will be reversed and the Registrar of Record field reset to its original state.² TEAC Implementation Requirements in RADAR A new contact field has been set up in RADAR for each registrar to enter its contact details for the Transfer Emergency Action Contact. ICANN has initially populated the TEAC fields with information presently on file for the registrar¹s Transfer Contact (Primary Contact if Transfer Contact was not present). Registrars are encouraged to log into RADAR as soon as practical to update this contact information. Once logged into RADAR registrars will have access to the contact information for all other registrars under the ³View All Registrars² button on the left side of the screen. This feature is live now, however the use of the TEAC and the response time requirement will not go into effect until 1 June 2012. The communication function in RADAR will be live on the effective date. The losing registrar will be able to use the communication tool to send an Emergency Action request to the gaining registrar¹s TEAC. This message will be time and date stamped to facilitate compliance with the 4-hour response requirement. A record of this communication along with the date and time sent will be maintained by ICANN and available for future access should it be needed. Modification to Section 3 Original text: A Registrar of Record can choose independently to confirm the intent of the Registered Name Holder when a notice of a pending transfer is received from the Registry. The Registrar of Record must do so in a manner consistent with the standards set forth in this agreement pertaining to Gaining Registrars. New text: A Registrar of Record shall confirm the intent of the Registered Name Holder when a notice of a pending transfer is received from the Registry by notifying the Registered Name Holder of the transfer. The Registrar of Record must do so in a manner consistent with the standards set forth in this agreement pertaining to Gaining Registrars. Original text: The FOA should be sent by the Registrar of Record to the Transfer Contact as soon as operationally possible, but must be sent not later than twenty-four (24) hours after receiving the transfer request from the Registry Operator. New text: The FOA should be sent by the Registrar of Record to the Registered Name Holder as soon as operationally possible, but must be sent not later than twenty-four (24) hours after receiving the transfer request from the Registry Operator. Modifications to Reasons for Denial Under Section 3 Reason for Denial #6 - Original text: Express written objection to the transfer from the Transfer Contact. (e.g. - email, fax, paper document or other processes by which the Transfer Contact has expressly and voluntarily objected through opt-in means) Reason for Denial #6 - New text: Express objection to the transfer by the authorized Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis and upon request by the authorized Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact to remove the lock within five (5) calendar days Reason for Denial #7 - Original text: A domain name was already in ³lock status² provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status. Reason for Denial #7 - Revision: The original text noted above has been deleted. Renumbering of Reasons for Denial #8 and #9 The previous Reasons for Denial #8 and #9 are now #¹s 7 and 8 respectively. The original text in these Reasons for Denial remains the same. Effective Date In order to provide a reasonable period of time to implement and comply with these revised provisions of the IRTP, registrars will have three months from the date of this notice; but in any event registrars must comply no later than 1 June 2012. Nothing in this notice should be construed as preventing registrars from voluntarily complying with these changes earlier than that date, however the new 4-hour TEAC requirement will only commence operation on the effective date. Tim Cole Chief Registrar Liaison ICANN One World. One Internet. Attachment:
IRTP_Changes_Effective_1_June_2012.pdf |