View source for Policy Development Process to Review the Transfer Policy

{{ICANN Working Group
|Organizer=GNSO
|Type=
|Status=Active
|Issue Areas=Tranfer Policy
|Process=
|Date Established=February 20, 2021
|Charter=https://community.icann.org/display/TPRPDP/2.+WG+Charter
|Workspace=https://community.icann.org/display/TPRPDP
}}
The '''Policy Development Process to review Transfer Policy (PDPRTP)''' is a [[GNSO]] [[PDP]] initiated by the [[GNSO Council]] on February 18, 2021.<ref>[https://community.icann.org/display/gnsocouncilmeetings/Motions+18+February+2021 GNSO Council Meeting Motions], Febrary 18, 2021</ref> 

==Focus and Charter Questions==
The [[Policy Development Process Charter|PDP Charter]] specifies that the [[Working Group]] "is to conduct a review of the [[Inter-Registrar Transfer Policy|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."
<ref name="draftcharter">[https://gnso.icann.org/en/drafts/draft-charter-pdp-transfer-policy-review-12mar21-en.pdf GNSO - Draft Charter, PDPRTP], March 12, 2021]</ref> The [[Final Issue Report]] identified questions and issues related to eight topics:

#Gaining & Losing Registrar [[Form of Authorization]] (“FOA”);
#[[AuthInfo Code]] Management;
#Change of [[Registrant]];
#[[Transfer Emergency Action Contact]] (“TEAC”);
#[[Transfer Dispute Resolution Policy]] (“TDRP”);
#Reversing/[[NACK]]ing Transfers;
#ICANN-Approved Transfers; and
#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.<ref name="fir">[https://gnso.icann.org/sites/default/files/file/field-file-attach/final-issue-report-pdp-transfer-policy-review-12jan21-en.pdf GNSO - Final Issue Report on a PDP to Review the Transfer Policy], February 20, 2021</ref>

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<ref>[https://community.icann.org/download/attachments/167543675/TPR%20Initial%20Report%20Draft%20-%2029%20April%202022.pdf PDP Transfer Policy Draft Initial Report, Phase 1(a)], April 29, 2022</ref>

==History and Work Progress==
The Final Issue Report was presented to the GNSO Council in advance of their February council meeting.<ref>[https://community.icann.org/download/attachments/157188391/Transfer%20Policy%20-%20Final%20Issue%20Report%20Webinar%20-%201%20Feb%202021%20-%20Final.pdf PDPRTP - Final Issue Report Webinar], February 20, 2021</ref> After initiation of the project at the February council meeting, the GNSO publicly launched the project at [[ICANN 70]] with an introductory session.<ref>[https://70.schedule.icann.org/meetings/w6oKZ4aZbisQE8kyE ICANN 70 - GNSO Introduction: PDP to Review Transfer Policy], March 22, 2021 (login required)</ref> 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.<ref>[https://cdn.filestackcontent.com/content=t:attachment,f:%22Transfer%20Policy%20PDP%20-%20ICANN70%20-%20Final.pptx%20(1).pdf%22/GoFEFpcRfWVQ5sP97ZiA ICANN 70 - GNSO Slides from Introductory Session], March 22, 2021</ref>

===Phase 1(a) Initial Report & Public Comment===
The working group intends to publish its Phase 1(a) Initial Report in June 2022.<ref>[https://community.icann.org/pages/viewpage.action?pageId=176622934 PDP Transfer Policy Review Workspace - Action Items & Work Plan], last updated November 2021</ref> 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.<ref name="1adraftIR">[https://community.icann.org/display/TPRPDP/Working+Documents?preview=/167543675/197263958/TPR%20Initial%20Report%20Draft%20-%2029%20April%202022.pdf Transfer Policy Review PDP - Draft Initial Report], April 20, 2022</ref> 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:
# Eliminate the requirement that the Gaining Registrar send a Gaining Form of Authorization;
# Eliminate the requirement that the Losing Registrar send a Losing Form of Authorization;
# 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;
# Require the Losing Registrar to send a Notification of Transfer Completion to the Registered Name Holder within 24 hours after the transfer is completed; 
# Replace "AuthInfo Code" and similar terms (Auth-Info Code, Auth-Code, transfer code) with "Transfer Authorization Code" (TAC) throughout the Transfer Policy;
# 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."
# Task ICANN org with the creation of minimum requirements for and components of the TAC; 
# Require Registries to validate that a TAC meets the minimum requirements when it is stored in the Registry system;
# 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;
# Affirm the Temporary Specification's requirement that the Registry Operator verify that the TAC is valid prior to allowing an inter-registrar transfer;
# Require that each TAC be a "one-time use" code;
# 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.
# 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;
# 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;
# Remove any reference to "Administrative Contact" or "Transfer Contact" and replace those terms with "Registered Name Holder" unless specifically indicated;
# Establish a mandatory 30-day moratorium on transfers from the initial registration date;
# Establish a mandatory 30-day moratorium on new transfers from the date of completion of an inter-registrar transfer;
# 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;
# Update and refine the language of the permitted reasons for denial of a transfer request;
# 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;
# 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 
# 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.<ref name="1adraftIR" /><ref>[https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit Transfer Policy Review PDP - Summary of Preliminary Recommendations] (Google Doc)</ref>

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.<ref>[https://mm.icann.org/pipermail/gnso-tpr/2022-May/000450.html Email from ICANN staff to PDP-TPR Listserv], May 12, 2022</ref> The Initial Report was scheduled to be presented during [[Prep Week]] of [[ICANN 74 - The Hague|ICANN 74]].<ref>[https://www.icann.org/en/announcements/details/icann74-prep-week-schedule-now-available-16-05-2022-en ICANN.org Blog - ICANN 74 Prep Week Schedule Now Available], May 16, 2022</ref> The presentation focused on the deliberations and rationales of the working group and the recommendations and outputs of the initial report.<ref>[https://74.schedule.icann.org/meetings/R6mxL9aTrm6NNWj3f ICANN 74 Archive - Initial Report of GNSO Transfer Policy Review], June 2, 2022</ref>

The WG received 34 submissions in response to its Initial Report of Phase 1(a).<ref>[https://itp.cdn.icann.org/en/files/inter-registrar-transfer-policy-irtp/summary-report-initial-report-transfer-policy-review-phase-1a-30-08-2022-en.pdf Phase 1(a) Public Comment Summary Report, ICANN Files]</ref> 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]].<ref>[https://75.schedule.icann.org/meetings/hNdkMxTP2FLu93z6h Transfer Policy Review Working Sessions, ICANN75]</ref>

===Phase 1(b)===
At [[ICANN 74]], the working group turned its attention to Phase 1(b), change of registrant.<ref name="74wg">[https://74.schedule.icann.org/meetings/exSok5N3N9WTCM4LH ICANN 74 Archive - GNSO Transfer Policy Review PDP Working Group], June 13, 2022</ref> 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.<ref name="74wg" /> The group consensus was that the policy was useful.<ref name="74wg" />

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.<ref>[https://community.icann.org/display/TPRPDP/2023-03-11+ICANN76+Transfer+Policy+Review+PDP+WG+Call Transfer Policy Review WG Session, ICANN 76]</ref>

===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 ﬁnal 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)<br/> 
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.

==References==
{{reflist}}

[[Category:PDPs]]