Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Initial Report on the Transfer Policy
Review Policy Development Process Phase 1(a)Status of This Document
This is the Phase 1(a) Initial Report of the GNSO Transfer Policy Review
Policy Development Process Working Group that has been posted for Public
Comment.

Preamble
The objective of this Initial Report is to document the working group’s (i)deliberations on charter questions, (ii) preliminary recommendations, and(iii) additional identified issues to consider before the working group issues
its Final Report. After the working group reviews Public Comment
submissions received in response to this report and completes Phase 1(b)of the PDP, the working group will submit its combined Phase 1 Final
Report to the GNSO Council for its consideration.

Page 1 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Table of Contents
Table of Contents
1 EXECUTIVE SUMMARY

32 WORKING GROUP APPROACH

7

3 WORKING GROUP RESPONSES TO CHARTER QUESTIONS ANDPRELIMINARY RECOMMENDATIONS

11

4 NEXT STEPS41

ANNEX A - BACKGROUND

42

ANNEX B - WORKING GROUP MEMBERSHIP AND ATTENDANCE44

ANNEX C - COMMUNITY INPUT

48

ANNEX D – EPDP PHASE 1, RECOMMENDATION 27, WAVE 1 ANALYSIS 49
ANNEX E – PROPOSED TRANSFER POLICY SWIM LANE DIAGRAM

55

Page 2 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

1 Executive Summary
1.1 Introduction
The Transfer Policy, formerly referred to as the Inter‐Registrar Transfer Policy (IRTP), isan ICANN consensus policy that went into effect on 12 November 2004. The policy
governs the procedure and requirements for registrants to transfer their domain names
from one Registrar to another, also referred to as an inter-Registrar transfer. The goal of
the Transfer Policy was to provide for enhanced domain name portability, resulting in
greater consumer and business choice and enabling registrants to select the Registrar
that offers the best services and price for their needs.
The Transfer Policy has been the subject of previous policy development work, and themost recent working group that reviewed the Transfer Policy recommended acomprehensive review of the policy-based changes to assess their efficacy and impact.1
In addition to the policy recommendation directing a review of the policy-basedchanges, sweeping and significant changes to various data privacy laws affected thethen current requirements related to gTLD registration data, including portions of theTransfer Policy. Accordingly, the ICANN Board adopted the Temporary Specification for
gTLD Registration Data, which established temporary requirements that allowed
Contracted Parties to comply with ICANN contracts and consensus policies.
In light of the policy recommendation to review the Transfer Policy and the changes to
the Policy from the Temporary Specification, on 18 February 2021, the GNSO Council
initiated a two-phased policy development process (PDP) to review the Transfer Policy.
The PDP is tasked with addressing the following topics:•••

Phase 1(a): Form of Authorization (FOA) (including EPDP Phase 1,
Recommendation 27, Wave 1 FOA issues2) and AuthInfo Codes
Phase 1(b): Change of Registrant (including EPDP Phase 1, Recommendation 27,
Wave 1 Change of Registrant issues)
Phase 2: Transfer Emergency Action Contact and reversing inter-Registrartransfers, Transfer Dispute Resolution Policy (including EPDP Phase 1,

1 See Final Report on the Inter-Registrar Transfer Policy - Part D Policy Development Process,Recommendation 17, pp. 6-7. For more information on the policy development history, please refer toAnnex A of this report.
2 For additional information about the EPDP Phase 1, Recommendation 27, Wave 1 Report, please see
pages 52-56 of the Final Issue Report.

Page 3 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Recommendation 27, Wave 1 TDRP issues), Denying (NACKing) transfers3,
ICANN-approved transfers
The working group charter was approved by the GNSO Council on 24 March 2021. The
Phase 1(a) working group held its first meeting on 14 May 2021.
For additional background on this PDP, please refer to Annex A of this report.

1.2 Preliminary Recommendations
In Phase 1(a) of the PDP, the working group was tasked to provide the GNSO Council
with recommendations on the following topics:••••

Losing and Gaining FOAs
AuthInfo Codes
Denying (NACKing) transfers
EPDP Phase 1, Recommendation 27, Wave 1 as they relate to FOA

Following its analysis of each of the questions outlined in its charter related to this task,
the working group has arrived at a set of preliminary recommendations and conclusions.
The working group will not finalize its responses to the charter questions andrecommendations to the GNSO Council until it has conducted a thorough review of thecomments received during the Public Comment period on this Initial Report andcompleted Phase 1(b) of its work. At this time, no formal consensus call has been takenon these responses and preliminary recommendations, but this Initial Report did receive
the support of the working group for publication for Public Comment.
Notwithstanding the above, the working group is putting forward preliminary
recommendations on the following topics for community consideration:
Preliminary Recommendation 1:

Gaining FOA

Preliminary Recommendation 2:

Losing FOA

Preliminary Recommendation 3:

Notification of TAC Provision

3 The topic of denying (NACKing) transfers was later moved to Phase 1(a) by a Project Change Request toensure that the working group could examine all elements of the security model for domain nametransfers in a holistic manner as part of its Phase 1 deliberations.

Page 4 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Preliminary Recommendation 4:

Notification of Transfer Completion

Preliminary Recommendation 5:

Update Term “AuthInfo Code” to “Transfer
Authorization Code (TAC)”

Preliminary Recommendation 6:

TAC Definition

Preliminary Recommendation 7:

TAC Composition

Preliminary Recommendation 8:

Verification of TAC Composition

Preliminary Recommendation 9:

TAC Generation, Storage, and Provision

Preliminary Recommendation 10:

Verification of TAC Validity

Preliminary Recommendation 11:

TAC is One-Time Use

Preliminary Recommendation 12:

Service Level Agreement (SLA) for TAC Provision

Preliminary Recommendation 13:

TAC Time to Live (TTL)

Preliminary Recommendation 14:

Terminology Updates: Whois

Preliminary Recommendation 15:

Terminology Updates: Administrative Contact andTransfer Contact

Preliminary Recommendation 16:

Transfer Restriction After Initial Registration

Preliminary Recommendation 17:

Transfer Restriction After Inter-Registrar Transfer

Preliminary Recommendation 18:

Format of Transfer Policy Section I.A.3.7

Preliminary Recommendation 19:

Revised Reasons that a Registrar of Record MAY
Deny a Transfer

Preliminary Recommendation 20:

New Reasons that a Registrar of Record MUST
Deny a Transfer

Preliminary Recommendation 21:

Revised Reasons that a Registrar of Record MUST
Deny a Transfer

Preliminary Recommendation 22:

Revised Reasons that a Registrar of Record MUSTNOT Deny a Transfer
Page 5 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

1.3 Conclusions and Next Steps
This Initial Report will be posted for Public Comment for 42 days. The working group will
review the Public Comments received on this Initial Report and consider whether any
changes need to be made to its Phase 1(a) recommendations. The working group willcomplete Phase 1(b) of its work, including a Phase 1(b) Initial Report followed by a
Public Comment period on the Phase 1(b) Initial Report. The working group will finalize
all Phase 1 recommendations in a single Phase 1 Final Report to be sent to the GNSO
Council.

1.4 Other Relevant Sections of this Report
The following sections are included within this report:◼

Explanation of the working group’s methods and process
for reaching preliminary recommendations;◼

Responses to the charter questions, preliminary
recommendations, and questions for community input;◼

Background on the PDP and issues under consideration;◼

Documentation of who participated in the working
group’s deliberations, including attendance records, andlinks to Statements of Interest as applicable;◼

Documentation on the solicitation of community input
through formal Supporting Organization/Advisory
Committee and Stakeholder Group/Constituency
channels and responses.

◼

A swim lane diagram documenting the possible futurestate process flow for inter-Registrar transfers as it will
exist if all recommendations are approved andimplemented. Note that this diagram is a working
product of the deliberations process to support
understanding of the recommendations’ impact. It is notintended to be authoritative.

Page 6 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

2 Working Group ApproachThis section provides an overview of the working methodology and approach of theworking group. The points outlined below are meant to provide the reader with relevant
background information on the working group’s deliberations and processes and should
not be read as representing the entirety of the efforts and deliberations of the working
group.

2.1 Project Plan
The working group’s first deliverable was to provide the GNSO Council with a Phase 1(a)project plan. To develop the project plan, the leadership team sought input frommembers about the sequence in which to address topics and the amount of time each
topic would take to discuss. This input was used to develop the project plan, which wasdelivered to the GNSO Council for its consideration during the 22 July 2021 Council
meeting.
As deliberations progressed, the working group agreed that it was important to examine
all elements of the security model for domain name transfers in a holistic manner aspart of its Phase 1 deliberations. The working group determined that the topic denying(NACKing) transfers should be addressed in Phase 1(a) rather than Phase 2 as originally
included in the charter. As a result, the working group leadership team submitted a
Project Change Request to the GNSO Council, which Council adopted on 16 December
2021. The expanded scope did not impact its target delivery dates to which the working
group committed.

2.2 Early Community Input
In accordance with GNSO policy development process requirements, the working groupsought written input on the charter topics from each Supporting Organization, Advisory
Committee and GNSO Stakeholder Group / Constituency. The input received wasincorporated into the working group’s deliberations as each topic was discussed. Since
all groups that provided written input also had representative members or appointed
subject matter experts in the working group, those members were well positioned torespond to clarifying questions from other members about the written input as it wasconsidered.

2.3 Methodology for Deliberations

Page 7 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

The working group began its deliberations for Phase 1(a) on 14 May 2021. The working
group agreed to continue its work primarily through conference calls scheduled weekly,in addition to email exchanges on its mailing list. The working group held sessions during
ICANN71, ICANN72, ICANN73, and ICANN74. These sessions provided an opportunity forthe broader community to contribute to the working group’s deliberations and provide
input on the charter topics being discussed.
All of the working group’s work is documented on its wiki workspace, including its
meetings, mailing list, meeting notes, deliberation summaries, draft documents,
background materials, early input received from ICANN org, and input received fromICANN’s Supporting Organizations and Advisory Committees, including the GNSO’s
Stakeholder Groups and Constituencies.
To develop the content included in the Initial Report, the working group progressed
through the charter questions by topic, following the sequence established in the
project plan. Because the Phase 1(a) topics are closely interrelated, the working group
took an iterative approach to producing and reviewing draft responses to charter
questions and draft preliminary recommendations to ensure that the full package of
outputs was coherent and comprehensive.
To ensure that all groups represented in the working group had ample opportunity toprovide input to the deliberations, the leadership team opened each working groupmeeting with an invitation for members to step forward and provide any updates about
discussions happening within their Supporting Organization/Advisory
Committee/Stakeholder Group/Constituency regarding the charter topics, as well as any
positions or interests members wanted to share on behalf of their groups. To further
support fulsome discussion, the leadership team regularly deployed informal polls in themeeting Zoom room to get a better sense of the “temperature of the room” and toprompt the sharing of perspectives and viewpoints that may not otherwise be voiced
through less structured interaction.
For those working group members who were less comfortable speaking on calls, theleadership team encouraged additional feedback on the mailing list and through written
contributions to working group documents.

2.4 Use of Working Documents
The working group used a series of working documents, organized per charter topic, tosupport its deliberations. Archives of the working documents are maintained on theworking group wiki. When a new charter topic was introduced, the leadership teamprovided a working document for the topic, including (i) charter questions related tothat topic and for each charter question, (ii) context from the Transfer Policy Status
Page 8 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Report, and (iii) relevant inputs received from community groups through earlyoutreach. As the working group progressed through discussions, staff captured asummary of deliberations on the charter question and eventually populated the
document with draft charter question responses and draft preliminary
recommendations to support further discussion and refinement of the text.
Working documents were updated on an ongoing basis and working group members
were encouraged to provide comments and input in the working documents between
calls.

