ICANN ICANN Email List Archives

[gnso-irtpc]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-irtpc] FW: [Registrar-announcements] IMPORTANT NOTICE - Changes to Transfer Policy Effective 1 June 2012

  • To: "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: [gnso-irtpc] FW: [Registrar-announcements] IMPORTANT NOTICE - Changes to Transfer Policy Effective 1 June 2012
  • From: Marika Konings <marika.konings@xxxxxxxxx>
  • Date: Thu, 1 Mar 2012 02:35:32 -0800

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
Description: IRTP_Changes_Effective_1_June_2012.pdf



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy