Public Comment

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.

Contenido disponible solo en los siguientes idiomas

  • English

Name: Registries Stakeholder Group (RySG)
Date:29 Jul 2022
Are you providing input on behalf of another group (e.g., organization, company, government)?
No
Please choose your level of support for Preliminary Recommendation 1.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 2.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 3.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 4.
Support Recommendation as written
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 in the Notification of Transfer Completion sent by the Losing Registrar to the Registered Name Holder? Why or why not? Please explain.

Registry Operators acknowledge the security benefit of notifying a RNH both of a completed transfer and of the identity of the Gaining Registrar. This notification provides a confirmation to the RNH that the desired action was completed as requested. Further, Registry Operators understand that in order to achieve this it will be incumbent of Registry Operators to provide this information to the Losing Registrar via EPP upon completion of the transfer as the Losing Registrar would not otherwise have access to this information.

Please choose your level of support for Preliminary Recommendation 5.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 6.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 7.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 8.
Support Recommendation intent with wording change

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

Proposed revised wording: The working group recommends that the Registry verifies at the time that the TAC is stored in the Registry system that the TAC meets the syntax requirements specified in Preliminary Recommendation 7. Rationale: The proposed change is to add the word “syntax” to be prescriptive about the requirements the Registry is to verify. This is necessary because many of the requirements in Recommendation 7 are operational requirements for Registrars and the TAC value itself does not provide any indication of whether or not these requirements were properly executed. Given a TAC value the only verifications a Registry can perform is to check that the TAC consists only of allowed characters and is of the minimum length required, i.e., verification of the syntax of the TAC.

Please choose your level of support for Preliminary Recommendation 9.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 10.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 11.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 12.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 13.
Significant change required: changing intent and wording

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

Proposed wording change: 13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry. Rationale: The suggested wording change is to drop the phrase “enforced by the Registries”, because Registries do not support this element of the recommendation. Registries acknowledge that having a time-to-live for the TAC is a good security practice, however we do not believe we are the best choice for enforcing this practice. The enforcement MUST remain with the Losing Registrar. Transferring a domain name is an activity very much engaged with a RNH. Registries currently serve only in the role of facilitator of transfers, in part because we have no direct relationship with a RNH. Preemptively invalidating a TAC is an expansion of the role of a facilitator. In such a scenario, the Registry would be directly impacting a RNH with no way to communicate that action, control the message to the registrant, or address complaints or appeals of the registrant. In order for Registries to consider supporting this Recommendation as proposed, these issues would need to be addressed, including appropriate recommendations specifying the change in role and the requirements of the new role. Further, Recommendation 13.2 allows for a shorter TAC if mutually agreed by the Registrar of Record and the RNH, presumably for operational reasons. Therefore it also seems reasonable that a RNH and Registrar of Record might agree to a short extension of the TAC lifetime for operational reasons. Enforcement of the 14-day deadline by the Registry eliminates this option and introduces further friction into the transfer process. An additional concern in such a scenario is that the Registry role is being expanded from being a facilitator to include a compliance responsibility over a Registrar. In any challenge or appeal related to the efficacy of a TAC, the registry will now be required to be responsive to RNH’s as well as any other authority that may be investigating a concern. As a facilitator, a Registry’s role in a transfer is strictly reactive to external triggers, e.g., responding to a transfer request from a Gaining Registrar. Enforcing a TTL would create the need for an internal trigger at the Registry, which imposes a new responsibility for which the requirements are not specified. Finally, splitting the management role of the TAC requires additional investigation of issues related to the use of “locks”. While it is understood – but worth noting it is not explicitly stated so it is a potential point of ambiguity – that a Registrar MUST remove all Registrar “locks” upon request of a TAC, Registry “locks” remain and appear to be considered out-of-scope for this group. The presumed interpretation of this is that it is Registry Policy for how its Registry Lock Service interacts with a transfer. The presumption is that when a transfer request is received and validated, a Registry would then invoke its “disable Registry Lock Service protocol”, which likely includes contacting the Losing Registrar to contact the Registrant to perform the necessary validation for the request. Suppose the timing of this is such that the TTL expires while this is in progress. If the Registrar is wholly responsible for the TAC then it seems reasonable for the Registrar to decide if the transfer should be rejected and required to restart. On the other hand, if the Registry is responsible for the TTL enforcement then it seems reasonable for the Registry to decide if the transfer should be rejected and required to restart. Other options are possible and should be considered; the options described here are not prescriptive of a preferred solution.

