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.

  • No labels

6 Comments

  1. Without commenting on the substance, I note that this statement is pretty much a complete reversal of the position that the ALAC took on the draft IRTP B Report. In the interest of full disclosure, I was the prime author of the last comment. That does not make it any more right than this one, but if the ALAC is going to reverse its position, it should be done in full awareness that this is what it is doing. I note that the Board effectively reversed its position on VI, so such moves are not unheard of in ICANN.

    You can find the wiki site where the last comments was drafted at  https://community.icann.org/x/JAG3 and the final comment at http://forum.icann.org/lists/irtp-b-proposed-final-report/msg00003.html.

  2. Firstly =>
    If and when piece of ALAC Advice given/published as Statement and/or Public Comment contradicts in whole OR Part any previous Advice it should NOT go to vote without going through an "informed" ALAC discussion on the point(s) that it contradicts/changes =>

    ALACs' (and their Opinions) do change sure they need to! BUT it is because they change (in terms of both personne and opinion/reaction to current conditions etc.,) that a 'Statement / Position Change' needs to be not only fully discussed and IF required suitably agreed to then BOTH the change and the rationale for it (and arguably the process used for that changes development) should be highlighted in the Staff Intro /cover sheet if not/also in the main body of the text where the 'New View' is listed/outlined...

    Secondly =>
    Our previous Comment/Statement on the Final Report focused on Recommendations 1 & 2 and I for 1 as an ALAC Member and as an active APRALO Rep see No reason or motivation from my RALO to change from what we said on these points in only March this year (which Alan has referenced and linked in the comment above) => i.e. (italics added by me as they would be IMO re quoted in new text style for this current response)

    "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. "

    and

    "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._"

    Thirdly =>
    To the rest of the Recommendations and the draft response  my edits comments are in line below <CLO> :-

    Recommendation #3 is ICANN kudzu, a WHOIS recommendation. It has no doubtful place in a recommendation concerning the operational practice of registrars transferring registrations at the request of registrants.   <CLO> Agreed with edits

    Recommendation #4 is actually reasonable, 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.   <CLO> Agreed with edit

    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.   <CLO> OK others may wish to expand more however...

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

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

    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. <CLO> I would need to have this either discussed more by ALAC (as I have heard no such prior discussion or advice in from RALO's/ALSes on this to indicate unilateral support for a not in public interest stand; But I could/would agree to a text that is 'simplified to' "#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 analysed by the ALAC as to any effect on Individual Registrants etc.,."

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

    Finally  =>

    If  ALAC does wish to adopt the new stance on Rec 1 & 2  then  use of words like  "stupid"  would need to be edited out  for me OR my RALO to even consider discussion let alone supporting.

  3. I may add some further thoughts on a number of these later, but I would like to address Rec# 8 now. Specifically, perhaps I am working in a fog, but I don't understand the relationship between Rec# 8 and the proposed comment.

    Recommendation #8: The WG recommends standardizing and clarifying WHOIS status messages regarding Registrar Lock status. The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Based on discussions with technical experts, the WG does not expect that such a standardization and clarification of WHOIS status messages would require significant investment or changes at the registry/registrar level. The WG recommends that ICANN staff is asked to develop an implementation plan for community consideration which ensures that a technically feasible approach is developed to implement this recommendation.

    Comment: 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.

    How does standardizing and clarifying WHOIS status messages relate to bulk transfers?

    1. Alan your not in a Fog (though I may be) at all please propose updated edit text from mine to effect that observation if you would be so kind....

  4. A reply from Eric Brunner Williams to some of the early points made by Alan (written prior to the comments by Cheryl Langdon Orr):
    Olivier,

    Thanks for providing the link to the comment Alan drafted previously.

    As a process comment, information as to prior statements on the same
    subject matter may be provided before a subsequent drafting exercise
    rather than after, which may reduce the necessity and utility of any
    subsequent draft.

    The prior text errs in associating general necessity for a mechanism to
    respond to third-party seizure of domains. The presenting problem, the
    hijacking of panix.com, is not a general problem. The interests of
    registrars, trademark holders as registrants, and trademark infringers
    as registrants, in modifications to the IRTP, are not a general registrant
    interest.

    While "Individuals who register domain names" often do "have little
    technical or domain-industry knowledge and are ill-prepared to deal
    with hijacking or the subtleties of domain name transfer", the value
    of their domains is generally insufficient to motivate third-party
    seizure, and therefore they are not "the registrants who are most
    vulnerable to problems being addressed in this PDP".

    While the prior text did not consider the public interest ab initio,
    the prior text also errs in failing to associat a general necessity for
    a mechanism to respond to bulk second-party attack where the margin of
    extracted value is a multiple or less than the wholesale price, or to
    rank the harm to the public interest purported by the authors of the
    IRTP-B text, and the harm to the public interest those authors chose
    to overlook.

    Next, the prior text is indifferent to the consequence of consolidation
    through the any 4 hour period within any 24x7x365 response cost. If we
    could agree that competition does not benefit registrants (contrary to
    the received wisdom in the Chicago School law and economics subculture)
    or that all registrars are equally bad and therefore consolidation is
    harmless, or that the intentional exploit of "2am notice" to construct
    compliance issues where no problem in fact exists was adequately
    prevented, this indifference would be harmless.

    In sum, the earlier draft accepts uncritically the necessity and
    utility of the recommendations of the IRTP-B authors, and identifies
    the interest of the IRTP-B authors with the general interests of
    registrar. If there was data sufficient to support the assumption
    that a significant portion of registrants who are neither domainers
    nor brand managers nor critical infrastructure operators were the
    targets of trasfer abuse, or data sufficient to support the assumption
    that a significant portion of registrants who are neither domainers
    nor brand managers nor critical infrastructure operators elect, sui
    sponte, to initiate transfers, and are therefore have interests
    compatible with the interests of the IRTP-B authors, it might be a
    comment made in the public interest.

    I suggest this is more of a consequence of hurried response than of
    anything else, and in drafting our comment, I know I didn't, and I
    don't think Cintra had, the opportunity to look for or at any prior
    ALAC comment or mail on this one of many, many GNSO C response issues.
    Having spent all of the years from 1998 to the present except for the
    last year engaged in the GNSO policy, I recognize how universal these
    seem to be to those directly engaged in them, but the user interests
    actually have not generally been represented by the constituencies.

    In closing I point out that I, and Cintra, provided the comments of
    one or two members of RALOs with some knowledge of and interest in
    the registrar functional area. What text the ALAC Executive chooses
    to offer to inform the Board as to the public interest in this or
    any question is the responsiblity of the ALAC Executive.

  5. Anonymous

    Comment from Danny Younger

    Regarding Recommendation #3:  The Working Group justified its recommendation with the following language:

    "The WG recommends requesting an Issues Report on the requirement of ‘thick’ WHOIS for all incumbent gTLDs. The benefit would be that in a thick registry one could develop a secure method for a gaining registrar to gain access to the registrant contact information. Currently there is no standard means for the secure exchange of registrant details in a thin registry. In this scenario, disputes between the registrant and admin contact could be reduced, as the registrant would become the ultimate approver of a transfer. Such an Issue Report and possible subsequent Policy Development Process should not only consider a possible requirement of 'thick' WHOIS for all incumbent gTLDs in the context of IRTP, but should also consider any other positive and/or negative effects that are likely to occur outside of IRTP that would need to be taken into account when deciding whether a requirement of 'thick' WHOIS for all incumbent gTLDs would be desirable or not."

    I fail to understand why the ALAC would choose to disparage this WG recommendation that acts to deal with a long-recognized and long-standing problem.  What possible harm could accrue from obtaining an Issues Report on this subject?