Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
If yes, please explain.
Input on behalf of ICANN org
If your response requires an edit or deletion of Preliminary Recommendation 3, please indicate the revised wording and rationale here.
ICANN org suggests that the WG update in recommendation 3.2 to include additional elements required to be included in the “Notification of TAC Provision” such as: * An element that explains that the TAC will enable the transfer of the domain name to another registrar. * The deadline by which the RNH must take action if the request is invalid so that the registrar has sufficient time to NACK the transfer, where applicable (note that, at the time the RNH receives the “Notification of TAC Provision”, the TAC may have already been provided and the transfer command sent to the registry operator). * Required actions registrars must take (and by when) upon receiving notification by the RNH of an invalid request. Regarding an element that explains the purpose of the TAC, ICANN org believes it is important that the RNH understand the implications of receiving the “Notification of TAC Provision” especially for invalid requests (e.g., hijacking attempt). A RNH who has not requested a transfer may disregard the email without understanding that the domain may be in the process of being hijacked. Similarly, regarding an element that explains the actions a registrar must take (and by when) upon being notified by the RNH of an invalid TAC request, ICANN org understands that the proposed policy recommendation mandates the notification be sent with instructions on the actions the RNH can take if the request is invalid. However, a RNH cannot directly NACK a transfer. The RNH can only inform the registrar that the request was invalid. Org’s assumption is that, should this happen, most registrars will timely NACK a transfer in progress. However, there is currently no requirement for ICANN Compliance to enforce if a registrar does not timely act and NACK the transfer in this situation. Furthermore, if such a scenario were to fall within the current reason for denial in Section I.A.3.7.4 of the Transfer Policy (i.e., express objection of the Transfer Contact), org would like to note that is currently a reason why a registrar MAY deny a transfer and not required to do so (dependent on rec. 20’s approval/implementation details). Hence, a transfer may still proceed even if the RNH has explicitly informed the registrar that the transfer was not requested by the RNH. Lastly, Recommendation 3.2 notes “if the TAC has not been provided via another method of communication, this communication will include the TAC”. ICANN org understands that notifications tend to be in the form of an email, and in general emails typically are not secure methods of communication. RFC9154 in subsection 7 of section 4.3, notes "The registrar's interface for communicating the authorization information with the registrant MUST be over an authenticated and encrypted channel." Thus, ICANN org suggests the WG consider updating the language in recommendation 3.2 to note "If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC." This suggested language change complies with RFC9154.
If your response requires an edit or deletion of Preliminary Recommendation 4, please indicate the revised wording and rationale here.
Based on Org’s understanding of the WG deliberations the “Notification of Transfer Completion'' is sent only after the transfer has been completed and that the recipient of the notification is the RNH which is listed at the time of the transfer request. Recommendation 4 as written seems to imply that the “Notification of Transfer Completion” can be sent at the same time as the request is made because it mentions “the Registration Data at the time of the transfer request.” If the intent of the WG is to have the notification sent once the transfer has been completed, Org suggests rewording the recommendation to make clear that the notification of transfer is sent only once the notification is successfully completed and that the recipient is the RNH as it was reflected the Registration Data at the time of the transfer request Similar to the input provided for Recommendation 3.2, ICANN org recommends the WG consider requiring additional elements to be included as part of the “Notification of Transfer Completion”, such as the timing by when the RNH is required to take action if they believe the transfer is invalid. ICANN org acknowledges that the WG plans to consider and discuss a transfer reversal process in Phase 2 of the Transfer Policy Review PDP. If requirements related to a transfer reversal are adopted, the RNH should be required to take action with sufficient time for the registrar to invoke the reversal process (the policy should also explain if/when and how the registrar must do so) within the period for which a domain is eligible for reversal after inter-registrar transfer.
The WG may want to consider including the gaining registrar IANA ID in the list of elements included in the notification of transfer completion. The Registrar IANA ID data element is superior to identifying the Registrar, because the IANA ID is a unique numeric identifier mitigating the risk of misidentifying the Registrar based on the name. The Registrar IANA ID of the Gaining Registrar could be obtained by querying the RDAP server of the Registry once the transfer is successful.
If your response requires an edit or deletion of Preliminary Recommendation 5, please indicate the revised wording and rationale here.
ICANN org would like to note that though the “Authinfo Code” is not referenced in other ICANN org policies nor in the Registrar Accreditation Agreement (RAA), but referenced on several ICANN.org webpages. ICANN org acknowledges that this update should be made across all platforms including ICANN.org webpages, and suggests the WG consider including an implementation note that clarifies that updates include publications and webpages in accordance with the suggested terminology change.
If your response requires an edit or deletion of Preliminary Recommendation 6, please indicate the revised wording and rationale here.
ICANN org acknowledges the WG considering our initial input and including the definition of “designated representative.” The WG may want to consider including the term “to request” in addition to obtaining the TAC. Specifically, an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf. This is to avert instances where a representative may obtain the TAC that the RNH never intended to request for a transfer the RNH never wanted. Org would also like to note that based on our experience in implementing other recommendations, it is a good idea to have important definitions embedded in the policy recommendations themselves (as opposed to in a footnote) as it will allow ICANN Compliance the ability to easily enforce the requirements when included and clearly described within the text of the policy language. Furthermore, the definition of “Designated Agent” is included within the text of the policy (II.A.1.2). It is unclear why the definition of “Designated representative” has been relegated to a footnote. For consistency and clarity, ICANN org recommends this definition be part of the text within the policy. Additionally, ICANN org acknowledges the concerns raised by the WG that adding language that the RNH’s authority supersedes that of the representative may conflict with agreements between the RNH and a third-party to which the RNH has given authority. Yet, ICANN org would like to point out that it is not uncommon for resellers or web-developers (example of these third-parties) to include general clauses in their agreements granting blanket authority to the reseller or web-developer to manage the domain name (which may be used by the third party to attempt to hinder or process an inter-registrar transfer where there is a dispute). Org would also like to note that “in the event of dispute” it is not within ICANN’s remit to determine how and to which extent an agreement a RNH may enter with a third party may suffice to diminish the protection and authority the Transfer Policy intends to afford to RNHs. Lastly, Org’s recommendation is consistent with the current Transfer Policy which indicates that the RNH and the Administrative Contact “are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the Registered Name Holder's authority supersedes that of the Administrative Contact. “ This is regardless of whether or not the RNH and the Administrative Contact may have a separate agreement.
If your response requires an edit or deletion of Preliminary Recommendation 7, please indicate the revised wording and rationale here.
RFC9154 in section 4.1, notes “ In accordance with current best practices and noting that the authorization information is a machine-generated value, the implementation SHOULD use at least 128 bits of entropy as the value " ICANN org suggests that the WG consider including language that makes the implementation use of 128 entropy a requirement (MUST) rather than optional (SHOULD). Additionally, RFC9154 already includes BCP106 as a normative reference. ICANN org proposes the WG consider an alternative method to write this recommendation such as - “The working group recommends that the minimum requirements for the composition of a TAC MUST be as specified in RFC 9154,including all successor standards, modifications or additions thereto relating to Secure Authorization Information for Transfer). The requirement in section 4.1 of RFC 9154 regarding the minimum bits of entropy (i.e., 128 bits) should be a MUST in the policy until a future RFC approved as “Internet Standards” (as opposed to Informational or Experimental standards) through the applicable IETF processes updates the security recommendation.
If your response requires an edit or deletion of Preliminary Recommendation 8, please indicate the revised wording and rationale here.
Section 5.2 of RFC9154 states: It is critical that registrars only use strong, randomly generated authorization information values. Because of this, registries may validate the randomness of the authorization information based on the length and character set required by the registry -- for example, validating that an authorization value contains a combination of uppercase, lowercase, and non-alphanumeric characters in an attempt to assess the strength of the value and returning an EPP error result of 2202 ("Invalid authorization information") [RFC5730] if the check fails. ICANN Org understands that recommendation 8 optionally instructs the Registry to verify the TAC as described in the paragraph above from RFC9154. If the requirement is optional, as the current text suggests, it seems that RFC9154 suffices, and recommendation 8 could be removed. If the intent of this recommendation is to require the Registry to verify the TAC, the recommendation should include "MUST”
If your response requires an edit or deletion of Preliminary Recommendation 11, please indicate the revised wording and rationale here.
While Org understands that the policy recommendations will be translated in policy language during implementation, in order to prevent any potential misunderstanding by the IRT during implementation, it will be helpful to be more precise on including what the action of “clear” entails in the policy recommendations as Org understands that “clear” entails unsetting the authorization information by the Registry. This will in turn guide more precise policy language which will assist ICANN Compliance in enforcing this requirement against registries where applicable. Additionally, ICANN org suggests the WG consider including the language that specifies a scenario where if the transfer request is not successful (e.g. “NACKED” by the losing registrar), the TAC must also be cleared by the registry operator, and a notification sent by the losing registrar operator explaining that the transfer request was not successful and a new TAC must be generated if a new transfer request is to be generated.
If your response requires an edit or deletion of Preliminary Recommendation 13, please indicate the revised wording and rationale here.
ICANN org suggests being consistent through the policy recommendations, and suggests using the combination of 14 days and 366 hours instead of calendar days alone. Additionally, ICANN org suggests using a more precise term in place of the word “clear,” because it is ambiguous what the term “clear” means in practice. It is ICANN org’s understanding that this term means “unset the authorization information” and is intended to describe the action that a Registry must take after the standard TTL is over. Therefore ICANN org suggests using the phrase “unset the authorization information” instead.
A standard default TTL could be implemented in the Registry or the Registrar. From a security/stability perspective, if the Registrar can unset the TAC earlier than the standard TTL, the Registrar system will have business logic for these exceptions augmenting the complexity, therefore implementing the standard TTL at the registry level could provide separation of duties for enforcing the standard TTL. The risk of the Registrants contacting the Registry by unsetting the authorization information could be mitigated by explaining in the “Notification of TAC Provision” that a standard 14-day TTL is enforced by the system.
If your response requires an edit or deletion of Preliminary Recommendation 15, please indicate the revised wording and rationale here.
ICANN org would like the WG to consider if completely removing the admin contact may have a significant impact on reseller’s operation. While Org acknowledges that even though Admin and Tech contacts are no longer required to be collected, some registrars may continue to process the admin contact. Though it will not impact most retail registrars, it is uncertain how large of an impact completely removing the admin contact would have on those wholesale registrars, or registries who heavily rely on resellers who assist their customers by managing their domains and listing themselves as the Admin or Tech contact.
If your response requires an edit or deletion of Preliminary Recommendation 16, please indicate the revised wording and rationale here.
ICANN org suggests the WG to review the means through which these mandatory restrictions must be implemented, preferably using the standard EPP status codes. EPP status codes, in addition to restricting transform-commands (e.g., clientTransferProhibited restricts transfer requests), are also a signaling mechanism that is shown in RDDS. The EPP status codes site at ICANN (https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) explains the EPP status codes, and the RDDS output provides a link to this site. Therefore, the WG may want to consider an alternative method to write this recommendation such as: “The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 days of the initial registration date by setting the appropriate EPP status(es) in the Registry system”.
If your response requires an edit or deletion of Preliminary Recommendation 17, please indicate the revised wording and rationale here.
ICANN org suggests the WG to review the means through which these mandatory restrictions must be implemented, preferably using the standard EPP status codes. EPP status codes, in addition to restricting transform-commands (e.g., clientTransferProhibited restricts transfer requests), are also a signaling mechanism that is shown in RDDS. The EPP status codes site at ICANN (https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) explains the EPP status codes, and the RDDS output provides a link to this site. Therefore, ICANN org proposes the WG consider an alternative method to write this recommendation such as: “The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 days of the completion of an inter-Registrar transfer by setting the appropriate EPP status(es) in the Registry system”.
Regarding the Working Group's Response to Charter Question a8 on page 20 of the Initial Report
The WG may want to further discuss properly documenting, retaining notifications of transfers sent so to the RNH, so that provisions of such records can be sent to ICANN Compliance when investigating a complaint as needed.
With the potential elimination of the Gaining Registrar Form of Authorization, the AuthInfo code becomes even more important for the transaction and for any compliance investigation related to it. Most registrars provide the AuthInfo code through the control panel. For some, it can be requested through the control panel and an email is sent to the RNH’s email address that contains the AuthInfo code. Many others, however, make the Authinfo code available within the control panel (i.e., it can be seen by logging in). A compliance investigation into an unauthorized transfer complaint will require evidence related to when and by whom the control panel was accessed, allowing access to the AuthInfo code (e.g., time-stamped system logs). These types of records are not specifically contemplated by the current agreement/policy (see below).
Section 3.4 of the RAA requires registrars to maintain and provide to ICANN:
126.96.36.199 In electronic form, the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry Operator(s);
188.8.131.52 In electronic, paper, or microfilm form, all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with Registered Name Holders, including registration contracts;
184.108.40.206 In electronic form, records of the accounts of all Registered Name Holders with Registrar.
The above does not cover, for example, system logs related to the retrieval of an AuthInfo code which is visible upon logging in a panel (it is not data submitted by the registrar to the registry, not a written communication, not records of the accounts themselves). It also will likely not cover the “other means of more modern communication” referenced in the recommendation.
Further, while the Transfer Policy does require both registrars to “provide evidence relied on for the transfer during and after the applicable inter-registrar domain transaction(s)”. The evidence a registrar “may rely on” when processing a transfer request may not suffice for an investigation into ICANN Compliance challenging such a transaction. For example, in the past ICANN Compliance has received responses from registrars along the following lines: the evidence cited by the registrar that the individual utilizing the AuthInfo code was authorized by the RNH was simply that the individual knew the AuthInfo code. The complainants (former RNHs), however, denied having requested the transfer (or authorized anyone to request it on their behalf) and additional information suggested that the resellers had access to the control panel. The registrars denied having specific evidence related to the AuthInfo code retrieval. As explained above, this evidence is not contemplated by 3.4 of the RAA and was not part of the evidence the registrar “relied on” for the transactions either. When conducting an investigation, ICANN Compliance should not make assumptions and needs to collect all the information and evidence needed to reasonably recreate the steps that occurred before/during/after the transaction and assess whether each obligation attached to each step was complied with. This includes confirming that the data and evidence indicate that the TAC was made available to the RNH (and not someone else). An investigation may be hindered when this evidence is not collected by the registrar and provided to ICANN upon reasonable notice. Note that a compliance investigation may often lead to the detection of deficiencies in processes or systems that are, as a result of the investigation, remediated by the registrar to prevent them from reoccurring and impacting additional domain names/registrants.
ICANN Compliance needs records pertaining to transfer transactions (mandatory notifications and the provision of TAC) to carry out thorough investigations following the receipt of transfer complaints. If the policy does not require registrars to retain such records to provide to ICANN Compliance upon request, it is unlikely that ICANN org will be able to thoroughly conduct compliance investigations following a transfer complaint.
For the avoidance of doubt, org is not requesting the addition of system logs to retention obligations. Rather, ICANN org suggest that the policy recommendation include requirements related to the maintenance and provision to ICANN (upon reasonable notice) of records related to when/how/to whom the TAC was provided, regardless of the means the registrar chooses to use to provide the TAC.
ICANN org would like to thank the Transfer PDP team for its thoughtful and dedicated work in producing this report. ICANN org hopes that its review of the initial report and input provided in this form will support the Transfer PDP Working Group as it discusses community input, and establishes its final recommendations for a successful and efficient Consensus Policy implementation.