Question to the community: Who is best positioned to manage the standard 14-day TTL – the Registry or the Registrar, and why? Are there specific implications if the TTL is managed by the Losing Registrar?

The Registrar is the first, best choice for enforcing a TTL on a TAC.


There are several reasons for this, listed here in no particular order:

1) The Registrar has all other responsibilities associated with a TAC. If enforcement of the TTL is to be put on any other entity, e.g., the registry, the benefit(s) of this move should be clearly articulated and supported in such a way as to make the move self-evident.


2) The Registry has no defined, scalable way of notifying the Registrar of Record that it has expired a TAC, which should require a further notification to be passed to the RNH. This mechanism would need to be designed, standardized, and implemented, the correct implementation of which would become its own compliance obligation for both Registries and Registrars. Further, this notification would change the relationship between Registries and RNHs, presumably with the registrar acting as a proxy. We believe this issue needs further investigation.


3) Recommendation 13.2 allows for the Registrar to set a TAC to null at any time before the TTL expires as mutually agreed by the Registrar and the RNH. However, there is no discussion of how this action is expected to interact with the Registry TTL enforcement. Presumably a Registry would stop its TTL countdown, but if the Registry does not take this action what action should it take if it discovers there is no TAC to expire? This issue needs further investigation.


4) An interpretation of Recommendation 13.2 is that a Registrar has the authority, upon agreement with the RNH, to set a shorter TTL for the TAC. Thus, a Registry is required to enforce a maximum TTL and the Registrar is enforcing a minimum TTL. There is no support or motivation of the benefit of this split in enforcement responsibility.


5) Currently, there is no guidance regarding changes to a TAC’s TTL. Although a TAC is required to be single use, can the same TAC be stored with a different TTL, while the TAC is still active? Should this restart the Registry enforcement of the maximum TTL? If not, what is the desired behavior the new TTL value would result in the TAC expiring before the value is reached?


Please choose your level of support for Preliminary Recommendation 14.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 15.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 16.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 17.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 18.
Support Recommendation intent with wording change

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

Proposed wording change: Preliminary Recommendation 18: I.A.3.7 of the Transfer Policy currently reads, “Upon denying 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 of this provision as two distinct provisions of the policy. In addition, the I.A.3.7 policy should be updated to clarify that the Registrar does not provide thereason for the denial to the potential Gaining Registrar as follows: replace the phrase “the Registered Name Holder and the potential Gaining Registrar with the reason for denial” with “the reason for the denial to the Registered Name Holder and the Registry, and the Registry will pass the reason for the denial to the potential Gaining Registrar”. Rationale for wording change: The proposed change is to add a sentence that recommends updating the policy to make it clear that Registrars can not directly provide the reason for the denial to the potential Gaining Registrar. Recommendation 18 overlooks the fact noted in Sub-Recommendation 4.3 that the Losing Registrar does not know the identity of the Gaining Registrar, which suggests it is not possible for the Losing Registrar to provide any reason for the denial to the Gaining Registrar. Registries do understand that the reason for the denial, as an ordinary part of executing the transfer process, is actually passed to the Registry from the Losing Registrar, who then passes it to the Gaining Registrar. We believe this should be clarified in the Recommendation.

Please choose your level of support for Preliminary Recommendation 19.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 20.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 21.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 22.
Support Recommendation as written
Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer.

The Registries note an ambiguity between Recommendations 3 and 12 that we believe should be clarified. Recommendation 3 states that the Registrar of Record is required to notify an RNH of the provision of a TAC within 10 minutes of its request. However, Recommendation 12 states that the TAC itself must be provided within at most 5 days. The use of “provision” and “provide” are ambiguous. Perhaps Recommendation 3 is intended to notify an RNH of the “request” for a TAC as opposed to its provision? Other resolutions are possible and our suggestion does not indicate a preferred choice.

Summary of Submission

The RySG welcomes the opportunity to provide feedback on the Initial Report on the Transfer Policy Review - Phase 1(a) and provides comments and alternative language for recommendation 8, 13 and 18.