Following is the draft ALAC Statement on the Inter-Registrar Transfer Policy (IRTP) Part B Policy Development Process (PDP) Recommendations for Board Consideration. This draft is by Eric Brunner-Williams and Cintra Sooknanan.
At-Large members are asked to comment using the "Add Comment" function at the bottom of this page. The deadline for these comments is 12:00 UTC on 11 August 2011.
The Public Policy Forum for this issue is located at: http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm.
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.
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.
Broadly, the “use case” pursued by the PDP has been the fractional percent of registrations which have sufficient value to attract third-party attack. Like the original IRTP, the policy does not, by design, encompass the vastly larger volume of registrations that have sufficient value to attract bulk second-party attack – aka abusive registrar conduct. It is therefore, nearly irrelevant to the public interest, except where critical public infrastructure, such as panix.com, are the targets of third-party attack, and theft of service is not adequately prevented by law.
The Final Report contains nine (9) recommendations.
Recommendation #1 calls for the creation of a transfer contact at each registrar. The recommendation is fact adverse as 600 or more of the 900 current accreditations are held by shell registrars who’s inventories are of no interest whatsoever, and the recommendation does not identify the class or registrars for which an improvement on the 2004 IRTP is possibly useful, or the class of registrations for which an improvement on the 2004 IRTP is possibly useful.
Recommendation #1 then calls for registrars to be obliged to act, within 4 hours, of notice to this contact address. This creates an attack vector 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 is capable of compromising ICANN compliance, as it is trivially possible to generate a large number of failed “emergency transfer requests” involving a large number of registrars.
Basically, this is stupid policy that can only harm small registrars, to the benefit of large registrars, dressed up in security theatrics. It amounts to a covert modification of the RAA to add a minimum capitalization requirement, while making no minimal service offer to the remainder of the registrants who have not chosen to select, or transfer to, one of the four registrars now holding one half of all gTLD registrations.
Recommendation #2 attempts to co-opt the ALAC into identifying business asset management practices as a means to detect and prevent isolated third-party attack and overlook the perennial problem of bulk second-party attack – aka abusive registrar conduct. The ALAC declines. The protection of critical infrastructure, such as ISPs as registrants – the panix.com case – is worth ALAC investment. The protection of other, private “high value” registrations is not, in itself, sufficiently in the public interest to be worth ALAC investment.
Recommendation #3 is ICANN kudzu, a WHOIS recommendation. It has no place in a recommendation concerning the operational practice of registrars transferring registrations at the request of registrants.
Recommendation #4 is actually reasonable, 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 loosing 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 benefits to registrants other than bulk registrants (domainers) and the segment of the registrar market engaged primarily in bulk transfer (domainer servicing registrars), and is therefore not in the public interest and not supported by the ALAC.
Recommendation #9, a change to the current denial reason #7 language, is non-controversial.
