[Gnso-ppsai-pdp-wg] Obligation to Respond to Inquiries

Metalitz, Steven met at msk.com
Wed May 14 23:57:16 UTC 2014

James, could you explain the basis for the assertion below that inquiries to accredited p/p/ providers would be less time sensitive than those to registrars under IRTP?  I imagine that sometimes this would be true, sometimes not.

One way to shed light on this might be to explain what constitutes an "emergency" under IRTP.


Steve Metalitz

From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of James M. Bladel
Sent: Tuesday, May 13, 2014 12:09 PM
To: gnso-ppsai-pdp-wg at icann.org
Subject: [Gnso-ppsai-pdp-wg] Obligation to Respond to Inquiries


Today we discussed the question of whether or not P/P services should be required to respond to inquiries/reveal requests.  I raised the idea that we could use something like the TEAC as a model.  Below, I've pasted the applicable text from the transfer policy (IRTP).

The TEAC model applies to our issues in that:

  1.  The accredited registrar is required to respond promptly
  2.  There is no guaranteed outcome as a result of the inquiry, and
  3.  There is an understanding that ICANN will sanction registrars who do not respond, as well as registrars abusing TEAC for non-emergencies.
However, as Michele and others point out, the TEAC model falls short of our needs in a few key areas:

  1.  The TEAC is intended to address time-sensitive inter-registrar transactions, not for the general public to raise complaints.
  2.  Our work would require a more general purpose point of contact for use by third parties, LEA, etc.
  3.  The issues raised will be less time sensitive, reasonable response times would likely be measured in business days rather than hours.
  4.  There would be some penalties for abuse of the contact (e.g. Blocking future requests)




Transfer Emergency Action Contact

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 ICANNCompliance 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 TEACcommunication and responses, and share copies of this documentation with ICANNand 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140514/cc655b8f/attachment-0001.html>

More information about the Gnso-ppsai-pdp-wg mailing list