AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

Comment Close
Date		Statement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number
09.05.2015

Proposed Implementation of GNSO PDP Recommendations on Inter-Registrar Transfer Policy (IRTP) Part C

No Statementn/an/an/an/an/an/a
Caitlin Tubergen
caitlin.tubergen@icann.org
n/a


For information about this PC, please click here 

Brief Overview

The public comment proceeding seeks to obtain community input on the proposed implementation of the Generic Names Supporting Organization (GNSO) Policy Development Process (PDP) recommendations on the Inter-Registrar Transfer Policy (IRTP) Part C.

Section I: Description, Explanation, and Purpose

In consultation with the GNSO Implementation Review Team, which was formed as directed by the GNSO Council to work with ICANN to ensure that the resultant implementation fulfills the intentions of the approved policy recommendations, ICANN reviewed the IRTP and has proposed revisions which include amongst others:

  • adding a new provision which outlines the rules and requirements for a change of registrant of a domain name registration.
  • updating to the IRTP to include time limiting the Form of Authorization (FOA) for inter-registrar transfer

The policy recommendations defined a “Change of Registrant” to be a material change to any of the following:

  1. Registrant name
  2. Registrant organization
  3. Registrant email address

The policy recommendations contemplated the change of registrant process to involve multiple steps, which include:

  1. The prior and new registrant must authorize the change by using a unique, “change of registrant credential”.
  2. The registrar confirms that the both registrants have authorized the change and that the name is eligible for change of registrant, i.e., there is no lock or restriction on the name.
  3. The registrar performs the change.
  4. The registrar notifies the prior and new registrant that the requested change has been made.
  5. Following the change, the registrar places a 60-day inter-registrar transfer lock on the name.

The GNSO Implementation Review Team encountered the following challenges while discussing the change of registrant process, including,

  1. What constitutes a “material change” that would trigger the change of registrant process?
  2. How can the registrar transmit the change of registrant credential to the prior registrant?
  3. What alternative methods can be used to provide the credential if the prior registrant can no longer access its email address?

For the material change question, the draft Transfer Policy provides some guidelines of what would be considered a material change, e.g., non-typographical corrections, any change to a registered name holder’s email address, and other examples provided in Section II, 1.1(d) of the revised Transfer Policy.

With respect to transmitting the change of registrant credential, the draft Transfer Policy was drafted in a way to give registrars the freedom to adopt various secure methods of transmitting the change of registrant credential to the prior registrant while balancing security concerns mentioned during discussions with the GNSO Implementation Review Team.  As a result, the draft policy provides that the credential cannot be transmitted via a control panel unless the prior registrant and account holder are the same. In the event the prior registrant can no longer access its email address, phone number or address, the Registrar would not be limited to the use of contact information on file in providing the change of registrant credential.  
Please note that as a result of the proposed revisions of the Transfer Policy, the numbering and heading scheme has also been updated to take into account the new sections.

ICANN Staff and the GNSO Implementation Review Team are now looking for input on the proposed revisions to the Transfer Policy, which aims to satisfy the intent of the GNSO Policy Recommendations. Furthermore, any feedback on the expected time needed for affected parties to implement the revised Transfer Policy before coming into effect, would be appreciated.

Section II: Background

The Inter-Registrar Transfer Policy (IRTP) aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another should they wish to do so. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. The policy is an existing community consensus policy that was implemented in late 2004 and is now being reviewed by the GNSO.

The IRTP Part C Policy Development Process (PDP) is the third in a series of five PDPs that address areas for improvements in the existing transfer policy.

The GNSO Council resolved at its meeting on 22 September 2012 to launch a PDP to address the following three issues:

  1. "Change of Control" function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security.
  2. Whether provisions on time-limiting Form Of Authorization (FOA)s should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold theFOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed.
  3. Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.

The IRTP Part C Working Group published its Initial Report on 4 June 2012 in conjunction with the opening of a public comment forum (see section 6 for further details) followed by its Final Report on 9 October 2012. The ICANN Board adopted the recommendations of the IRTP Part C Working Group on 20 December 2012. The Implementation Review Team in conjunction withICANN staff worked together to develop a draft of the Transfer Policy. Community input is now sought on the updated Transfer Policy.