2.5 Swim Lane Diagram
To further support deliberations and document the expected impact of proposed
recommendations, the working group developed a swim lane diagram to visually
represent the possible future-state process flow for inter-Registrar transfers as it will
exist if all recommendations are approved and implemented. This diagram serves as aworking document to support the deliberations process and is not intended to beauthoritative, but it is included in this Initial Report to demonstrate the working group’s
understanding of the recommendations’ impact on the inter-Registrar transfer process.
The swim lane diagram is included in Annex E of this report.

2.6 Data and Metrics
The Transfer Policy Status Report produced by ICANN org in 2019 served as the working
group’s primary resource for data and metrics related to inter-Registrar transfers. In thecourse of its deliberations, the working group identified additional data that would bevaluable to support its work. The additional data provided by ICANN org’s Contractual
Compliance Department in response to these requests is available on the working
group’s wiki.

2.7 ICANN Org Interaction
To help support a smooth transition from policy development to eventual
implementation of GNSO Council adopted and ICANN Board approved
recommendations, the working group has been supported by early and ongoingengagement with ICANN org subject matter experts. Liaisons from ICANN org’s Global
Domains and Strategy (GDS) and Contractual Compliance departments regularly
attended working group calls, providing input and responding to questions where it waspossible to do so in real time. The liaisons acted as a conduit for working group
questions to ICANN org that required additional research or input. The liaisons also

Page 9 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

facilitated early review of working group draft outputs by ICANN org subject matter
experts.

2.8 Accountability to the GNSO Council
As is now the case with all GNSO working groups, the working group delivered monthly“project packages” to the GNSO Council to update the Council on the status of its work.
An archive of these packages is available on the wiki. The GNSO Council Liaison, Greg
DiBiase, served as an additional point of connection between Council and the working
group.

Page 10 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

3 Working Group Responses to Charter Questions
and Preliminary Recommendations
The WG was chartered to provide the GNSO Council with policy recommendations
regarding the issues identified in the Final Issue Report on a Policy Development Process
to Review the Transfer Policy.
Following its analysis of each of the questions outlined in its Charter related to this task,
the working group has arrived at a set of preliminary recommendations and conclusions.
Within the text of this document, the key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOTRECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP
148 [RFC2119] [RFC8174].
The working group will not finalize its responses to the charter questions andrecommendations to the GNSO Council until it has conducted a thorough review of thecomments received during the Public Comment period on this Initial Report andcompleted Phase 1(b) of its work. At this time, no formal consensus call has been takenon these responses and preliminary recommendations, but this Initial Report did receive
the support of the working group for publication for Public Comment.
The working group believes that when it formulates its final recommendations, if
approved by the GNSO Council and the ICANN Board, there will be substantial
improvement to the current environment. The following sub-sections of this report areorganized by topic. Within each topic, the working group provides responses to therelevant charter questions and corresponding preliminary recommendations:◼

Section 3.1: Gaining and Losing Forms of Authorization (FOA)◼

Section 3.2: Transfer Authorization Code/AuthInfo CodeManagement◼

Section 3.3: EPDP Phase 1, Recommendation 27, Wave 1
Report◼

Section 3.4: Denying (NACKing) Transfers

3.1 Gaining and Losing Forms of Authorization (FOA)
For context on this topic and the associated charter questions, please see pages 7-14 of
the Final Issue Report.
Page 11 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

3.1.1 Charter Question a1
Is the requirement of the Gaining FOA still needed? What evidence did the working
group rely upon in making the determination that the Gaining FOA is or is not necessary
to protect registrants?
Working Group Response:
The Inter-Registrar Transfer Policy - Part D Policy Development Process Working Group(IRTP WG D), previously examined the question of “Whether the universal adoption andimplementation of Extensible Provisioning Protocol (EPP) AuthInfo codes has eliminatedthe need of FOAs.” The IRTP WG D ultimately determined to retain the FOA until moreevidence was gathered. The Transfer Policy Review Working Group was asked to revisit
the same question and has determined there is now strong evidence that the Gaining
FOA can be eliminated from the Transfer Policy without negatively affecting the securityof inter-Registrar transfers. The working group further believes that requirements for a
Gaining FOA or a similar replacement are unjustified under data protection law and nolonger necessary from a practical perspective to facilitate the transfer. The working
group recognizes that this is a significant departure from existing policy and has
therefore provided a detailed rationale for its conclusion.
Prior to the General Data Protection Regulation (GDPR) coming into force, the Gaining
Registrar was required to confirm the Registered Name Holder’s (RNH) intent to transfer
by sending an email to the RNH asking for confirmation to proceed. In order for theGaining Registrar to be able to send the Gaining FOA, it needed to obtain the RNH’s
contact information from the publicly available Registration Data Directory Services(RDDS). With the introduction of the GDPR, Gaining Registrars were no longer able toobtain this information via RDDS, as personally identifiable information was largely
redacted within RDDS. In recognition of this new obstacle, ICANN org deferred
Contractual Compliance enforcement on Gaining FOA requirements. While still arequirement on paper, in practice the Gaining FOA does not currently exist and cannot
exist.
The working group considered that it could recommend some form of replacement for
the Gaining FOA to be included in future policy requirements. If it did so, there would
need to be a method and a justification for the Registrar of Record to transfer the RNH’s
contact information to the Gaining Registrar.
The working group considered that it is likely possible from a technical perspective tofacilitate the transfer of the RNH’s contact information from the Registrar of Record to
the Gaining Registrar for the purposes of confirming the RNH’s intent to transfer.
Page 12 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

However, the working group did not pursue specific methods for doing so because it did
not believe this transfer is feasible from a legal perspective.
In its deliberations on applicable law, the working group considered the principles ofdata minimization and privacy by design. Under these principles, in order to justify thetransfer of personally identifiable information (PII) from the Registrar of Record to theGaining Registrar and the subsequent processing of this data (in order to send theGaining FOA) by the Gaining Registrar, one would have to demonstrate that this transfer
and processing of PII is necessary to facilitate the transfer. The working group notedthat the transfer process has functioned without the Gaining FOA since the GDPR went
into force, and the working group has not encountered any evidence that there has
been an increase in unauthorized transfers since the Gaining FOA was functionallyeliminated. It has not found any other indications that the transfer process ismalfunctioning without the Gaining FOA requirement. Therefore, the working groupsees no evidence that the Gaining FOA is needed for the purpose of facilitating thetransfer or protecting the RNH from unauthorized transfers.
The working group looked at the value that the Gaining FOA provided to ensure thatequivalent value is covered by elements of the process going forward.
The working group noted that when the Gaining FOA requirements were in place, thetransfer could only proceed once the RNH had responded to the Gaining FOA. This
meant that the RNH always actively confirmed the intent to transfer before the transfer
took place. The Gaining FOA therefore served a notification function and also a
confirmation function. To the extent that the party obtaining the Transfer Authorization
Code (TAC) and requesting the transfer was an individual other than the RNH, the RNH
had the opportunity to confirm that they were aware of the request and wanted it toproceed.
The working group believes that the new notifications detailed in Preliminary
Recommendations 3-4 ensure that the RNH receives the necessary information withrespect to an inter-Registrar transfer. These notifications provide instructions on what
to do if the RNH wants to either stop or reverse the process because the action on theaccount is unauthorized or unintended. With respect to the confirmation function that
the Gaining FOA served, the working group believes that this is duplicative andtherefore unnecessary. The provision of the TAC is sufficient confirmation that the RNH
intends to transfer the domain, and therefore the Gaining Registrar does not need torequest this confirmation via another means.
The working group recalled that the Gaining FOA pre-dated the TAC, and that prior to
the introduction of the TAC, the Gaining FOA was an essential element for facilitating
the transfer and also provided a function that was important to prevent theunauthorized transfer of domains. With the introduction of the TAC, an additional layerof security was added to the process, and the Gaining FOA became less essential. The
Page 13 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

working group further noted that it has recommended a series of measures to increase
the security of the TAC and reduce the risk that the TAC is obtained by an unauthorized
person, as detailed in Preliminary Recommendations 7-13. With added security
measures, the TAC becomes a stronger means to demonstrate that the TAC holder is anappropriate party to request the transfer, which makes the authorization element of theGaining FOA unnecessary.
The working group noted that while it was in use, the Gaining FOA provided a record toassist ICANN’s Contractual Compliance department in investigating complaints,
especially those related to unauthorized transfers. It also supported the resolution of
disputes. The working group noted that new notifications detailed in Preliminary
Recommendations 3-4 will provide the necessary paper trail for this purpose.
Preliminary Recommendations:
Preliminary Recommendation 1: The working group recommends eliminating from theTransfer Policy the requirement that the Gaining Registrar send a Gaining Form of
Authorization. This requirement is detailed in section 1.A.2 of the Transfer Policy.

3.1.2 Charter Question a2
If the working group determines the Gaining FOA should still be a requirement, are any
updates (apart from the text, which will likely need to be updated due to the gTLD
Registration Data Policy) needed for the process? For example, should additional security
requirements be added to the Gaining FOA (two-factor authentication)?
Working Group Response:
As described in the above response to charter questions a1, the working group hasdetermined that the Gaining FOA should no longer be a requirement.

3.1.3 Charter Question a3
The language from the Temporary Specification provides, “[u]ntil such time when the
RDAP service (or other secure methods for transferring data) is required by ICANN to beoffered, if the Gaining Registrar is unable to gain access to then-current Registration
Data for a domain name subject of a transfer, the related requirements in the Transfer
Policy will be superseded by the below provisions...”. What secure methods (if any)
currently exist to allow for the secure transmission of then-current Registration Data fora domain name subject to an inter-Registrar transfer request?
Working Group Response:
Page 14 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

As noted in the response to charter question a1, the working group considered that it islikely possible from a technical perspective to facilitate the transfer of the RNH’s contact
information from the Registrar of Record to the Gaining Registrar for the purposes ofconfirming the RNH’s intent to transfer. However, the working group did not pursue
specific methods for doing so because it did not believe this transfer is feasible from alegal perspective.

3.1.4 Charter Question a4
If the working group determines the Gaining FOA is no longer needed, does the AuthInfo
Code provide sufficient security? The Transfer Policy does not currently require specificsecurity requirements around the AuthInfo Code. Should there be additional security
requirements added to AuthInfo Codes, e.g., required syntax (length, characters), twofactor authentication, issuing restrictions, etc.?
Working Group Response:
The working group has presented a series of enhancements to the security of theTransfer Authorization Code (TAC), formerly known as the AuthInfo Code, in Preliminary
Recommendations 7-13. The working group believes that the TAC will provide sufficient
security with these improvements in place.

3.1.5 Charter Question a5
If the working group determines the Gaining FOA is no longer needed, does thetransmission of the AuthInfo Code provide a sufficient “paper trail” for auditing andcompliance purposes?
Working Group Response:
It is the working group’s view that a sufficient “paper trail” will be provided by records
associated with provision of the TAC and notifications to the RNH outlined in Preliminary
Recommendations 3-4.

3.1.6 Charter Question a6
Survey respondents noted that mandatory domain name locking is an additional security
enhancement to prevent domain name hijacking and improper domain name transfers.
The Transfer Policy does not currently require mandatory domain name locking; it allows
a Registrar to NACK an inter-Registrar transfer if the inter-Registrar transfer wasPage 15 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

