2. If your response requires an edit or deletion of Recommendation #11, please indicate the revised wording and rationale here.

RFC9151 says: "The registrar's interface for communicating the authorization information with the registrant MUST be over an authenticated and encrypted channel." RFC9151 provides guidance based on IT best security practices. This recommendation allows a Registrar to send the authorization information via email, which is usually unencrypted and unauthenticated, thereby going against the language and intent of RFC9151.

2. If your response requires an edit or deletion of Recommendation #14, please indicate the revised wording and rationale here.

ICANN org acknowledges that Recommendation 5 defines the Transfer Authorization Code (TAC) as a token created by the Registrar of Record and provided upon request to the RNH or their designated representative. Additionally, it defines the "designated representative" as an individual or entity explicitly authorized by the RNH to request and obtain the TAC on their behalf. In line with this, ICANN org recommends updating the language of Recommendation 14 to explicitly require registrars to retain all records related to the provision of the TAC, whether to the RNH or their designated representative, as follows: 'The Registrar MUST retain all records pertaining to the provision of the Transfer Authorization Code (TAC) to a Registered Name Holder or their designated representative...'

2. If your response requires an edit or deletion of Recommendation #16, please indicate the revised wording and rationale here.

Registries that use the IANA ID as their internal IDs for registrars should not have an issue implementing this. Registries that use different IDs may need to implement an EPP extension to provide this information in EPP. Creating a new EPP extension will likely require Registries and Registrars to work in the IETF to standardize such an extension. When reviewing this recommendation, it was unclear to ICANN org if it requires providing this information in EPP or if providing it offline is an option.

2. If your response requires an edit or deletion of Recommendation #19, please indicate the revised wording and rationale here.

Input for Implementation Guidance: ICANN org would like to bring to the Working Group’s attention that, following the completion of a transfer, the Privacy/Proxy service in place prior to the transfer may be canceled or deactivated. This could render the Privacy/Proxy contact details invalid, potentially preventing the underlying customer from receiving the required Notification of Transfer Completion.

2. If your response requires an edit or deletion of Recommendation #21, please indicate the revised wording and rationale here.

ICANN org is assuming that “RegistrarHold” refers to "ClientHold" status in the EPP. ICANN org recommends using the standard terminology as provided by the EPP in such cases. ICANN org recommends separating the reason for denial stated in A.I.3.7.1, which is currently phrased as "Evidence of (a) fraud or (b) DNS Abuse as defined in Section 3.18.1 of the Registrar Accreditation Agreement," into two distinct categories: "Evidence of fraud" and "Evidence of DNS Abuse as defined in Section 3.18.1 of the Registrar Accreditation Agreement." Since “fraud” is not defined in the RAA, this distinction will help reduce confusion and prevent challenges arising during enforcement.

2. If your response requires an edit or deletion of Recommendation #26, please indicate the revised wording and rationale here.

