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 your response requires an edit or deletion of Preliminary Recommendation 3, please indicate the revised wording and rationale here.
The term “RNH, as listed in the Registration Data at the time of the TAC request” may be incomplete with regards to domain name registrations that utilise Privacy/Proxy services. This should be clarified to ensure that underlying P/P service customers can access the TAC, to align with the RrSG feedback to Recommendation 14.
If your response requires an edit or deletion of Preliminary Recommendation 4, please indicate the revised wording and rationale here.
The RrSG suggests that the IANA ID of the Gaining Registrar be added to the notification required in 4.3 and, optionally, the name of the Gaining Registrar.
Yes, the registry operator should provide the IANA ID of the Gaining Registrar to the Losing Registrar, so it can be included in the Notification of Transfer Completion. This would provide a better and more informed experience for registrants regarding their domain name transfer. Registries could map their internal ID to an IANA ID. While this is a desirable outcome, the RrSG does not consider this as a must-have outcome for these recommendations (as this has not been a requirement for almost two decades).
If your response requires an edit or deletion of Preliminary Recommendation 7, please indicate the revised wording and rationale here.
The RrSG proposes a minor wording change for clarity. The text “(and its update and replacement RFCs)” could instead say “and its successors”; this may be more clear and readable. Further, the RrSG would like the Working Group to explore or request another appropriate group to explore improving TAC security by embedding information into the TAC at the time of creation. This could include the TAC creation date (improving awareness of TAC TTL and ability to verify TAC duration/validity), or could include the gaining registrar’s IANA ID (to ensure the domain can only be transferred to the specified registrar), depending on feasibility. The RrSG also suggests that TAC TTL information should be included in the “EPP Info” response from the Registry, allowing a registrar to verify the validity of the TAC in a standardized manner. The RrSG is raising these as suggestions for consideration by the working group, but not as items that the RrSG believes should be required in any final recommendations.
If your response requires an edit or deletion of Preliminary Recommendation 9, please indicate the revised wording and rationale here.
Recommendation 9.2 only makes a reference to the current RFC; it should include any subsequent updates to that RFC in order to capture future requirements. After “at least according to the minimum standard set forth in RFC 9154.” we should add “(or its successors)”.
If your response requires an edit or deletion of Preliminary Recommendation 10, please indicate the revised wording and rationale here.
The RrSG suggests that the Recommendation reference the Transfer Policy and not the Temporary Specification (which will, at some point, be superseded by this Policy): “The Working Group Recommends that the Transfer Policy include the following requirement: ‘Registry Operator MUST verify that the “Transfer Authorization Code (TAC)” provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request.’ with other terminology updates in accordance with other relevant recommendations.” This is because the Temporary Specification is intended to be temporary and the updates to the Transfer Policy should live in a permanent update.
If your response requires an edit or deletion of Preliminary Recommendation 13, please indicate the revised wording and rationale here.
The RrSG notes that the word “standard” implies that this is the required length of time for TTL, however “maximum” may be a better term as the TTL period will be not more than 14 calendar days.
As the registry is the central authority for registrations, they are the only place to enforce a standardized and consistent TAC TTL. The registry checks the TAC the moment it is used and can invalidate the TAC immediately when the TTL expires. The automatic nullifying of the TAC does not change that authority, nor does it alter the registry’s relationship with the registrant. The RrSG additionally supports that no RSEP be required for any registry to implement TAC TTL as it would be an obligation of the contract that the registry must perform and not a service it is choosing to perform.
If your response requires an edit or deletion of Preliminary Recommendation 14, please indicate the revised wording and rationale here.
The RrSG notes that “Registration Data” could suggest that this includes Privacy/Proxy service data. We suggest including an Implementation Note clarifying that “‘Registration Data’ in case of a domain with an active P/P service means the underlying customer, not the publicly-displayed P/P data.”
If your response requires an edit or deletion of Preliminary Recommendation 16, please indicate the revised wording and rationale here.
The RrSG conducted an internal poll on the topic of transfer lock periods both after initial registration and after inter-registrar transfer. The results were split and the RrSG did not come to consensus on what would be the appropriate time frame, although the most popular options were 30 and 60 days and the RrSG participants on the Working Group agreed to support the Working Group’s recommendation. It is important that sufficient time be provided for the registrar to address issues of fraud or abuse but also that domain owners are able to choose their registration provider and move between providers at their own discretion. The RrSG proposes that registrars should be able to override a transfer lock period, as part of the “fast undo” transfer-reversal process (which will be discussed in a later phase of this PDP WG) or in the event that the registration violates the registrar’s Terms of Service, Acceptable Use Policy, etc. For both Recommendations 16 and 17, the RrSG strongly suggests that the two lock periods should be the same duration, and the “fast undo” transfer reversal period should be the same duration as well. The RrSG internal poll results are in the attachment to this comment.
If your response requires an edit or deletion of Preliminary Recommendation 17, please indicate the revised wording and rationale here.
Same comment as Recommendation #16
If your response requires an edit or deletion of Preliminary Recommendation 21, please indicate the revised wording and rationale here.
Support Recommendation as written, except for the reasons in Reference I.A.3.8.5, which as stated above for Recommendations 16 and 17, the RrSG has no opinion.
If your response requires an edit or deletion of Preliminary Recommendation 22, please indicate the revised wording and rationale here.
Current Guidance implies that these reasons only apply during the Auto-Renew Grace Period but they are intended to always apply. Recommend removal of “during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period” so that the Guidance says: “Implementation Guidance: Registrars are prohibited from denying domain name transfer requests based on non-payment of fees for pending or future registration periods.”
n/a
The RrSG notes the significant benefit of the work of the TPR WG in normalising and streamlining terminology, terms, and references used across numerous policy areas that touch domain transfer policy. This standardization will provide clarity and consistency while reducing subjectivity of interpretation or implementation, to the benefit of all involved.
The RrSG has further comments on some of the Recommendations which we do support as written.
Preliminary Recommendation 2 - Losing FOA:
The RrSG notes that the ability to decline a transfer (NACK) within 5 days from the notice is currently standard practice and it may be a surprise to some when that period no longer exists. As such, when the TPR WG reviews the “fast undo” transfer dispute process in a later phase, this change should be further considered.
Preliminary Recommendation 3 - Notification of TAC Provision
The RrSG notes that use of the term “Registration Data” (“as listed in the Registration Data at the time of the TAC request”) could suggest that this applies to Privacy/Proxy service data. We suggest including an Implementation Note clarifying that “Registration Data” in case of a domain with an active P/P service means the underlying customer data, not the publicly-displayed P/P data. This ties to Recommendation 14 (terminology updates) where we suggest including clarifying language on this point within the Recommendation itself.
Preliminary Recommendation 7 - TAC Composition
The RrSG offers the following suggestion for how registries could add the date to the hash so it becomes easier for registries and registrars to know if a TAC has expired or not.
Technical implementation would be as follows;
Validity date as part of the auth code, e.g.: <random code>@<date> / sdkflsjdflkjslfd@2022-06-01
Hash auth full auth code (including the date) with a salt e.g.: c0ca869697c411566cd6475dcbbe1892860094ca
Set hashed auth code at registry: <algowithm>|<salt>|<auth code>|<date> / sha1|fsshfjkl|c0ca869697c411566cd6475dcbbe1892860094ca|2022-06-01
the registry can communicate the validity date based on this format but also needs to validate the date included in the hashed password to make sure both match when validating the auth code
By including the date in the authcode, anyone can see the validity date.
Preliminary Recommendation 21 - Revised Reasons that a Registrar of Record MUST Deny a Transfer
The RrSG notes that the notification of UDRP or URS procedure must come from the Provider and as such there may in some cases be a delay between the time of registration and the time of notification of the dispute. It is important that the timing of transfer denials be carefully considered to ensure that a registrant does not move between registrars in order to avoid the UDRP or URS and, should that occur, rollback of the transfer in these scenarios should be considered in the appropriate phase of this TPR WG.
RrSG internal poll results on the topic of transfer lock periods both after initial registration and after inter-registrar transfer
The Registrar Stakeholder Group (RrSG) is pleased to comment on the Initial Report on the Transfer Policy Review Policy Development Process - Phase 1(a). We appreciate the hard work of the group members and leadership team, and overall support the efforts of the working group.
It is important to ensure that domain owners maintain the ability to choose their provider, which includes the ability to transfer the domain when they want to do so, while also not being at risk of domain theft (and especially not at increased risk due to the changes outlined here). The RrSG believes that the updated Transfer Policy will appropriately balance these needs.
In general, the RrSG supports most recommendations. The RrSG has some suggestions to improve some recommendations, and for the reasons detailed in our comments, does not have an opinion on some recommendations.