requested within 60 days of the domain name’s creation date as shown in the Registry
RDDS record for the domain name or if the domain name is within 60 days after beingtransferred. Is mandatory domain name locking an additional requirement the working
group believes should be added to the Transfer Policy?
Working Group Response:
The working group understands that this charter question refers to a lock that some
Registrars apply by default to protect their customers from accidental or malicious interRegistrar transfers. Registrants may, however, request lock removal, and Registrars
must remove the lock within five days per requirements of the Transfer Policy.4 Charter
question a6 asks whether this lock, which some Registrars choose to apply today, should
become a policy requirement for ALL Registrars. For the avoidance of doubt, the lock
addressed in this charter question is distinct from potential requirements for a Registrar
to restrict the RNH from transferring a domain name to a new Registrar within 30 daysof the initial registration date and within 30 days of the completion of an inter-Registrartransfer. Unlike Preliminary Recommendations 20-21 regarding inter-Registrar transfer
restrictions, the lock discussed in this charter question is a default lock that is generally
removable upon the request of the registrant,5 while the restrictions discussed in
Preliminary Recommendations 20-21 are triggered by a specific event and are notremovable upon the request of the registrant.
The working group does not believe that mandatory domain name locking as presented
above should be added to the Transfer Policy. It is the working group’s view that
Registrars are in the best position to determine whether locking a domain by default
upon registration is appropriate for their customers in combination with other security
features implemented by the Registrar. The working group notes that there will begreater security related to inter-Registrar transfers following the implementation ofPreliminary Recommendations 7-13 for enhanced security of the TAC. The working
group expects that Registrars will continue to use their own discretion to implement any
additional measures that may be appropriate for their business model and customerbase.

3.1.7 Charter Question a7
Is the Losing FOA still required? If yes, are any updates necessary?
Working Group Response:

4 Please note there are some instances, which are specifically spelled out in the Transfer Policy, where a

Registrar may not unlock a domain name, even if requested by the Registered Name Holder, e.g., thedomain name is subject to a UDRP proceeding or locked pursuant to a court order.
5 Ibid.

Page 16 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

The working group acknowledged that the Losing FOA serves a number of importantfunctions:•••

The Losing FOA notifies the RNH that a transfer has been requested.
In cases where the party requesting the TAC is different from the RNH receiving
the Losing FOA, the Losing FOA provides an extra layer of security in the form of
a “second factor” to ensure that the RNH is aware that the transfer is taking
place.
The Losing FOA provides a paper trail to assist ICANN’s Contractual Compliancedepartment in investigating complaints, especially those related to unauthorizedtransfers. It also supports the resolution of disputes. Following the deferral ofContractual Compliance enforcement of Gaining FOA requirements, the Losing
FOA has taken on particular importance for complaint investigation.

The working group agreed that the transfer process must have appropriate security
measures in place and that the RNH must continue to be notified when an interRegistrar transfer is expected to take place. Furthermore, the working group agreed that
there must be a record of events that is sufficient to facilitate ICANN Contractual
Compliance’s investigation of transfer-related complaints and support the resolution of
disputes.
With respect to security, the working group noted that new laws have come into force
since the Losing FOA was instituted that provide additional protections to the RNH withrespect to personal data protection. The working group further concluded that if the
TAC is managed in a more secure manner following Preliminary Recommendations 7-13,
the risk of unauthorized transfer should be reduced.
The working group agreed that the transfer process should be simple, quick, andefficient. Members noted that the Losing FOA process can delay the transfer up to 5days, which may inconvenience registrants. Therefore, it is desirable to pursue
alternatives to the Losing FOA that allow for transfers to take place instantly.
Taking into account these considerations, the working group determined that the Losing
FOA requirement should be eliminated and replaced with new requirements. These newrequirements allow the transfer to occur in nearly real time while ensuring that: 1. The
RNH is informed of an inter-Registrar transfer, and 2. A sufficient record of the process
is maintained to support investigation of complaints and resolution of disputes.
Preliminary Recommendations:Page 17 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Preliminary Recommendation 2: The working group recommends eliminating from theTransfer Policy the requirement that the Registrar of Record send a Losing Form of
Authorization.6 This requirement is detailed in section I.A.3 of the Transfer Policy.
Preliminary Recommendation 3: The working group recommends that the Registrar of
Record MUST send a “Notification of TAC Provision”7 to the RNH, as listed in theRegistration Data at the time of the TAC request, without undue delay but no later than
10 minutes after the Registrar of Record provides the TAC.8
3.1: This notification MUST be written in the language of the registrationagreement and MAY also be provided in English or other languages.
3.2: The following elements MUST be included in the “Notification of TAC
Provision”:• Domain name(s)• Date and time that the TAC was provided and information about when
the TAC will expire• Instructions detailing how the RNH can take action if the request is invalid(how to invalidate the TAC)
• If the TAC has not been provided via another method of communication,
this communication will include the TAC
Preliminary Recommendation 4: The working group recommends that the Losing
Registrar9 MUST send a “Notification of Transfer Completion” 10 to the RNH, as listed in
the Registration Data at the time of the transfer request, without undue delay but nolater than 24 hours after the transfer is completed.
4.1: This notification MUST be written in the language of the registrationagreement and MAY also be provided in English or other languages.
4.2: To the extent that multiple domains have been transferred to the same

6 The working group notes that, in place of the Losing FOA, notifications are sent to the RNH in relation to

an inter-Registrar transfer, as detailed in Preliminary Recommendations 3-4.
7 The working group recognizes that this notification MAY be sent via email, SMS, or other secure
messaging system. These examples are not intended to be limiting, and it is understood that additional
methods of notification MAY be created that were not originally anticipated by the working group.
8 The working group recognizes that from a security perspective, it is best for the “Notification of TAC
Provision” to be delivered by a method of communication that is different from the method used todeliver the TAC. If this is not possible, and the same method of communication is used, the Registrar of
Record MAY choose to send the "Notification of TAC Provision" and the TAC together in a single
communication.
9 This is the Registrar of Record at the time of the transfer request.
10 The footnote on Preliminary Recommendation 3 regarding the method by which notifications are sent
equally applies to the “Notification of Transfer Completion.”

Page 18 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Gaining Registrar or to multiple Gaining Registrars at the same time, and the RNH
listed in the Registration Data at the time of the transfer is the same for all
domains, the Registrar of Record MAY consolidate the “Notifications of Transfer
Completion” into a single notification.
4.3: The following elements MUST be included in the “Notification of Transfer
Completion”:• Domain name(s)• Text stating that the domain was transferred• Date and time that the transfer was completed• Instructions detailing how the RNH can take action if the transfer wasinvalid (how to initiate a reversal)
Note: The working group has included the following question for community
input regarding Preliminary Recommendation 4.3 as part of the Public Comment
process on the Initial Report:
As detailed in Recommendations 3-4, the working group is recommending
replacing the Standardized Losing FOA with two notifications to the Registered
Name Holder: (i) a required “Notification of TAC Provision” and (ii) a required“Notification of Transfer Completion”. Recommendation 4 details the minimum
elements to be included in the Notification of Transfer Completion, including, forexample, domain name, date/time of transfer completion, instructions on how totake action if the transfer is invalid. The working group discussed the possibility ofincluding the IANA ID of the Gaining Registrar within this notification.
Note: The IANA ID is the unique number provided by ICANN to each accredited
Registrar. The IANA ID can be helpful in identifying the correct Registrar,
especially in situations where Registrars have similar names and/or have multiple
subsidiaries with similar names.
In the working group’s discussion, Registrars noted that not all Registry
Operators use the Gaining Registrar’s IANA ID when notifying a Losing Registrarof a pending transfer request. Instead, some Registry Operators use a separate,internal client ID that does not correspond to the IANA ID. Registry
representatives asked if this question could be included in the Public Comment
forum to allow additional time to discuss if it would be feasible to include the
IANA ID when notifying the Registrar via EPP or otherwise, which would thenallow the Losing Registrar to provide the IANA ID in the Notification of Transfer
Completion. Please note all commenters are welcome to respond to this question,
not just Registry Operators.
Question to the community: Should the Gaining Registrar’s IANA ID be provided
by the Registry Operator to the Losing Registrar so that it may be included inPage 19 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

the Notification of Transfer Completion sent by the Losing Registrar to theRegistered Name Holder? Why or why not? Please explain.

3.1.8 Charter Question a8
Does the Contracted Parties House (CPH) Proposed Tech Ops Process represent a logicalstarting point for the future working group or policy body to start with? If so, does it
provide sufficient security for registered name holders? If not, what updates should beconsidered?
Working Group Response:
The CPH Tech Ops Group, “agreed that the requirement to notify the Registrant about atransfer request should be mandatory. As general business practices of Registrars andindividual transfer scenarios vary, the group concluded that such notification does nothave to be an email, but rather may incorporate other means of more modern
communication.”11
The working group agreed with Tech Ops that it is important to notify the RNH when atransfer is expected to take place and has recently taken place. The working groupfurther supported the idea that given variations in Registrar business models andindividual transfer scenarios, different secure means of communication may beappropriate for the provision of notifications.

3.1.9 Charter Question a9
Are there additional inter-Registrar transfer process proposals that should be consideredin lieu of or in addition to the CPH TechOps Proposal? For example, should affirmative
consent to the Losing FOA be considered as a measure of additional protection?
Working Group Response:
The working group did not identify any additional proposals to pursue in this regard.

3.2 Transfer Authorization Code/AuthInfo Code Management
For context on this topic and the associated charter questions, please see pages 15-19of the Final Issue Report.

11 Full text of the CPH Tech Ops proposal can be found in Annex B of the TPR Final Issue Report.

Page 20 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

3.2.1 Charter Question b1
Is AuthInfo Code still a secure method for inter-Registrar transfers? What evidence wasused by the working group to make this determination?
Working Group Response:
The working group agreed that it should first establish clarity around the function anddefinition of the AuthInfo Code and ensure that terminology is clear before addressing
specific security requirements. The working group used the following text on ICANN.org
as a starting point for discussion on the definition of the Transfer Authorization Code(TAC): “An Auth-Code (also called an Authorization Code, Auth-Info Code, or transfercode) is a code created by a Registrar to help identify the Registered Name Holder of adomain name in a generic top-level domain (gTLD). An Auth-Code is required for a
Registered Name Holder to transfer a domain name from one Registrar to another.” The
working group agreed that the term “identify” is inappropriate in this context, because
the code does not verify identity in practice. Instead, the TAC is used to verify that theRegistered Name Holder (RNH) requesting the transfer is the same RNH who holds thedomain.
The working group considered that a number of different terms currently apply to thesame concept, including AuthInfo Code, Auth-Info Code, Auth-Code, Authorization
Code, and transfer code. None of these terms clearly describe the function of the code.
The working group believes that it is clearer for all parties, and particularly the RNH, if asingle term is used universally. The working group believes that “Transfer Authorization
Code” (TAC) provides a straightforward description of the code’s function, and therefore
should serve as the standard term in place of the alternatives.
Regarding the security of the TAC, the working group agreed that metrics could support
deliberations on charter question b1. In particular, working group members wereinterested to see if there has been a change in the number of unauthorized transfers
following adoption of the Temporary Specification for gTLD Registration Data. ICANN’s
Contractual Compliance Department provided the working group with updated metrics
regarding complaints received, which covered the periods both before and after the
Temporary Specification went into effect.12 Contractual Compliance subsequently
shared additional metrics that included the “closure codes” associated with complaints

12Available at:https://community.icann.org/download/attachments/181307054/Compliance_Transfer%20Data_present
ed%2029%20June%202021.xlsx?version=1&modificationDate=1638449700087&api=v2

Page 21 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

