[gnso-irtp-b-jun09] From the ICANN Compliance Newsletter: Registrar Compliance with IRTP

[Marika Konings <marika.konings@xxxxxxxxx>]

For your information, from the latest edition of the ICANN Compliance 
Newsletter 
(http://www.icann.org/en/compliance/archive/compliance-newsletter-201010-en.htm):

2. Registrar Compliance with Inter-Registrar Transfer Policy

Transfer problems most consistently top all consumer complaints received by 
ICANN. Usually, they represent 20-30 percent of complaints that ICANN 
processes. To address this issue, an IRTP Audit Plan was designed and developed 
by Contractual Compliance with input and feedback from a number of key 
registrar representatives and various ICANN departments and a beta test on the 
IRTP Audit Plan was conducted in May 2010.

Objectives:

The primary purpose of the beta audit is to determine if the IRTP Audit Plan is 
methodologically and operationally sound. It was also designed to:

 *   Gain a better understanding of the actual transfer problems encountered by 
consumers;
 *   Gauge the level of registrar compliance with the IRTP; and
 *   Raise registrar awareness of their obligations under the transfer policy 
and encourage future compliance.

Audit notices were sent to registrars who were subject to the beta-audit by 
both email and fax. A copy of the IRPT Audit Plan was attached to the audit 
notice.

Methodology:

Due to the vast number of transfers occurring each month and the large number 
of registrars involved, it was not feasible to examine each transfer 
transaction or each registrar’s transfer practices. Instead, random selection 
mechanisms were used to select four groups of registrars to be audited:

 1.  Transfer-losing-registrars with NACK rates exceeding 20% (maximum of 10 
registrars)
 2.  Transfer-gaining-registrars with NACK rates exceeding 40% (maximum of 5 
registrars)
 3.  Five registrars who received the most complaints by number
 4.  Five registrars who received the most complaints by ratio ( see the 
calculation set out in the IRTP Audit Plan)

Selection of groups 1 & 2 registrars was based on VeriSign’s transactional 
report for the month of December 2009, while selection of groups 3 & 4 
registrars was based on data from ICANN’s C-ticket system for the month of 
March 2010. Using these two sets of data and the selection mechanisms, a total 
of 17 registrars were subject to the beta audit.

The total number of domain names sponsored by these 17 registrars was 
71,491,626 (this represents 63% of total gTLD registrations of 113,802,218, as 
of 31 May 2010).

Findings:

Eight registrars provided the information on or before the deadline of 24 May 
2010, while others required one or two reminders. By 4 June 2010 all provided 
the information requested. All but one registrar were requested to provide 
ICANN with additional clarifications or information.

The table below is a summary of the findings based on the 4 registrar groups:

Group   Description     Registrars Audited      Transfers/ Complaints Selected 
per Registrar    Registrars Deemed Compliant*    Registrars Deemed 
Non-compliant Compliant registrars by % in Group
1       Losing  4       10 or actual    2       2       50%
2       Gaining 5       10 or actual    5       0       100%
3       Complaints by number    4       5       2       2       50%
4       Complaints by ratio     4       5       3       1       75%

A registrar is deemed compliant if each of its transfer transactions that were 
subject to the audit was considered in compliance with the IRTP.

Of 119 transfer transactions reviewed, 27 were deemed non-compliant with the 
IRTP. This translates to 77% of transactions being compliant.

Most transfer-related complaints that were subject to the beta audit concerned 
either delays/inabilities to obtain the AuthInfo Code, or domains still locked 
by the registrar of record. The problems seem more prevalent when resellers are 
involved.

Based on the response provided by groups 3 & 4 registrars, ICANN noted that 
some of the delays were caused by authentication or validation processes 
employed by registrars. ICANN recognizes the need for authentication of the 
Registered Name Holder who requested the AutoInfo Code, but registrars must 
also be mindful of their obligation to provide the Code within five calendar 
days of the initial request.

They must also ensure that they do “not employ any mechanism for complying with 
a Registered Name Holder's request to obtain the applicable “AuthInfo Code” 
that is more restrictive than the mechanisms used for changing any aspect of 
the Registered Name Holder's contact or name server information” (see paragraph 
5 of the IRTP).

Follow-up Actions:

ICANN has stated in its beta audit notice to registrars that “the findings of 
these beta-test audits are for information only and will not be used as the 
basis for enforcement action.”

Accordingly, ICANN does not intend to take “formal” compliance or enforcement 
action against those registrars that are deemed non-compliant with the IRTP or 
the RAA but Contractual Compliance staff has informed them of their 
non-compliance and worked with them to help bringing them into compliance with 
their IRTP obligations.

In addition, the beta audit has alerted a number of registrars about the 
deficiencies in their business practices and processes. Additional 
investigations may occur. The beta-audit has prompted a number of registrars to 
take the initiative of reviewing and/or improving their transfer practices.

Below are some of the comments received from registrars:

Comment from a group 1 registrar:

“Your beta testing request alerted us to the high rate of Nack in December 2009 
…our use of Nacking was not compliant with ICANN IRTP in December 2009. We have 
now reviewed our current procedures in order to correct this situation.”

Comments from two group 2 registrars:

“..., this process has highlighted to me some weaknesses in how we maintain 
this information.”

“The audit exercise has highlighted a couple of issues for us:

 *   The way that our data records are labeled (we gave you invalid details as 
a result)
 *   The way that our system automatically re-attempts to transfer a domain 
that has been NACKed. (We shouldn’t be doing this).

I am actively addressing both of these issues within our organization to 
rectify immediately. ”

Comments from two group 3 registrars:

“We have paid close attention to this matter and discussed the measures to let 
our transfer policy to comply with the ICANN Inter-Registrar Transfer Policy. 
There may be a period for us to make a new transfer policy and adjust our 
system.”

“If our transfer process as described above needs change or improvement, please 
let us know and we will do our upmost to become compliant as soon as possible.”

Comment from a group 4 registrar:

“We will introduce a “3 strikes, you are out reseller policy” to make sure our 
resellers respond to customers’ requests for EPP codes in time, as required by 
the IRTP.”

Further changes to IRTP Audit Plan after the beta audit and formal audits:

A registrar in group 1 suggested some changes to the requested 
documents/information (as set out in the IRTP Audit Plan). ICANN will 
incorporate those suggestions, in addition to some changes for clarity in light 
of registrars’ responses to the beta audit. ICANN plans to conduct two rounds 
of formal audit in accordance with the updated IRTP Audit Plan, with one during 
the remainder of 2010 and one in the first half of 2011.