ICANN org does not have any concerns about enforcing two separate policies. However, it is worth noting that in 2016, the Inter-Registrar Transfer Policy (IRTP) was renamed to Transfer Policy to reflect the addition of inter-registrant transfer requirements. The separation of these interconnected aspects, given their intertwined relationship (i.e., one action under one policy results in a lock under the other), can lead to increased confusion. For instance, when either ICANN or registrars must inform a registrant about a domain lock imposed under one policy, removal of the lock requires adherence to provisions outlined in another policy. Additionally, any future review will likely involve reviewing two distinct policies instead of one (potentially risking the oversight of important points), thereby adding further complexity to the review process. 26.1: If the recommendation aims to restrict CORD approval solely to the Registrant, merely removing all mentions of the Designated Agent from the policy will not necessarily and directly resolve the issues and complexity of the matter. This is because there may still be Terms of Service (TOS), registration agreements, powers of attorney, and other similar arrangements through which a Registrant may grant authority to a third party to act on the Registrant's behalf. The recommended changes will pose challenges for both registrars and registrants, many of whom may not want or lack the capability to manage their domain names directly. Registrars will likely include general clauses in their registration agreements and claim that the policy does not explicitly prohibit them from approving CORD on behalf of the registrant. If the intention is to restrict CORD approval exclusively to the Registrant, this should be explicitly stated in the policy alongside the removal of references to the Designated Agent; however, this will likely present significant challenges for many parties. Alternatively, if the goal is to address issues caused by the Designated Agent, it may be more effective to update the definition and role of the Designated Agent to specifically address the identified issues and concerns. 26.2: The WG classified the impact of Recommendation 26.2 as 'LOW'; however, its actual impact will be significant. Specifically, the inclusion of clear reasons for the denial of CORD in the policy is essential for several parties, for the following reasons: - For registrars: Having clear reasons for denial of CORD ensures uniform application of the policy requirements across all registrars, which guarantees that registrants receive predictable outcomes, irrespective of their registrar choice, and makes it more difficult for unauthorized parties to manipulate or fraudulently change domain name registration data, as registrars will have explicit guidelines to reject CORD requests that fail to meet the enumerated requirements. - For registrants: Clear enumeration of denial reasons in the policy (e.g., CORD is not approved by the authorized parties) ensures that their rights are adequately protected. It also helps them better understand the circumstances under which CORD requests must be denied, enabling them to make informed decisions. Most importantly, it prevents abusive denials by registrars and ensures that, as the policy itself reads, registrants are permitted to update their Registration Data and transfer their registration rights to other registrants freely. - For other impacted parties (such as those involved in a UDRP proceeding): The absence of explicit guidelines on when CORD must be denied may lead to an increase in changes to registrant data of domain names that are subject to UDRP proceedings - registrants may attempt to modify domain name registration data in bad faith to evade the consequences of UDRP proceedings. Without clear and explicit denial reasons, ICANN compliance will be unable to evaluate a registrar's decision in this regard and to ascertain whether it aligns with the policy requirements as those requirements will not exist. In light of the above, ICANN org recommends that the policy explicitly includes and clearly outlines the circumstances under which CORD must be denied. Therefore, ICANN org advises the WG to reconsider Recommendation 26.2 to eliminate Section II.B from the policy. 26.4: ICANN org acknowledges the Working Group's rationale that the COR lock has been a source of frustration for registrants, and recognizes the uncertainty regarding whether the 60-day lock effectively reduces instances of domain hijacking. However, ICANN org would like to express its concerns about the implications of removing this lock period for registrants and registrars. Post COR inter-registrar transfer lock provides a buffer period, allowing the Prior Registrant time to detect and address any unauthorized changes made to their domain registration with the registrar of record. It is notably easier to resolve such issues and reclaim the domain name while the domain remains under the control of the registrar of record, compared when it is transferred away to a different registrar. The latter scenario typically involves more complex processes with less desirable or effective outcomes. Eliminating this lock will result in reduced protection afforded to registrants, leaving them more exposed to potential domain theft or fraudulent transfers. This concern is particularly heightened in light of Recommendation 26.2, which suggests eliminating Section II.B “Availability of Change of Registrant,” that enumerates reasons for denying a CORD; Recommendation 26.3, which proposes removing the requirement to obtain confirmation from both the Prior Registrant and the New Registrant prior to processing a CORD; and Recommendation 18, which introduces the possibility of early removal of the mandatory 30-day restriction following an inter-registrar transfer. With these changes, there is an increased likelihood that the registration data could be easily updated by the perpetrator, and the domain name could transition between multiple registrars before the Prior Registrant has an opportunity to take mitigation actions in cases where the CORD was unauthorized or fraudulent.

2. If your response requires an edit or deletion of Recommendation #27, please indicate the revised wording and rationale here.