about unauthorized transfers.13 While the working group agreed that it is difficult todraw conclusions from the data, the working group noted that there was no notable
increase in complaints following the date that the Temporary Specification went into
effect.
The working group considered that in addition to examining metrics regarding past
performance, it is important to consider future-state objectives for the TAC. The
working group agreed that from this perspective, additional security features areappropriate to protect the RNH, particularly in light of working group preliminary
recommendations to replace requirements for the Gaining and Losing FOA with
notifications to the RNH. In considering potential security enhancements, the working
group considered the benefits of requiring these measures, while also taking into
account usability considerations and operational impacts on contracted parties in
implementing new requirements.
Preliminary Recommendations:
Preliminary Recommendation 5: The working group recommends that the Transfer
Policy and all related policies MUST use the term “Transfer Authorization Code (TAC)” inplace of the currently-used term “AuthInfo Code” and related terms. This
recommendation is for an update to terminology only and does not imply any otherchanges to the substance of the policies.
Preliminary Recommendation 6: The working group recommends that the Transfer
Authorization Code MUST be defined as follows: “A Transfer Authorization Code (TAC) isa token created by the Registrar of Record and provided upon request to the RNH or
their designated representative.14 The TAC is required for a domain name to betransferred from one Registrar to another Registrar and when presented authorizes thetransfer.”15 Relevant policy language MUST be updated to be consistent with thisdefinition.
Preliminary Recommendation 7: The working group recommends that the minimum
requirements for the composition of a TAC MUST be as specified in RFC 9154 (and its

13Available at:https://community.icann.org/download/attachments/181307054/Compliance_Unauthorized%20Transfer%20Data%20Aug%202020Sept%202021_presented%209%20November%202021.xlsx?version=1&modificationDate=163844997500
0&api=v2
14 "Designated representative" means an individual or entity that the Registered Name Holder explicitly
authorizes to obtain the TAC on their behalf.
15 Note: This definition draws on elements included in Preliminary Recommendation 9.

Page 22 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

update and replacement RFCs). In addition, where random values are required by RFC
9154, such values MUST be created according to BCP 106. 16
Preliminary Recommendation 8: The working group recommends that the Registryverifies at the time that the TAC is stored in the Registry system that the TAC meets therequirements specified in Preliminary Recommendation 7.

3.2.2 Charter Question b2
The Registrar is currently the authoritative holder of the AuthInfo Code. Should this be
maintained, or should the Registry be the authoritative AuthInfo Code holder? Why?
Working Group Response:
In considering this charter question, the working group focused on evaluating anddefining specific roles and responsibilities of Registries and Registrars in the transfer
process, noting that each party has an important role to play in the transfer process.
While some working group members expressed the view that Registry management of
the TAC would be more uniform, standardized, and transparent, others noted thatstandards will be set through policy and enforced by ICANN Contractual Complianceregardless of whether the authoritative holder is the Registry or Registrar; therefore, it
is not clear why it would be better to have the Registry be the authoritative holder.
The working group ultimately did not identify a compelling reason to shift ownership of
the TAC to the Registry and therefore determined that the Registrar should continue togenerate the TAC, set the TAC in the Registry platform, and provide the TAC to the RNH
or their designated representative. The working group further agreed that the Registry
should continue to verify the validity of the TAC. The working group provided
preliminary recommendations to improve security practices with respect to the TAC to
be implemented at the Registry.
Preliminary Recommendations:
Preliminary Recommendation 9: The working group recommends that:

16 BCP 106 is a Best Current Practice and is an idempotent reference to the most recent version of thespecification entitled “Randomness Requirements for Security”, currently RFC 4086, which is how it isreferenced in RFC 9154. For clarity, idempotent means the BCP 106 URL reference is static, and willautomatically point to the updated RFC, without the need for action by the Contracted Party.

Page 23 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

9.1: The TAC MUST only be generated by the Registrar of Record upon request
by the RNH or their designated representative.
9.2: When the Registrar of Record sets the TAC at the Registry, the Registry
MUST store the TAC securely, at least according to the minimum standard set
forth in RFC 9154.
Implementation Guidance for Recommendation 9.2: RFC 9154 recommends
using a strong one-way cryptographic hash with at least a 256-bit hash function,such as SHA-256 [FIPS-180-4], and with a per-authorization information random
salt with at least 128 bits. 17
9.3: When the Registrar of Record provides the TAC to the RNH or theirdesignated representative, the Registrar of Record MUST also provide
information about when the TAC will expire.
Preliminary Recommendation 10: The working group confirms the following provisionof Appendix G: Supplemental Procedures to the Transfer Policy contained in the
Temporary Specification for gTLD Registration Data: “4. Registry Operator MUST verify
that the "AuthInfo" code provided by the Gaining Registrar is valid in order to accept aninter-registrar transfer request,” with terminology updates in accordance with otherrelevant recommendations.
Preliminary Recommendation 11: The working group recommends that the TAC ascreated by the Registrar of Record according to Preliminary Recommendation 7, MUST
be “one-time use.” In other words, it MUST be used no more than once per domainname. The Registry Operator MUST clear the TAC as part of completing the successfultransfer request.

3.2.3 Charter Question b3
The Transfer Policy currently requires Registrars to provide the AuthInfo Code to theregistrant within five [calendar] days of a request. Is this an appropriate Service Level
Agreement (SLA) for the Registrar’s provision of the AuthInfo Code, or does it need to be
updated?
Working Group Response:

17 [FIPS-180-4] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure

Hash Standard, NIST Federal Information Processing Standards (FIPS) Publication 180-4",
DOI10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>.

Page 24 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

The working group agreed that the Transfer Policy should continue to require Registrars
to provide the TAC to the RNH or their designated representative within a specified
period of time following a request. While some working group members felt that thestandard time frame for provision of the TAC should be shorter than five calendar days,
working group members noted that exceptions may be necessary to accommodate
specific circumstances. The working group did not identify a compelling reason tochange the five-day response timeframe but believes that it is appropriate to update thepolicy language to highlight that five calendar days is the maximum and not thestandard period in which the TAC is to be provided.
Preliminary Recommendations:
Preliminary Recommendation 12: The working group confirms that the Transfer Policy
MUST continue to require Registrars to set the TAC at the Registry and provide the TAC
to the RNH or their designated representative within five calendar days of a request,
although the working group recommends that the policy state the requirement as 120
hours rather than 5 calendar days to reduce any risk of confusion. The working groupfurther recommends that the policy MUST make clear that 120 hours is the maximum
and not the standard period in which the TAC is to be provided.

3.2.4 Charter Question b4
The Transfer Policy does not currently require a standard Time to Live (TTL) for the
AuthInfo Code. Should there be a standard Time to Live (TTL) for the AuthInfo Code? Inother words, should the AuthInfo Code expire after a certain amount of time (hours,
calendar days, etc.)?
Working Group Response:
The working group clarified its understanding that the Time to Live (TTL) is the period oftime that the TAC is valid once the TAC has been created. The working group noted that
there are no existing policy requirements regarding TTL. The working group believes
that it is good security practice to have a standard TTL for the TAC, because old, unused
TACs are vulnerable to exploitation.
Preliminary Recommendations:
Preliminary Recommendation 13:
The working group recommends that:
13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days fromthe time it is set at the Registry, enforced by the Registries.
Page 25 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

13.2: The Registrar of Record MAY set the TAC to null after a period of less than
14 days by agreement by the Registrar of Record and the RNH.
Note: The working group has included the following question for community
input regarding Preliminary Recommendation 13.1 as part of the Public
Comment process on the Initial Report:
The working group noted that the standard Time to Live (TTL), as referenced in
Preliminary Recommendation 13.1 is the period of time that the TAC is valid once
the TAC has been created. The purpose of the standard TTL is to enforce security
around unused TACs (e.g., requested/received but not used), in a situation where
the TAC may be stored in a registrant’s email or other communications storage.
The working group agreed to a maximum standard TTL of 14 days.
In discussing this Charter Question, the working group initially discussed thebenefits of placing the Registry in the role of enforcing the standard TTL. The
working group noted that Registry authority would be more secure andstreamlined due to the lesser number of Registry Operators as compared to
ICANN-accredited Registrars.
Registry Operators, however, have expressed two concerns in taking on this role:
1) Registries do not have a customer relationship with registrants, and,accordingly, cautioned that having Registries preemptively invalidate a TAC
directly impacts registrants; 2) this gives Registries a compliance responsibility
over Registrars since they would be required to respond to authorities andpotentially registrants investigating any concerns with the efficacy or expiry of a
TAC.
Question to the community: Who is best positioned to manage the standard
14-day TTL – the Registry or the Registrar, and why? Are there specificimplications if the TTL is managed by the Losing Registrar?

3.2.5 Charter Question b5
Should the ability for registrants to request AuthInfo Codes in bulk be streamlined andcodified? If so, should additional security measures be considered?
Working Group Response:
As a general rule, the working group believes that one randomly generated TAC should
be provided per domain name, because this is a good security practice (see Preliminary
Recommendation 7). The Working Group recognizes that for cases where multiple
Page 26 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

domains are being transferred, it would be more convenient to have a streamlined
approach for requesting and using TACs. Some working group members suggested acarveout to the standard TAC requirements that would allow use of the same TAC for
multiple domains if specific additional requirements were met to ensure security of thetransaction. At the time of publication of the Initial Report, the working group did notagree on specific conditions under which this should be possible. Therefore, the working
group is not making any recommendations with respect to exceptions for multi-domaintransfers.

3.2.6 Charter Question b6
Does the CPH TechOps research provide a logical starting point for future policy work on
AuthInfo Codes, or should other options be considered?
Working Group Response:
The working group carefully reviewed the TechOps proposal18 and considered input
from those involved in development of the proposal. The working group appreciated theexpertise and relevant experience of those who developed the proposal and therefore
considered it a logical starting point for discussion. The working group agreed, however,that it is important to consider (i) the range of views and interests that may not havebeen represented in the development of the proposal, and (ii) any new information orinterests that have come to light since the development of the proposal. Therefore, indeveloping its preliminary recommendations, the working group deliberated on each of
the charter questions, taking into account both the relevant elements of the TechOps
paper as well as all other available information and inputs.

3.2.7 Charter Question b7
Should required differentiated control panel access also be considered, i.e., theregistered name holder is given greater access (including access to the auth code), andadditional users, such as web developers would be given lower grade access in order toprevent domain name hijacking?
Working Group Response:
The working group does not believe that there should be any new policy requirementsin this regard.

18 Available in Annex B of the TPR Final Issue Report.

Page 27 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

3.3 EPDP Phase 1, Recommendation 27, Wave 1 Report
For context on this topic and the associated charter questions, please see pages 52-56
of the Final Issue Report.

3.3.1 Charter Question c1
How should the identified issues be addressed?
Working Group Response:
The working group reviewed the Transfer Policy-related issues from Section 3.11 of the
Wave 1 Report and noted seven (7) of the ten (10) “key issues” were relevant to thecurrent phase (Phase 1(a)) of its work.19 The working group reviewed and discussed
these seven issues and has provided a response to each issue. The detailed responses
can be found in Annex D of this report.
Preliminary Recommendations:
Preliminary Recommendation 14: The working group recommends the following
specific terminology updates to the Transfer Policy:(i) The term "Whois data" SHALL have the same meaning as "Registration Data".
(ii) The term "Whois details" SHALL have the same meaning as "Registration Data".
(iii) The term "Publicly accessible Whois" SHALL have the same meaning as "RDDS".
(iv) The term "Whois" SHALL have the same meaning as "RDDS".
For the avoidance of doubt, the terms referenced in above in Recommendation 14 (i) (iv) are intended to correspond to the definitions in the Registrar Accreditation
Agreement (“RAA”). In the event of any inconsistency, the RAA definitions, if updated,
will supersede. The working group also recommends that the outdated terms should be
replaced with the updated terms, e.g., all references to “Whois Data” should be
replaced with the term “Registration Data,” etc.
Rationale: This recommendation is consistent with the EPDP Team’s Phase 1
Recommendation 24.

