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.