Policy Development Process to Review the Transfer Policy

Policy Development Process to Review the Transfer Policy
Status:	Active
Issue Areas:	Tranfer Policy
Date Established:	February 20, 2021
Charter:	WG Charter
Workspace:	Community Wiki

The Policy Development Process to review Transfer Policy (PDPRTP) is a GNSO PDP initiated by the GNSO Council on February 18, 2021.

Focus and Charter Questions

The PDP Charter specifies that the Working Group "is to conduct a review of the Transfer Policy and determine if changes to the policy are needed to improve the ease, security, and efficacy of inter-registrar and inter-registrant transfers." The Final Issue Report identified questions and issues related to eight topics:

1. Gaining & Losing Registrar Form of Authorization (“FOA”);
2. AuthInfo Code Management;
3. Change of Registrant;
4. Transfer Emergency Action Contact (“TEAC”);
5. Transfer Dispute Resolution Policy (“TDRP”);
6. Reversing/NACKing Transfers;
7. ICANN-Approved Transfers; and
8. Recommendation 27 of the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP), as it relates to FOA, change of registrant, and TDRP proceedings.

The working group divided the work into phases:

• Phase 1(a) - FOA and AuthInfo Codes, and EPDP Temp Spec Recommendation 27 re: FOA;
• Phase 1(b) - Change of Registrant and EPDP Temp Spec Recommendation 27 re: change of registrant issues;
• Phase 2 - Transfer Emergency Action, Reversing Transfers, Denying (NACKing) Transfers, ICANN-Approved Transfers, TDRP, and EPDP Temp Spec Recommendation 27 re: TDRP

History and Work Progress

The Final Issue Report was presented to the GNSO Council in advance of their February council meeting. After initiation of the project at the February council meeting, the GNSO publicly launched the project at ICANN 70 with an introductory session. The session provided an overview of the issue areas, identified ways for community members to participate, and described the composition and sources of the Working Group membership.

Phase 1(a) Initial Report & Public Comment

The working group intends to publish its Phase 1(a) Initial Report in June 2022. As the working group investigated the issues and charter questions regarding FOA and AuthInfo codes, they identified terminology issues resulting from the Temporary Specification for gTLD Registration Data as well as overlapping terms referring to the same object.

• The group found numerous spellings, punctuated variants, and parallel terms for the concept of an "AuthInfo" code. Recommendation #6 in the Draft Initial Report suggests replacing all such terms with "Transfer Authorization Code."
• The Registrar Accreditation Agreement still contains references to "WHOIS Data," "Administrative Contact," and other terms specific to the WHOIS system. The working group recommended ensuring that the Transfer Policy utilize terms that could relate to still-relevant aspects of the RAA requirements, but that were more generic. They also recommended collapsing all references to a specific type of contact into a single term: "Registered Name Holder." The recommendation leaves open the option to retain legacy references to WHOIS-associated terms if there is a reason to do so.
• The recommendations, if accepted, would effectively eliminate "Form of Authorization" as a term of art. The working group recommended a series of notifications to and from the Registered Name Holder and the Registrar of Record, rather than FOAs.

Early drafts of the Initial Report contained a total of 22 recommendations in response to the charter questions:

1. Eliminate the requirement that the Gaining Registrar send a Gaining Form of Authorization;
2. Eliminate the requirement that the Losing Registrar send a Losing Form of Authorization;
3. Require the Registrar of Record to issue a Notification of Transfer Authorization Code (TAC) Provision to the Registered Name Holder within ten minutes of providing a TAC;
4. Require the Losing Registrar to send a Notification of Transfer Completion to the Registered Name Holder within 24 hours after the transfer is completed;
5. Replace "AuthInfo Code" and similar terms (Auth-Info Code, Auth-Code, transfer code) with "Transfer Authorization Code" (TAC) throughout the Transfer Policy;
6. Define "Transfer Authorization Code" as: "a token created by the Registrar of Record and provided upon request to the RNH or their designated representative. The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer."
7. Task ICANN org with the creation of minimum requirements for and components of the TAC;
8. Require Registries to validate that a TAC meets the minimum requirements when it is stored in the Registry system;
9. Secure the TAC process by: only generating a TAC upon request, securely storing the TAC in the Registry system using a one-way hash, and provide information regarding the timing of expiration of the TAC;
10. Affirm the Temporary Specification's requirement that the Registry Operator verify that the TAC is valid prior to allowing an inter-registrar transfer;
11. Require that each TAC be a "one-time use" code;
12. Maintain the existing requirement that registrars must provide a TAC within "five calendar days" of a request, but recommend changing the time limit to 120 hours for clarity.
13. Set a default Time to Live (TTL) for a TAC at 14 days, and allow the Registrar of Record to set the TAC to null before the expiration date upon request from the Registered Name Holder or by agreement between the Registrar of Record and the Registered Name Holder;
14. Clarify what terms are equivalent between the Transfer Policy and the current Registrar Accreditation Agreement by specifying (for example) that "WHOIS Data" and "Registration Data" are referring to the same thing;
15. Remove any reference to "Administrative Contact" or "Transfer Contact" and replace those terms with "Registered Name Holder" unless specifically indicated;
16. Establish a mandatory 30-day moratorium on transfers from the initial registration date;
17. Establish a mandatory 30-day moratorium on new transfers from the date of completion of an inter-registrar transfer;
18. Separate section I.A.3.7 of the Transfer Policy into two distinct sections, one containing the requirement that the Registrar of Record present their reason for denial of a transfer request, and the other specifying the permitted reasons for denial;
19. Update and refine the language of the permitted reasons for denial of a transfer request;
20. Update and revise some of the reasons that the Registrar of Record may deny a transfer request under the Transfer Policy so that they become circumstances under which the Registrar of Record must deny the transfer request;
21. Update and refine the language of the Transfer Policy's existing list of circumstances under which the Registrar of Record must deny a transfer request; and
22. Update and revise the Transfer Policy so that situations in which a Registrar may not deny a transfer request are instead situations in which the Registrar of Record must not deny such a request.