19 Key Issues 4, 6, and 7 related to Change of Registrant, and, accordingly, the working group agreed to

discuss these issues during Phase 1(b) of its work.

Page 28 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Preliminary Recommendation 15: The working group recommends removing any
reference to an “Administrative Contact” or “Transfer Contact” in the Transfer Policy
and replacing it with “Registered Name Holder” unless specifically indicated.
Rationale: Under the Registration Data Policy, Administrative Contact data is nolonger collected by the Registrar. Accordingly, the Registered Name Holder would
be the only authorized transfer contact.

3.3.2 Charter Question c2
Can the FOA-related Transfer Policy issues (identified in paragraphs 5 and 9 of Wave 1
Report), as well as the proposed updates to the Gaining and Losing FOAs, be discussed
and reviewed during the review of FOAs?
Working Group Response:
As noted above, the working group reviewed the seven key issues from Section 3.11 of
the Wave 1 Report that are directly related to Phase 1(a) of its work, including the issues
related to the Gaining and Losing FOAs. The working group determined these specificissues are in scope for it to address during Phase 1(a) and discussed and reviewed theseissues during its plenary meetings. For the detailed responses on the key issues, pleaserefer to Annex D of this report.
The working group noted many key issues alluded to terminology inconsistencies, which
are the direct result of the EPDP Phase 1 recommendations. For example, EPDP Phase 1,
Recommendation #5 provides an updated list of data elements to be collected byRegistrars. Notably, the administrative contact field, which was a required data fieldunder the 2013 RAA, is no longer a required data element for Registrar collection andsubsequent processing. Because the administrative contact field is referenced manytimes within the Transfer Policy, the working group noted those references should be
removed.20 Similarly, the working group observed that the multiple references to“Whois” need to be updated.

3.4 Denying (NACKing) Transfers
The topic of denying (NACKing) transfers was originally planned for Phase 2 of the PDP.
It was later moved to Phase 1(a) by a Project Change Request to ensure that the working

20 Additional context from the working group’s discussion can be found in Annex D of this report.

Page 29 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

group could examine all elements of the security model for domain name transfers in aholistic manner as part of its Phase 1 deliberations.
For context on this topic and the associated charter questions, please see pages 43-48
of the Final Issue Report.

3.4.1 Charter Question h1
Are the current reasons for denying or NACKing a transfer sufficiently clear? Should
additional reasons be considered? For instance, ICANN Contractual Compliance has
observed difficulties from Registrars tying transfer denials involving domain names
suspended for abusive activities to the denial instances contemplated by the Transfer
Policy; or should any reasons be removed?
Working Group Response:
The working group conducted a thorough review of the reasons for denying or NACKinga transfer and has provided a series of preliminary recommendations detailed below.
Please see the rationale for each proposed change for additional information about why
these updates are being recommended.
While discussing sections I.A.3.7 through I.A.3.9 of the Transfer Policy, the working
group spent a significant among of time considering I.A.3.7.5 and I.A.3.7.6 and the factthat in some cases, a domain is locked against inter-Registrar transfer for 60 days
following the registration of the domain name or the transfer of the domain name to a
new Registrar. Requirements regarding post-registration and post-transfer locks appear
in some Registry Agreements and are reflected in corresponding Registry-Registrar
Agreements. This practice is neither required nor prohibited in the Transfer Policy and isapplied inconsistently across the industry.
The working group considered that this inconsistent practice may cause confusion
among registrants and may lead to poor registrant experience. The working groupsupported establishing a standard set of requirements that apply across the industry.
While some members also supported opportunities for opt-outs or flexibility in therequirements (for example a minimum lock period with an option to implement a longer
lock period), the working group ultimately agreed that consistency needs to be
maintained.

Page 30 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

In the course of deliberations, the working group discussed three possible time periods
for post-registration and post-transfer locks:21 10 days, 30 days, and 60 days. Working
group members supported maintaining consistency between the period that a transfer
is prohibited following registration and following inter-Registrar transfer. Some working
group members have advocated for establishing a “fast undo” process along the lines of
the Expedited Transfer Reverse Process (ETRP) considered in Inter-Registrar Transfer
Policy (IRTP) Part B Policy Development Process. The IRTP Part B Working Groupultimately did not adopt the ETRP proposal. “Fast undo” discussions will continue inPhase 2 of the Transfer Policy Review PDP, and the working group has not yet
considered this topic in depth. At this stage, some working group members noted that if
a “fast undo” process is ultimately adopted, the period for which a domain is eligible for“fast undo” following an inter-Registrar transfer should likely correspond to the lockperiods, and should be sufficiently long to identify the need to invoke the “fast undo”
process.
Preliminary Recommendations:
Preliminary Recommendation 16: The Registrar MUST restrict the RNH fromtransferring a domain name to a new Registrar within 30 days of the initial registration
date.
Rationale: The working group believes that a single requirement across theindustry will result in a better experience for registrants. The working group
recommends that 30 days is the appropriate period for this requirement because:• It provides a window of opportunity to identify issues associated withcredit card payments, including unauthorized use of a credit card. This may
assist with addressing criminal activity and deterring fraud.
• It provides a window of opportunity for a complainant to file a Uniform
Domain Name Dispute Resolution Policy (UDRP) proceeding without thedomain being transferred to a new registrar. Once the proceeding isunderway, the domain will be locked in relation to the dispute.
• For registrants who legitimately want to transfer a domain shortly after
registration, the working group believes that 30 days is a reasonable periodof time to wait.
Preliminary Recommendation 17: The Registrar MUST restrict the RNH fromtransferring a domain name to a new Registrar within 30 days of the completion of aninter-Registrar transfer.

21 Use of the term “lock” is not intended to imply or require a specific technical solution for

implementation. Rather, it is used as shorthand meaning that the domain is ineligible for inter-Registrartransfer for a period of time.

Page 31 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Rationale: The working group believes that a single requirement across theindustry will result in a better experience for registrants and will also consistently
prevent the transfer of a domain multiple times in rapid succession, a practiceassociated with domain theft. The working group recommends that 30 days is theappropriate period for this requirement because:• It provides a window of opportunity to identify issues associated withcredit card payments, including unauthorized use of a credit card. This may
assist with addressing criminal activity and deterring fraud.
• For registrants who legitimately want to transfer a domain again shortly
after an inter-registrar transfer has taken place, 30 days is a reasonable
period of time to wait.
Preliminary Recommendation 18: I.A.3.7 of the Transfer Policy currently reads, “Upondenying a transfer request for any of the following reasons, the Registrar of Record must
provide the Registered Name Holder and the potential Gaining Registrar with the reason
for denial. The Registrar of Record MAY deny a transfer request only in the following
specific instances:” The working group recommends expressing the two sentences ofthis provision as two distinct provisions of the policy.
Rationale: The two sentences of I.A.3.7 express two distinct concepts andtherefore should be separated into two different provisions.
Preliminary Recommendation 19: The working group recommends revising thefollowing reasons that the Registrar of Record MAY deny a transfer request as follows:
Reference Current Text

Revision

Rationale

I.A.3.7.1

Evidence of fraud.

Evidence of fraud or
violation of theRegistrar’s domain use
or anti-abuse policies.

ICANN’s Contractual ComplianceDepartment has observed difficulties from
Registrars tying transfer denials involving
domain names suspended for abusive
activities to the denial instances
contemplated by the Transfer Policy. The
working group considered several possible
revisions to I.A.3.7.1 with the goal of
ensuring that the text is clear andnarrowly-tailored while appropriately
addressing the issue identified. The
working group’s addition of “violation of
the Registrar’s domain use or anti-abusepolicies” seeks to strike this balance.

I.A.3.7.2

Reasonable dispute
over the identity of
the Registered Name
Holder or

Reasonable dispute overthe identity of concernthat the transfer was
not requested by the

The working group believes that the term
“identity” is not appropriate in thiscontext, in part due to concerns regarding
data privacy implications. Because thePage 32 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report
Administrative
Contact.

Registered Name Holder
or Administrative
Contact.

Date: 16 June 2022

issue at hand is more precisely aboutauthority over the domain, the working
group refined the text to focus on the key
underlying concern, namely that thetransfer request was made by a party
other than the Registered Name Holder.
Under the Registration Data Policy,
Administrative Contact data is no longer
collected by the Registrar, therefore thisterm has been removed. This update isconsistent with Preliminary
Recommendation 15.
The Working Group considered adding
language to address other types of invalid
requests or disputes by other parties. The
Working Group determined that the use
cases they discussed are appropriately
covered by the revised language in
I.A.3.7.2.

I.A.3.7.3

No payment forprevious registration
period (including
credit card chargebacks) if the domainname is past its
expiration date orfor previous orcurrent registration
periods if thedomain name has
not yet expired. In all
such cases, however,the domain namemust be put into
"Registrar Hold"
status by theRegistrar of Record
prior to the denial oftransfer.

Nonpayment forprevious registration
period (including
payment disputes or
credit card charge-backs)
if the domain name ispast its expiration dateat the current Registrarof Record or for previous
or current registration
periods if the domainname has not yet
expired. In all such cases,
however, the domainname must be put into
"Registrar Hold" status
by the Registrar of
Record prior to thedenial of transfer.

The working group has added the term
“payment disputes” to reflect problems
related to payments other than a credit
card charge-back.
The working group received input fromICANN’s Contractual ComplianceDepartment that the term “expirationdate” in this provision is not sufficiently
precise, because during the Auto-Renew
Grace Period, the domain will not show as
expired at the Registry level, but will show
as expired at the Registrar of Record. By
adding “at the current Registrar of
Record” the working group has clarified
that if the domain name is past its
expiration date at the current Registrar of
Record and the RNH has not paid for theregistration period prior to that expiration
date, the Registrar of Record may deny
the transfer.
The working group notes that thesentence beginning “In all such cases. . .”dates back as early as the 2002 ICANNDNSO Transfers Task Force Final Report &Recommendations. The working groupbelieves that the Expired Registration
Recovery Policy now provides the

Page 33 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

necessary guidance on treatment of
domains post-expiration and that thissentence is unnecessary in the Transfer
Policy text.

Preliminary Recommendation 20: The working group recommends changing thefollowing reasons that the Registrar of Record currently MAY deny a transfer into
reasons that the Registrar of Record MUST deny a transfer and revising the text asfollows:
Reference Current Text

Revision

Rationale

I.A.3.7.4

Express objection to thetransfer by theauthorized Transfer
Contact Registered
Name Holder. Objection
could take the form ofspecific request (either
by paper or electronicmeans) by theauthorized Transfer
Contact Registered
Name Holder to deny aparticular transfer
request, or a generalobjection to all transfer
requests received by theRegistrar, either
temporarily orindefinitely. In all cases,
the objection must be
provided with theexpress and informed
consent of theauthorized Transfer
Contact Registered
Name Holder on an optin basis and uponrequest by theauthorized Transfer
Contact Registered
Name Holder, theRegistrar must remove
the lock or provide a
reasonably accessible
method for theauthorized Transfer
Contact Registered
Name Holder to remove