Section III: Relevant Resources

Section IV: Additional Information

Section V: Reports

Staff Contact

Caitlin Tubergen
caitlin.tubergen@icann.org

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 


FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

 

FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.

  • No labels

6 Comments

  1. Ariel Liang

    In July 2012, the ALAC submitted a Statement on the Inter-Registrar Transfer Policy (IRTP) Part C Policy Development Process Initial Report <https://community.icann.org/x/FQQQAg>: 

    The ALAC supports the general direction that the IRTP C PDP WG is heading. Specifically, the ALAC strongly supports all measures that will reduce the possibility of domain hijacking while still providing legitimate registrants the ability to change registrars.

    The ALAC similarly supports all efforts to formally define the process by which the registrant of record can be changed, with implicit safeguards to inhibit hijacking. The ALAC does not have strong views as to whether this needs to be a separate consensus policy or not, but the overall results and benefits to registrants should not be diminished by this decision.

    The ALAC supports the requirement to have all gTLDs use the IANA Registrar IDs (in addition to any proprietary ones if desired).

    Lastly, the report could benefit from a clearer overview describing the change of registrar and registrant processes.

    The ALAC didn't submit a Statement on the Final Report <https://community.icann.org/x/kIg3Ag>.

  2. Holly Raiche

    My recommendation is that ALAC really has nothing further to add other than what we commented on the initial report.  We should still support the proposed measures that support the ability of registrants to change registrars while formalising processes that will provide safeguards to inhibit hijacking - maybe one sentence just to say we support the report.

    The one thing we could say is to stress the need for a much clearer statement easily found on the website that describes the transfer process from the registrant perspective - it is not easy to find now and would be a complete mystery for those registrants who would like to know what processes will be followed if they want to change registrars.

    The one change between ITRP-C and IRTP-D was that in 'C', registrants could have been parties to the TDRP dispute process.  After a lot of discussion in the IRTP-D WG, this was changed so that they cannot now be parties to thoe disuptes. In the implementation of the IRTP-D, this issue should be followed up.

    1. Alan Greenberg

      Holly, I am a bit confused. The PC is asking specifically about how they have interpreted specific recommendations, where the wording was unclear or not sufficiently specific or did not contemplate certain circumstances. As I understand it, they are looking for comments on whether we believe that they have made reasonable choices.

  3. Holly Raiche

    Alan.   Having read the amended Transfer policy that incorporates  changes recommended by the IRTP-C WG, I think they pretty well reflect what the WG recommended.  So I still think the only thing we need to say (if at all) is that we think the proposed changes reflect what the WG recommended (and was accepted by the Board).

    Again, if we are to make any statement on this issue, it is that the actual transfer process is not easily understood, and that a simple (as much as is possible) explanation should be somewhere on the website so that registrants can understand the processes required in transferring registrars.

    So if we do comment, it should be two sentences:

    ALAC supports the changes  in the TRansfer Policy proposed by the Implementation WG.  ALAC recommends, however, that the GNSO itself, or through the implementation WG, develop an easily understood document for registrants on the processes to be followed if they wish to transfer registrars that is easily located on the ICANN website.

    1. Alan Greenberg

      Thanks Holly. I agree with the intent of what you are saying.

      • if all we are going to say on the implementation details is that we support it, then no statement is necessary.
      • For the lack of user-oriented documentation, sending that message may well be a good thing to do, but the staff who this PC is targeted at are not likely the correct people. If we do want to make such a recommendation, I suggest that we have At-Large Staff inquire as to where such a message should be sent.

      I think that this means we do not need a statement.

      1. Holly Raiche

        Hi Alan

        Agreed.

        And I do think it would be helpful for ICANN staff to follow up.  As you are aware, the transfer process is really complex, particularly with the safeguards that are being proposed.  So registrants really do need somewhere to go to understand the process - in plain English.