Page History

...

The Public Policy Forum for this issue is located at:  http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm.

Draft ALAC Comment on the Final Report on IRTP B PDP.

...

The original version, Version 1, is shown further down this page. Version 2 is the version taking into account comments that were received by email and in the comments box at the bottom of this page.

Version 2 / FINAL

The 2004 IRTP recognized systemic abuse by a number of accredited registrars, and removed some of the restrictions these registrars exploited to prevent inventory and recurring revenue loss through registrant initiated transfer to other registrars.  As policy, the IRTP is consistent with non-regulation of registrars, substituting registrant response to registrar abuse for accreditation enforcement.

The 2009 GNSO Council cited five issues when initiating the present PDP – the 2005 hijack of panix.com, the oldest dial-up ISP serving the New York City, an event a co-author of this draft was personally involved in, three additional minor issues relating to transfers initiated by parties other than registrants, and clarifying transfer denials.

The Final Report contains nine (9) recommendations. The ALAC has already commented on two of these recommendations and will re-iterate its comments for these two recommendations here:

Recommendation #1: the ALAC strongly supports the Emergency Action Channel.

With regard to the specific questions, we offer the following comments on several of the questions:

 - Within what timeframe should a response be received after an issue has been raised through the Emergency Action Channel (for example, 24 hours - 3 days has been the range discussed by the WG)?

>As a prime use of the Emergency Action Channel is to reverse domain hijacking, we support as short a period as practical. The target should be well under 24 hours.

 - What qualifies as 'a response'? Is an auto-response sufficient?

An automated response is not considered acceptable as it eliminates the intent of establishing communications between the registrars.

- Should there be any consequences when a response is not received within the required timeframe?

The Emergency Action Channel would have no meaning if there were not consequences to no response.  Consequences should include a provision for the registry unilaterally reversing the transfer and possibly fines.

- Is there a limited time following a transfer during which the Emergency Action Channel can be used?

We support a reasonably long period but have no specific suggestion. We defer to the registrars who regularly must respond to hijacking as to what time period they find acceptable.

- Who is entitled to make use of the Emergency Action Channel?

The Emergency Action Channel may be useful for a number of registrar issues. Those are likely outside the scope of this PDP, but other uses should not be precluded.

Since the publishing of the ALAC’s last response about Recommendation #1, some members have emitted concerns about the potential for creation of an attack vector on capable of de-accrediting any registrar lacking the resources to staff 24x7x365, consisting of an arbitrary collection of domains registered with the target registrar, followed by “emergency transfer requests” falling at 2am, weekends, holidays, and ICANN meetings.  The attack vector would be capable of compromising ICANN compliance, as it would be possible to generate a large number of failed “emergency transfer requests” involving a large number of registrars.

This possibility has not been discussed at length in the At-Large community, although some members hope that there will be process safeguards in place to prevent such an occurrence.

Recommendation # 2: the ALAC supports the concept of increased and improved registrant education. The ALAC, through its RALOs and ALSs can interact with users worldwide in ways that are both geographically close and culturally sensitive. Although it is not clear that the ALAC should be designated as the prime channel for such activities, The ALAC and At-Large may be considered one of the possible channels, factoring in the limited ICANN budget at its disposal for such activities and the limited control over volunteer time that it exercises.

In addition, the ALAC makes the following comments about the other recommendations contained in the Final Report:

Recommendation #3 is a WHOIS recommendation. It has doubtful place in a recommendation concerning the operational practice of registrars transferring registrations at the request of registrants.

Recommendation #4 is reasonable. The ALAC supports the preparation of an issues report to determine the range of practice the regulators and/or operators of other namespaces have determined are in the interests of their registrants.

Recommendation #5 proposes that losing registrars auto-ack transfers to registrants. The low cost to implement rational is not necessarily unbelievable, but the utility and necessity for the auto-ack is unstated.

Recommendation #6, a change to the current denial reason #6 language, is non-controversial. 

Recommendation #7 is predicated upon a review of the UDRP, and is therefore non-operative. 

Recommendation #8 offers no obvious benefits to registrants other than bulk registrants (domainers) and the segment of the registrar market engaged primarily in bulk transfer (domainer servicing registrars), and has not been deeply analyzed by the ALAC as to what its effect would be on Individual Registrants. In keeping this in mind, the ALAC would reserve its judgement.

Recommendation #9, a change to the current denial reason #7 language, is non-controversial.

...

Version 1 / Original Version by Eric Brunner Williams and Cintra Sooknanan, replaced by Version 2  

Summary: The Inter-Registrar Transfer Policy (IRTP) was implemented in 2004, prior to the explosion in accreditations driven by the Verisign drop pool and Add Grace Period exploits.

...