Under the Registration Data Policy,
Administrative Contact data is no longer
collected by the Registrar. Accordingly, theRNH would be the only authorized transfer
contact. The working group believes that it
is logical that the Registrar of Record must
deny a transfer if the Registered Name
Holder expressly objects to the transfer.
This update is consistent with Preliminary
Recommendation 15.

Express objection to
the transfer by theauthorized Transfer
Contact. Objection
could take the formof specific request(either by paper orelectronic means) by
the authorized
Transfer Contact todeny a particulartransfer request, ora general objection
to all transfer
requests received by
the Registrar, either
temporarily orindefinitely. In allcases, the objection
must be provided
with the express andinformed consent of
the authorized
Transfer Contact onan opt-in basis andupon request by theauthorized Transfer
Contact, theRegistrar must
remove the lock orprovide a reasonably
accessible method
for the authorized
Transfer Contact toremove the lockwithin five (5)calendar days.

Page 34 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

the lock within five (5)calendar days.
I.A.3.7.5

I.A.3.7.6

The transfer was
requested within 60
days of the creation
date as shown in theregistry Whois
record for thedomain name.

The transfer was
requested within 60 30
days of the creation dateas shown in the registry
Whois RDDS record forthe domain name.

A domain name iswithin 60 days (or alesser period to be
determined) after
being transferred(apart from beingtransferred back to
the original Registrar
in cases where both
Registrars so agree
and/or where adecision in thedispute resolution
process so directs).
"Transferred" shall
only mean that aninter-registrartransfer has
occurred inaccordance with theprocedures of thispolicy.

A domain name is within
60 30 days (or a lesser
period to be determined)
after being transferred(apart from beingtransferred back to theoriginal Registrar in cases
where both Registrars so
agree and/or where adecision in the dispute
resolution process so
directs). "Transferred"
shall only mean that aninter-registrar transfer
has occurred inaccordance with theprocedures of this policy.

Per working group Preliminary
Recommendation 16, the Registrar MUST
restrict the RNH from transferring adomain name to a new Registrar within 30
days of the initial registration date.
“Whois” has been updated to “RDDS”
consistent with Preliminary
Recommendation 14.
Per working group Preliminary
Recommendation 17, the Registrar MUST
restrict the RNH from transferring adomain name to a new Registrar within 30
days of the completion of an interRegistrar transfer.

Preliminary Recommendation 21: The working group recommends revising the reasonsthat the Registrar of Record MUST deny a transfer request as follows:
Reference Current Text

Revision

Rationale

I.A.3.8.1

A pPending UDRP
proceeding that theRegistrar has been
informed notified of by
the Provider inaccordance with the
UDRP Rules.

The working group has refined thecurrent text in an effort to clarify that
Registrars must deny inter-Registrartransfer requests that are received after a
Registrar has been notified by a UDRP
Provider of a UDRP proceeding inaccordance with the UDRP Rules.

A pending UDRP
proceeding that theRegistrar has been
informed of.

Page 35 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

I.A.3.8.2

Court order by acourt of competentjurisdiction.

N/A

The working group believes that thisprovision continues to be appropriate
and that the language is sufficiently clear.

I.A.3.8.3

Pending dispute
related to a previoustransfer, pursuant to
the Transfer Dispute
Resolution Policy.

Pending dispute related
to a previous transfer,
pursuant to under theTransfer Dispute
Resolution Policy.

This revision is editorial in nature. It is notintended to change the meaning of theprovision.

I.A.3.8.4

URS proceeding or
URS suspension that
the Registrar has
been informed of.

Pending URS proceedingor URS suspension that
the Registrar has been
informed notified of by
the Provider inaccordance with the URS
Procedure.

The term “pending” has been added forconsistency with language in I.A.3.8.1 andI.A.3.8.3. In addition, the working grouphas refined the current text in an effort toclarify that Registrars must deny interRegistrar transfer requests that arereceived after a Registrar has been
notified by a URS Provider of a URS
proceeding or URS suspension inaccordance with the URS Procedure.

I.A.3.8.5

The Registrar
imposed a 60-day
inter-registrartransfer lockfollowing a Change
of Registrant, andthe Registered Name
Holder did not opt
out of the 60-day
inter-registrartransfer lock prior to
the Change ofRegistrant request.

N/A

The Working Group is not proposing any
revisions at this time. Per the working
group charter, Change of Registrant will
be addressed in Phase 1(b) of the PDP.
The working group will revisit I.A.3.8.5
once it has completed deliberations on
Change of Registrant.

Preliminary Recommendation 22: The working group recommends changing thefollowing reasons that the Registrar of Record currently MAY NOT deny a transfer into
reasons that the Registrar of Record MUST NOT deny a transfer and revising the text asfollows:
Reference Current Text

Revision

Rationale

I.A.3.9.1

Implementation
Guidance: Registrars areprohibited from denying
domain name transfer
requests based on nonpayment of fees forpending or future

The Working Group has provided
Implementation Guidance in response to
input from ICANN’s Contractual
Compliance Department that it would be
helpful to provide additional guidanceconsistent with the Registrar Advisory
dated 3 April 2008 which states, “Pursuant

Nonpayment for apending or future
registration period.

Page 36 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

registration periods
during the Auto-Renew
Grace Period, provided
that any auto-renewal
costs borne by theRegistrar are reversible
for future period.

to the Transfer Policy, registrars areprohibited from denying domain nametransfer requests based on non-paymentof fees for pending or future registration
periods during the Auto-Renew Grace
Period.”I.A.3.9.2

No response fromthe Registered Name
Holder or
Administrative
Contact.

No response from theRegistered Name Holder.
or Administrative
Contact

Under the Registration Data Policy,
Administrative Contact data is no longer
collected by the registrar. Accordingly, theRNH would be the only authorized transfer
contact. This update is consistent with
Preliminary Recommendation 15.

I.A.3.9.3

Domain name inRegistrar Lock
Status, unless theRegistered Name
Holder is provided
with the reasonable
opportunity andability to unlock thedomain name prior
to the Transfer
Request.

A registrar-applied interregistrar transfer lock isin place on the Ddomainname in Registrar Lock
Status, for reasons otherthan those specified in
I.A.3.7 and I.A.3.8 unlessand the Registered
Name Holder is notprovided with thereasonable opportunity
and ability to unlock thedomain name prior to
the Transfer Request
pursuant to therequirements in sections
I.A.5.1 - I.A.5.4.

The updates are primarily intended to
improve clarity of the provision, useterminology that will be commonly
understood, and refer to the relevant
provisions that should be referenced
alongside I.A.3.9.3.

I.A.3.9.4

Domain nameregistration period
time constraints,
other than during
the first 60 days of
initial registration,
during the first 60
days after a registrartransfer, or during
the 60-day lockfollowing a Change
of Registrant
pursuant to Section
II.C.2.

Domain nameregistration period time
constraints, other thanas defined in I.A.3.7.5
and I.A.3.7.622 during
the first 60 days of initial
registration, during thefirst 60 days after aregistrar transfer , orduring the 60-day lockfollowing a Change ofRegistrant pursuant to
Section II.C.2.

The working group updated the language
to reference the applicable provisions of
the policy rather than repeating thedetails of those provisions.
Change of Registrant will be addressed inPhase 1(b) of the PDP. Reference to the“60-day lock following a Change ofRegistrant pursuant to Section II.C.2” mayneed to be revisited following completionof Phase 1(b).

22 In implementation, to the extent that there is re-numbering of applicable provisions, this reference

should be updated accordingly.

Page 37 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report
I.A.3.9.5

General payment
defaults between
Registrar andbusiness partners /affiliates in cases
where theRegistered Name
Holder for thedomain in question
has paid for theregistration.

General payment
defaults between
Registrar and Reseller, as
defined in the RAA,
business partners /affiliates in cases where
the Registered Name
Holder for the domain inquestion has paid for theregistration.

Date: 16 June 2022

The update is not intended to change themeaning of the provision, but rather toupdate legacy language to be consistent
with currently used and definedterminology.

3.4.2 Charter Question h2
Should additional guidance around cases subject to a UDRP decision be provided toensure consistent treatment by all Registrars? If so, is this something that should beconsidered by the RPMs PDP Working Group’s review of the UDRP, or should it be
conducted within a Transfer Policy PDP?
Working Group Response:
The working group reviewed the World Intellectual Property Organization’s (WIPO)
detailed comment in response to the Transfer Policy Status Report and has noted twoconcerns involving a UDRP proceeding vis-à-vis the Transfer Policy. Specifically, WIPO
has noted issues related to: (i) the locking of a domain name subject to a UDRP
proceeding (in order to prevent an inter-Registrar transfer during the pendency of theproceeding),23 and (ii) the implementation of a UDRP Panel’s order to transfer a domainname to a complainant.24
Domain Name Locking
UDRP Rule 4(b) provides, in part, “Within two (2) business days of receiving theProvider's verification request, the Registrar shall [ . . . ] confirm that a Lock 25 of thedomain name has been applied. [ . . . ] The Lock shall remain in place through theremaining Pendency of the UDRP proceeding. [ . . . ].” Additionally, Paragraph I.A.3.8.1of the Transfer Policy requires registrars to deny any requests for inter-registrartransfers during “a pending UDRP proceeding that the Registrar has been informed of.”23 For specific policy requirements, please see UDRP Rule 1 (definitions of Lock and Pendency,

respectively), UDRP Rule 4(b), and Paragraph I.A.3.8.1 of the Transfer Policy.
24 For specific policy requirements, please see UDRP Section 4(i), 4(k), UDRP Rule 16(a).
25 UDRP Rule 1 defines Lock as “a set of measures that a Registrar applies to a domain name, which
prevents at a minimum any modification to the registrant and Registrar information by the Respondent,
but does not affect the resolution of the domain name or the renewal of the domain name.”

Page 38 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Within its preliminary recommendations, the working group has proposed to update thecurrent Transfer Policy language to:“The Registrar of Record MUST deny a transfer request in the following circumstances:• Pending UDRP proceeding that the Registrar has been notified of by the Provider
in accordance with the UDRP Rules.”The working group is proposing a slight refinement to the current text in an effort toclarify that Registrars must deny inter-Registrar transfer requests that are received after
a Registrar has been notified by a UDRP Provider of a UDRP Proceeding in accordancewith the UDRP Rules.
In response to WIPO’s related concern that “the ambiguity associated with ‘locking’ adomain name has resulted in many improper domain name transfers,” the working
group notes that the definition of Locking is part of the UDRP Rules, and, accordingly,
appears out of scope for this working group to address. The working group does note,though, that the proposed updates to the Transfer Policy endeavor to make clear that
Registrars are forbidden from implementing inter-Registrar transfer requests received
following a notification from a UDRP Provider of a pending UDRP proceeding.
In the event a Registrar mistakenly or purposefully effects an inter-Registrar transfer
during the pendency of a UDRP proceeding, this would be a clear violation of theTransfer Policy and should be referred to ICANN org Contractual Compliance for review.
The working group will flag the definitional issue of “locking” with the Rights Protection
Mechanisms (RPMs) Phase 2 Working Group, who will be closely reviewing the UDRP,
and will be in a better position to determine if updates are needed.
Implementation of UDRP Panel Decisions
The working group also discussed WIPO’s noted concern regarding the reported refusalof some Registrars to effect a UDRP Panel’s decision to transfer a disputed domainname(s) to the Complainant.
Paragraph 4(i) of the UDRP provides that a UDRP Complainant may request thefollowing remedies in its UDRP Complaint, “the cancellation of [a disputed] domainname or the transfer of [a disputed] domain name registration to the complainant.”(emphasis added). Paragraph 4(k) goes on to provide, in part, “if an Administrative Paneldecides that [the disputed] domain name registration should be canceled or transferred,[the Registrar of Record] will wait ten (10) business days [ . . . ] before implementing thatdecision [to cancel or transfer the disputed domain name].” (emphasis added)
Registrar representatives within the working group noted various methods theircompanies use to implement UDRP decisions, including, for example, providing thePage 39 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