27.2: In terms of “taking action” by the registrant if the change was invalid, ICANN org recommends that the CORD notification specifies the time period within which the registrant must take action. Similarly, ICANN org recommends that the policy also include requirements explaining the actions a registrar must take (and by when) upon being notified by the registrant of a invalid/unauthorized CORD (e.g. lock the domain name, deny inter-registrar transfer request, etc.) This is all to ensure predictability for all parties involved and enforceability by ICANN compliance (as ICANN compliance cannot enforce a timing that is not included in the policy). 27.3: ICANN org recommends that the policy stipulates that, regardless of the means used, all notifications sent must be properly documented, retained, and made available to ICANN compliance to facilitate the investigation of a CORD complaint. 27.4: Regarding item (b): It is important to note that if the policy states "MAY" and if the registrar chooses not to implement it, ICANN compliance cannot enforce it. The new email address may belong to someone else, and a perpetrator who gains access to it could exploit this. Receiving notification at the new email address can alert the legitimate owner of a compromised email address about the potential unauthorized changes. Even in cases where there is no malicious intent, for the sake of clarity, the registrant will not be able to confirm the change has been completed if notifications are not received at the new address (particularly, in cases where the old email address is outdated) which can cause confusion. Therefore, it is recommended to make this requirement mandatory (i.e., replace "MAY" with "MUST"). Regarding item (c): ICANN org recommends that the policy stipulates that, regardless of the means used, all notifications sent must be properly documented, retained, and made available to ICANN compliance to facilitate the investigation of a CORD complaint. 27.5: ICANN org would like to note that in accordance with Section II.A.1.3.2, any change to the Registered Name Holder's name or organization that is accompanied by a change of address or phone number constitutes a material change. In instances where modifications to the address or phone number occurred in conjunction with a change in the RNH's name or organization, ICANN compliance will require evidence demonstrating compliance with CORD requirements. If the registrar sends additional notification per Rec 27.5, regardless of the means used, notifications sent must be properly documented, retained, and made available to ICANN compliance to facilitate the investigation of a CORD complaint. 27.6: All domain names should be clearly displayed in the notification sent by the Registrar. ICANN org recommends that consolidation should not be permitted when the means chosen to provide the notification does not allow for the listing of each domain name in the CORD. For instance, if character limitations in an SMS prevent the listing of all domains in a single notification, then the registrar may not consolidate and must instead send out individual notifications to cover all domain names subject to the request. It is important that the policy includes the language explicitly specifying this requirement to eliminate ambiguity and assumptions. 27.7: ICANN org recommends that the language of Recommendation 27.7 clearly specify which notification it refers to as "optional Change of Registrant Data notification" to avoid ambiguity and prevent any assumptions (e.g., the CORD notification sent per Recommendation 27.4(b)).

2. If your response requires an edit or deletion of Recommendation #28, please indicate the revised wording and rationale here.

ICANN org has no concerns regarding the enforcement of the provision allowing registrars to offer registrants the ability to opt-out of receiving CORD notifications. However, it is important to note that CORD notifications will serve as a crucial mechanism for providing registrants with visibility and control over changes to their domain registration information. By opting out of these notifications, registrants forfeit this visibility and control over the status of and changes to their domain registrations. Registrants may opt out of receiving CORD notifications without fully understanding the implications of doing so. Before opting out, they may not read or comprehend the required prior explanations and warnings provided by the registrar about the potential risks and consequences of not receiving CORD notifications. If a registrant opts out of CORD notifications, they may not be promptly informed about changes to their domain registration information, including transfers of ownership. Opting out of CORD notifications will hinder registrants' ability to take timely action in response to unauthorized or fraudulent changes to their domain registration information. This lack of awareness and inability to take timely action by the registrants if the change was invalid or unauthorized/fraudulent, can make it easier for malicious actors to execute unauthorized or fraudulent changes to domain ownership without detection. Additionally, with the recommended elimination of the requirement to lock the domain name post-CORD, as outlined in Recommendation 26.4, there is an increased likelihood of the domain name transitioning to a different registrar post-CORD. This transition complicates mitigation efforts in cases where the CORD was unauthorized or fraudulent.

2. If your response requires an edit or deletion of Recommendation #34, please indicate the revised wording and rationale here.

