Team:

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)

Thanks—

J.



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.