After circulation for review and comment within the Working Group, the deadline for suggestions or objections to the initial draft passed without any such suggestions on May 14, 2022. The Initial Report was scheduled to be presented during Prep Week of ICANN 74. The presentation focused on the deliberations and rationales of the working group and the recommendations and outputs of the initial report.

The WG received 34 submissions in response to its Initial Report of Phase 1(a). Many of the submissions concerned the elimination of the losing FOA and the replacement with notifications to the RNH (Preliminary Recommendations 2, 3, and 4), TAC time to live (Preliminary Recommendation 13), and transfer restriction after initial registration and inter-Registrar transfer (Preliminary Recommendations 16 and 17). These concerns were also discussed at ICANN 75.

Phase 1(b)

At ICANN 74, the working group turned its attention to Phase 1(b), change of registrant. Noting that the first charter question challenged the necessity of a continued Change of Registrant Policy, Jim Galvin first requested feedback on that question as a "threshold" issue prior to deliberating any of the details of the policy and related charter questions. The group consensus was that the policy was useful.

As of ICANN 76, the Working Group had produced the Phase 1A Initial Report, revised recommendations following the public comment period, and conducted preliminary deliberations on Phase 1B topics. The WG revised the project plan to account for newly-found dependencies between topics, consolidated work into a single phase, and planned an additional Initial Report to cover all topics and a single Final Report. The WG began discussing Phase 2 (now Group 2) topics in February 2023 and will return to Group 1 topics following the preliminary outputs of Group 2 topics.

Group 2 Topics

Transfer Emergency Action Contact (TEAC)

• Registrars must establish a Transfer Emergency Action Contact ("TEAC") for urgent communications relating to transfers. (Transfer Policy, Section I.4.6)
  • May be designated as a telephone number or some other real-time communication channel (Sec. I.4.6.1)
  • Must generate a non-automated response by a human representative of the Gaining Registrar (Sec. I.4.6.2)
  • Responses are required within 4 hours, although final resolution of the incident may take longer. (Sec. I.4.6.3)
  • Channel is reserved for Rrs, Rys, and ICANN org (Sec. I.4.6.2)
  • Records of communications for this channel must be retained and documentation must be shared with ICANN and Rys upon request

TEAC Objectives:

• 24/7 access to registrar technical support staff for emergencies
• Quickly reverse instances of domain name hijacking or transfer errors
• Ensure the registrar representative is empowered to take action on TEAC requests
• Policy violation for non-responsive registrars

Transfer Dispute Resolution Policy (TDRP)

Description:

• Designed for cases of invalid inter-registrar transfers, where registrars are unable to resolve the issue amongst themselves
• Must be filed by Registrar (not Rt) within 12 months of invalid transfer (TDRP Sec. 2.2)
• Decided by independent panelist(s) appointed by the Provider (TDRP, Sec. 1.3)
• Complainant must pay a fee to file a TDRP (may be transferred to the respondent in some instances) (TDRP, Sec. 3.3)
• Documentation of improper transfer is required (TDRP, Sec. 3.1, 3.2)
  

The WG decided that the TDRP should not include dispute resolution options for registrants, because adding a new class of parties to an already complex, technical process would overload it. The WG couldn't imagine how a loser-pays TDRP cost-recovery scheme would work when the dispute was between a legitimate registrant and a criminal. Therefore, they decided to create separate inter-registrant and inter-registrar transfer dispute-resolution processes and not to open the IRTP to registrant disputes.

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).