ICANN org notes that it provided feedback to the Working Group on this topic previously. Following that conversation, the team has discussed further and is offering the following to elaborate on its thinking, for consideration by the WG. ICANN org notes that this process as recommended presents difficulties for each of the parties in a bulk transfer (registrants, registrars, and even ROs who might be waiting for other ROs to respond before billing can be initiated). For ICANN org to play the recommended role in the billing and outreach of ROs adds complexity and inefficiency to the bulk transfer process. For instance, in a voluntary termination case ICANN operations dealt with in the past, a Registrar had 50,100 domains (therefore exceeding the 50,000 minimum threshold), spread across 395 different TLDs. The team reached out to all 395 TLDs, manually creating cases for each. The team then also confirmed all domain names were transferred and the number of domain names transferred. This could take up to three instances of outreach to get a response from Registry Operators, meaning as many as 1185 outreach instances in total. Assuming all of the contacted ROs respond back, the team is then aware of whether or not the 50,000 threshold was reached. Then the calculation has to be made of domains managed per TLD. Then, to let them know of the fee that is eligible to be charged. Regarding the fees that ROs are able to charge, 50,000 USD split between 395 TLDs would result in a minor revenue for each RO (for the sake of example, if they were split equally, each would receive 126 USD). If ROs are eligible only to charge a small fee for the full portfolio transfer, the incentive to respond to ICANN’s outreach attempt is very low. The entire process could take months in cases where ROs are unresponsive. Even in cases of voluntary termination, large transfers can also happen. In the cases of Registry families, they could close one TLD, and transfer those domains to another registrar. Thus it is unclear that the involvement of ICANN in tracking and consolidating details of transactions among registries and registrars adds value to the overall process. In the case that the WG would continue with this approach, ICANN org proposes as a possible mitigation that only TLDs with >1000 domains would qualify to charge the fee, as a potential solution to reduce the outreach work needed. In order to cover registry families or ROs who cover more than one TLD, there could be a caveat that the 1000 minimum could be reached through different TLDs, if managed by the same RO. For example, if THIS EXAMPLE Registry operates .THIS and .EXAMPLE, and together, and the combined names of those two total >1000, then THIS EXAMPLE Registry could charge a fee because it meets the threshold.

2. If your response requires an edit or deletion of Recommendation #35, please indicate the revised wording and rationale here.

See comments on Rec 34.

2. If your response requires an edit or deletion of Recommendation #36, please indicate the revised wording and rationale here.

See comments on Rec 34.

2. If your response requires an edit or deletion of Recommendation #37, please indicate the revised wording and rationale here.

See comments on Rec 34.

2. If your response requires an edit or deletion of Recommendation #38, please indicate the revised wording and rationale here.

See comments on Rec 34.

2. If your response requires an edit or deletion of Recommendation #41, please indicate the revised wording and rationale here.

Recommendation 41 mentions "Reseller or service provider". “Resellers” is a known term. However, “service provider” is not a well-known term. Could the PDP WG please explain this further? Does “service provider” mean something other than “reseller”? While the term "reseller" and its contractual relationship with a registrar, as well as registrar's responsibility for the reseller's actions, are defined in the RAA (e.g., Sections 1.26; 3.12), ICANN compliance may encounter challenges in determining whether the Losing Registrar or the Gaining Registrar should be held accountable in instances of reseller's non-compliance or violations. Furthermore, ICANN has no authority to enforce policy requirements or address violations involving third parties, such as service providers, as ICANN does not have a contractual relationship with these entities. Therefore, ICANN org recommends reconsidering the expansion of the standard BTAPPA to include resellers and service providers.

2. If your response requires an edit or deletion of Recommendation #42, please indicate the revised wording and rationale here.

ICANN org recommends that the policy stipulates that, regardless of the means used to notify registrants, notifications sent must be properly documented, retained, and made available to Compliance to facilitate the investigation of a BTAPPA complaint.

2. If your response requires an edit or deletion of Recommendation #46, please indicate the revised wording and rationale here.

Instead of leaving it open how the notice of fees is transmitted to Registrars, could there be a standard way to provide this? Registrars have previously raised the point that talking to multiple Registries presents significant difficulties.