AuthInfo Code to the Complainant to effect the inter-Registrar transfer, setting up an
account for the Complainant and transferring the name to the new account, et. al. The
working group discussed that so long as the Registrar of Record effects the Panel’sdecision by allowing transfer of the domain name, the Registrar would be in compliancewith the UDRP, and the working group was reluctant to recommend specificimplementation restrictions.
The working group noted that a Registrar refusal to implement a UDRP Panel’s decision
to cancel or transfer the disputed domain name to the Complainant, absent official
documentation of a court proceeding,26 would be a violation of the UDRP, and,accordingly, should be referred to ICANN org Contractual Compliance for review. The
working group noted that it will refer this reported issue of UDRP decision
implementation to the RPMs Phase 2 Working Group, as the working group believed thespecific implementation around UDRP decisions to be out of scope for the Transfer
Policy.

26 See UDRP, Paragraph 4(k).

Page 40 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

4 Next Steps
This Initial Report will be posted for Public Comment for 42 days. The working group will
review the Public Comments received on this Initial Report and consider whether any
changes need to be made to its Phase 1(a) recommendations. The working group willcomplete Phase 1(b) of its work, including a Phase 1(b) Initial Report followed by a
Public Comment period on the Phase 1(b) Initial Report. The working group will finalize
all Phase 1 recommendations in a Final Report to be sent to the GNSO Council forreview. If adopted by the GNSO Council, the Final Report would then be forwarded to
the ICANN Board of Directors for its consideration and, potentially, approval as an
ICANN Consensus Policy.
Following a charter review process, Phase 2 of the PDP will commence.

Page 41 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Annex A ‐ Background
The Transfer Policy, formerly referred to as the Inter‐Registrar Transfer Policy (IRTP), isan ICANN consensus policy that went into effect on 12 November 2004. The policy
governs the procedure and requirements for registrants to transfer their domain names
from one Registrar to another, also referred to as an inter-Registrar transfer. The goal of
the Transfer Policy was to provide for enhanced domain name portability, resulting in
greater consumer and business choice and enabling registrants to select the Registrar
that offers the best services and price for their needs.
On April 22, 2019, ICANN org delivered the Transfer Policy Status Report to the GNSO
Council. ICANN org delivered the Transfer Policy Status Report pursuant to
Recommendation 17 of the Inter-Registrar Transfer Policy (IRTP) Part D PDP Working
Group’s Final Report, which provides, “[t]he Working Group recommends that
contracted parties and ICANN should start to gather data and other relevant
information that will help inform a future IRTP review team in its efforts.” The Transfer
Policy Status Report provided a foundation to review the history and underlying goals ofTransfer Policy, the five policy development processes that sought to improve theTransfer Policy, and associated metrics on the Transfer Policy.
During its meeting on September 19, 2019, the GNSO Council agreed to launch a call forvolunteers for a Transfer Policy Review Scoping Team, comprised of interested andknowledgeable GNSO members that were tasked with advising the GNSO Council byproviding recommendations on the following:• approach to the review (for example, by initiating a new PDP);• composition of the review team or PDP working group, and• scope of the review and future policy work related to the Transfer Policy.
On April 6, 2020, the Transfer Policy Review Scoping Team delivered its Transfer Policy
Review Scoping Paper to the GNSO Council for its consideration. The Scoping Team
recommended that the GNSO Council instruct ICANN org policy support staff to draft an
Issue Report, outlining, et.al., the issues described in its Scoping Report. On 23 June
2020, the GNSO Council voted to approve a motion requesting a Preliminary Issue
Report, for delivery as expeditiously as possible, on the issues identified in the Transfer
Policy Initial Scoping Paper, to assist in determining whether a PDP or series of PDPs
should be initiated regarding changes to the Transfer Policy.
The Final Issue Report addressed eight issues associated with the Transfer Policy, sevenof which were specifically identified by the Transfer Policy Review Scoping Team:
a.
b.
c.

Gaining & Losing Registrar Form of Authorization (“FOA”)
AuthInfo Code Management
Change of Registrant
Page 42 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report
d.
e.
f.
g.
h.

Date: 16 June 2022

Transfer Emergency Action Contact (“TEAC”)
Transfer Dispute Resolution Policy (“TDRP”)
Reversing/NACKing Transfers
ICANN-Approved Transfers
EPDP Phase 1, Recommendation 27, Wave 1 Report

On 18 February 2021, The GNSO Council passed a resolution to initiate a two-phased
PDP to review the Transfer Policy using the approach recommended in the Final Issue
Report:•••Phase 1(a): Form of Authorization (including EPDP Phase 1, Recommendation 27,
Wave 1 FOA issues) and AuthInfo Codes
Phase 1(b): Change of Registrant (including EPDP Phase 1, Recommendation 27,
Wave 1 Change of Registrant issues)
Phase 2: Transfer Emergency Action Contact and reversing inter-Registrartransfers, Transfer Dispute Resolution Policy (including EPDP Phase 1,
Recommendation 27, Wave 1 TDRP issues), Denying (NACKing) transfers, ICANNapproved transfers

The topic of denying (NACKing) transfers was later moved to Phase 1(a) by Project
Change Request to ensure that the working group could examine all elements of the
security model for domain name transfers in a holistic manner as part of its Phase 1deliberations.
A small group of Councilors reviewed the draft charter included in the Final Issue Reportand finalized the document. The charter was approved by Council on 24 March 2021.
The Phase 1(a) working group held its first meeting on 14 May 2021.

Page 43 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Annex B ‐ Working Group Membership andAttendance
The Working Group held its first meeting in April 2021. Recordings and transcripts of thegroup’s discussions can be found on its wiki space. It has conducted its work primarily
through weekly conference calls, in addition to email exchanges on its mailing list.
As instructed by the GNSO Council, the Working Group prepared a work plan, which it
reviewed on a regular basis. The Working Group Chair and the GNSO Council Liaison to
the Working Group also provided regular reports to the GNSO Council regarding thestatus and progress of the group’s work. Details of the project schedule, attendance andaction items can be found in the monthly project packages.
The Working Group email archives can be found athttps://mm.icann.org/pipermail/gnso-tpr/.

Plenary Meetings:• 50 Plenary calls (w/ 4 cancelled) for 68.5 call hours for a total of 1506.0 personhours• 81.4% total participation rate
Small Team Meetings:• 8 Small team calls for 8.0 call hours for a total of 78.0 person hours• 100.0% total participation rate
Leadership Meetings:• 49 Leadership calls (w/6 cancelled) for 23.0 call hours for a total of 212.0 person
hours

Page 44 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Working Group Activity Metrics:

Page 45 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

The Members of the Working Group are:Represented Group

SOI

Start Date

DepartDate

At-Large Advisory Committee(ALAC)
Nanghaka Daniel Khauka
SOI
5/4/2021
Steinar Grøtterød
SOI
5/5/2021
Commercial Business Users Constituency (BC)Zak Muscovitch
SOI
4/23/2021
GNSO Council
Gregory DiBiase
SOI
6/4/2021
Roger Carney
SOI
4/23/2021
Independent
Steve Crocker
SOI
4/26/2021
Intellectual Property Constituency (IPC)
Mike Rodenbaugh
SOI
4/21/2021
Salvador Camacho Hernandez
SOI
4/26/2021
Internet Service Providers and Connectivity Providers Constituency (ISPCP)John Woodworth
SOI
4/14/2021
Non-Commercial Stakeholder Group (NCSG)
Farzaneh Badiei
SOI
6/1/2021
Wisdom Donkor
SOI
6/1/2021
Registrar Stakeholder Group (RrSG)
Antonia Nan Chu
SOI
5/6/2021
Catherine Merdinger
SOI
4/27/2021
Crystal Ondo
SOI
4/23/2021
Eric Rokobauer
SOI
4/26/2021
Keiron Tobin
SOI
6/7/2021
Owen Smigelski
SOI
4/27/2021
Prudence Malinki
SOI
4/27/2021
Richard Merdinger
SOI
5/5/2021
6/7/2021
Sarah Wyld
SOI
4/23/2021
Theo Geurts
SOI
4/23/2021
Thomas Keller
SOI
4/26/2021
9/27/2021
Volker Greimann
SOI
4/24/2021
Registry Stakeholder Group (RySG)James Galvin
SOI
4/27/2021
Richard Wilhelm
SOI
3/4/2022
Totals:Attended %

Role

73.9%
69.6%
78.3%
91.3%
91.3%
86.4%
71.4%
100.0%
23.9%
23.9%
32.6%
47.8%
17.4%
84.8%
84.8%
53.5%
37.2%
69.8%
88.7%
97.8%
80.4%
76.1%
95.6%
90.5%
87.0%
97.8%
100.0%
87.0%
89.1%
56.3%
97.4%
82.1%
80.4%
90.0%
75.8%

Liaison
Chair

Page 46 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

The Alternates of the Working Group are:Represented Group
SOIAt-Large Advisory Committee(ALAC)
Lutz Donnerhacke
SOI
Raymond Mamattah
SOI
Commercial Business Users Constituency (BC)Arinola Akinyemi
SOI
Non-Commercial Stakeholder Group (NCSG)
Akinremi Peter Taiwo
SOI
Registrar Stakeholder Group (RrSG)
Andrew Reberry
Arnaud Wittersheim
SOI
Essie Musailov
SOI
Jacques Blanc
SOI
Jody Kolker
SOI
Jothan Frakes
SOI
Min Feng
SOI
Pam Little
SOI
Richard Brown
SOI
Registry Stakeholder Group (RySG)
Beth Bacon
SOI
Totals:Start Date

DepartDate

Attended %

Role

90.7%
89.7%
92.0%
100.0%
100.0%
71.4%
71.4%
97.1%
0.0%
96.7%
100.0%
66.7%
100.0%
100.0%
50.0%
50.0%
100.0%
97.0%
97.0%
95.8%

5/8/2021
5/4/2021
8/12/2021
6/2/2021

5/5/2021
4/23/2021
4/29/2021
5/7/2021
4/23/2021
4/26/2021
4/26/2021
4/26/2021
5/4/2021

There are a total of 33 Observers to the Working group.
ICANN org Policy Staff Support for the Working Group:
Represented Group
SOI
Start Date
Internet Corporation for Assigned Names & Numbers (ICANN)
Berry Cobb
Caitlin Tubergen
Devan Reed
Emily Barabas
Holida Yanik
Isabelle Colas
Julie Bisland
Julie Hedlund
Michelle DeSmyter
Nathalie Peregrine
Terri Agnew

DepartDate

Attended %Page 47 of 55

RoleTransfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Annex C ‐ Community Input
4.1 Request for Input
According to the GNSO’s PDP Manual, a PDP working group should formally solicit
statements from each GNSO Stakeholder Group and Constituency at an early stage of its
deliberations. A PDP working group is also encouraged to seek the opinion of other
ICANN Supporting Organizations and Advisory Committees who may have expertise,
experience or an interest in the issue. As a result, the working group reached out to all
ICANN Supporting Organizations and Advisory Committees as well as GNSO Stakeholder
Groups and Constituencies with a request for input at the start of its deliberations. In
response, statements were received from:◼

The GNSO Business Constituency (BC)◼

The Registries Stakeholder Group (RySG)◼

The At-Large Advisory Committee (ALAC)◼

The Security and Stability Advisory Committee (SSAC)

The full statements can be found on the working group wiki here:
https://community.icann.org/x/tIT8CQ.

4.2 Review of Input Received
All of the statements received were added to the to the relevant working documents
and considered by the working group in the context of deliberations on each topic.

Page 48 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Annex D – EPDP Phase 1, Recommendation 27, Wave 1 Analysis
For context on this analysis, please see pages 52-56 of the Final Issue Report.
Wave 1 Analysis Key Points
1. Transfer Policy section I.A.1.1 provides that either the Registrant
or the Administrative Contact can approve or deny a transfer
request. (emphasis added) Under the Registration Data Policy,
Administrative Contact data is no longer collected by theregistrar. Accordingly, the registrant would be the only
authorized transfer contact.

2.

Transfer Policy section I.A 2.1, Gaining Registrar Requirements,
relies on the specification of transfer authorities in section 1.1,
defining either the Registrant and Administrative Contact as a"Transfer Contact.” Given that Administrative Contact data is nolonger collected by the registrar, there may not be a need for“transfer contact” terminology, but such references can be
replaced by “registrant” as the registrant is the only validtransfer authority. “Transfer Contact” terminology is referenced
in part I (A) of the policy in sections 2.1, 2.1.1, 2.1.2, 2.1.2.1,
2.1.3.1(b), 2.1.3.3, 2.2.1, 3.2, 3.3, 3.6, 3.7.4, and 4.1.

TPR Working Group Response
In its current set of preliminary recommendations, the TPR Working
Group does not include the Administrative Contact as an entity that
can approve an inter-Registrar transfer; instead, the preliminary
recommendations only refer to the Registered Name Holder, or, insome instances, the “Registered Name Holder or their designatedrepresentative.”
In light of the obsolescence of the Administrative Contact under the
EPDP Phase 1 recommendations, any reference to an “Administrative
Contact” or “Transfer Contact” within the Transfer Policy MUST beeliminated and replaced with “Registered Name Holder” unlessspecifically indicated, per Preliminary Recommendation 15. For
example, Preliminary Recommendation 6, et. al., refers to the“Registered Name Holder or their designated representative”.
As noted above in Key Point 1, the preliminary recommendations
currently refer to the “Registered Name Holder” instead of the“Transfer Contact”, noting that the Registered Name Holder is the
now the valid transfer authority, rather than the “Transfer Contact” or“Administrative Contact”.

Page 49 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

3.

4.

5.

Transfer Policy section I.A.3 enumerates the reasons a registrarof record may deny a transfer. These include section 3.7.2,“reasonable dispute over the identity of the Registered Name
Holder or Administrative Contact.” The Administrative Contact
reference may be eliminated as the Administrative Contact data
is no longer collected by the registrar. Section I.A.3 also
enumerates the reasons a registrar of record may not use todeny a transfer request. These include section 3.9.2, “noresponse from the Registered Name Holder or Administrative
Contact.” The Administrative Contact reference may beeliminated as the Administrative Contact data is no longer
collected by the registrar.
Transfer Policy section I.A.4.6.5 provides that both registrars willretain correspondence in written or electronic form of any
Transfer Emergency Action Contact (TEAC) communication andresponses, and share copies of this documentation with ICANN
and the registry operator upon request. This requirement does
not appear to be affected by the new Registration Data Policy,
which provides for retention of data elements for a period of 18
months following the life of the registration.
Transfer Policy section I.A.5.6 provides that the "AuthInfo" codes
must be used solely to identify a Registered Name Holder,
whereas the Forms of Authorization (FOAs) still need to be used
for authorization or confirmation of a transfer request, as
described in Sections I.A.2, I.A.3, and I.A.4 of the policy. Where
registrant contact data is not published, and absent an available
mechanism for the Gaining Registrar to obtain such contact data,
it is not feasible for a Gaining Registrar to send an FOA to theregistrant contact data associated with an existing registration,
as required by the policy. However, the requirement for theRegistrar of Record to send an FOA confirming a transfer request

Date: 16 June 2022

The working group is recommending that the reference toAdministrative Contact in Section I.A.3.7.2 must be removed due tothe EPDP recommendation for elimination of the Administrative
Contact. See also TPR Preliminary Recommendation 15.

Defer further discussion to Phase 2 of the PDP.

In its preliminary recommendations, the working group isrecommending eliminating the requirement that the Gaining Registrar
send a Gaining Form of Authorization.
For further rationale on the proposed elimination of the Gaining FOA,
please see the working group’s response to charter question a1.
With respect to the Losing FOA, the working group is recommending
to replace the requirement for the Losing FOA (see Preliminary
Recommendation 2). Instead, the working group is recommending to
introduce two new required notifications to be sent from the Losing
Registrar to the Registered Name Holder, namely (i) a notification ofPage 50 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report(covered in section I.A.3) is still achievable as the registrar does
not need to rely on publicly available data.

6.

7.

8.

Transfer Policy section II.B.1, Availability of Change of Registrant,
provides that “Registrants must be permitted to update theirregistration/Whois data and transfer their registration rights toother registrants freely.” This language may be updated to clarify
what updating registration data means, i.e., whether
requirements differ according to whether a change of registrant
changes anything that is displayed.
Transfer Policy section II.B.1.1.4 references the Administrative
Contact. The context of this provision is to define a change ofregistrant as a material change to certain fields, including“Administrative Contact email address, if there is no Prior
Registrant email address.” This section may no longer benecessary, as, under the new Registration Data Policy,
Administrative Contact data is no longer collected by theregistrar.
The Transfer Policy contains references to Whois in sections
I.A.1.1, I.A.2.1.2, I.A.2.2.1, I.A.3.6, I.A.3.7.5, I.B.1, and the Notes
section titled “Secure Mechanism.” If updates are considered tothis policy as a result of GNSO policy work, it may be beneficial toconsider replacing these references with RDDS. (The Temporary
Specification, Appendix G, Section 2.2.4, on Supplemental
Procedures to the Transfer Policy, provides that the term
"Whois" SHALL have the same meaning as "RDDS.” This is carriedover in the EPDP Phase 1 recommendation 24) Transfer Policy
section II.C.1.4 provides that a registrar must obtain confirmationof a Change of Registrant request from the Prior Registrant, or
the Designated Agent of such, using a secure mechanism toDate: 16 June 2022

provision of the Transfer Authorization Code (TAC), formerly referred
to as the Auth-Info Code (see Preliminary Recommendation 3), and (ii)and a notification of inter-Registrar transfer request completion(Preliminary Recommendation 4).
Defer discussion to Phase 1(b) of the PDP.

Defer discussion to Phase 1(b) of the PDP.

For terminology consistency, the working group is recommending
replacing current references to Whois to RDDS throughout theTransfer Policy for any references to Whois that remain. (Please see
response to Key Item 9 below for more detail and Preliminary
Recommendation 14.)
Discussions related to Section II of the policy (Change of Registrant)
will be deferred to Phase 1(b) of the PDP.

Page 51 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report9.

confirm that the Prior Registrant and/or their respective
Designated Agents have explicitly consented to the Change ofRegistrant. The footnote to this section notes that “The registrar
may use additional contact information on file when obtaining
confirmation from the Prior Registrant and is not limited to the
publicly accessible Whois.” If changes are considered to thispolicy as a result of GNSO policy work, it may be beneficial toconsider updating this footnote to eliminate the reference toWhois.
The EPDP Team’s Phase 1 Recommendation 24 recommends thatthe following requirements apply to the Transfer Policy until
superseded by recommendations from the Transfer Policy review
being undertaken by the GNSO Council:(a) Until such time when the RDAP service (or other secure
methods for transferring data) is required by ICANN to beoffered, if the Gaining Registrar is unable to gain access to thencurrent Registration Data for a domain name subject of atransfer, the related requirements in the Transfer Policy will besuperseded by the below provisions:(a1) The Gaining Registrar is not REQUIRED to obtain a Form of
Authorization from the Transfer Contact.
(a2) The Registrant MUST independently re-enter Registration
Data with the Gaining Registrar. In such instance, the Gaining
Registrar is not REQUIRED to follow the Change of Registrant
Process as provided in Section II.C. of the Transfer Policy.

Date: 16 June 2022

In its preliminary recommendations, the working group isrecommending eliminating the requirement that the Gaining Registrar
send a Gaining Form of Authorization (Preliminary Recommendation
1).
In Preliminary Recommendation 14, the working group isrecommending the terminology changes from EPDP Phase 1,
Recommendation #24. Specifically:(b) As used in the Transfer Policy:(b1) The term "Whois data" SHALL have the same meaning as"Registration Data".
(b2) The term "Whois details" SHALL have the same meaning as"Registration Data".
(b3) The term "Publicly accessible Whois" SHALL have the same
meaning as "RDDS".

(b) As used in the Transfer Policy:

Page 52 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report(b1) The term "Whois data" SHALL have the same meaning as"Registration Data".
(b2) The term "Whois details" SHALL have the same meaning as"Registration Data".

Date: 16 June 2022(b4) The term "Whois" SHALL have the same meaning as "RDDS".
With respect to (c) and (d), the working group has a list of very
specific preliminary recommendations regarding generating andupdating the TAC (formerly referred to as Auth-Info Code) that can befound in Section 3.2 of the Initial Report.

(b3) The term "Publicly accessible Whois" SHALL have the same
meaning as "RDDS".
(b4) The term "Whois" SHALL have the same meaning as "RDDS".
(c) Registrar and Registry Operator SHALL follow best practices ingenerating and updating the "AuthInfo" code to facilitate asecure transfer process.
(d) Registry Operator MUST verify that the "AuthInfo" codeprovided by the Gaining Registrar is valid in order to accept aninter-registrar transfer request.
These requirements are being implemented as part of
implementing the Registration Data Policy.
10. Feedback from some stakeholders in June 2019 during an
ICANN65 session suggested an approach of starting from a cleanslate rather than looking at specific transfer issues individually.
This appears to be the path the GNSO is taking, based on
discussions at the September Council meeting.
Cross-reference: Transfer Policy section I.B.3.1 contains a footnote
referencing the Expired Registration Recovery Policy. The context forthis reference is a provision specifying when the Change of Registrant
Procedure does not apply, in this case, when the registrationagreement expires. The footnote provides that if registration and

The working group has methodically worked through its charter
questions, which has enabled it to review previously identified andlongstanding issues in the Transfer Policy by proposing slightadjustments to specific transfer issues and/or proposing new
methods.
Defer discussion to Phase 1(b) of the PDP.

Page 53 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Whois details are changed following expiration of the domain namepursuant to the terms of the registration agreement, the protectionsof the Expired Registration Recovery Policy still apply.
Cross-reference: Transfer Policy section I.B.3.5 references the Expired
Domain Deletion Policy. The context for this reference is a provision
specifying when the Change of Registrant Procedure does not apply, inthis case, when the Registrar updates the Prior Registrant's
information in accordance with the Expired Domain Deletion Policy.

Date: 16 June 2022

Defer discussion to Phase 1(b) of the PDP.

Page 54 of 55

Transfer Policy Review PDP WG Phase 1(a) Initial Report

Date: 16 June 2022

Annex E – Proposed Transfer Policy Swim Lane Diagram
This swim lane diagram should be reviewed alongside a detailed review of each the proposed recommendations listed in this report.
It attempts to outline the beginning-to-end process of executing the transfer of a domain by the roles that are played within thetransaction. Each spot that coincides with a working group recommendation will contain a small callout to the relevant charter
question(s) and recommendation number(s).
A full PDF version of this swim lane diagram can be found on the working group’s wiki space.

Page 55 of 55