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.
Контент доступен только на следующих языках
2. If your response requires an edit or deletion of Recommendation #5, please indicate the revised wording and rationale here.
The definition of the TAC implies that a TAC will be able to authorize a transfer at any time, but there are some times when the domain cannot be transferred and the TAC would not authorize the transfer in those circumstances. The RrSG provides two options for revision, for the Working Group’s consideration: Option 1 - unless ineligible: “...The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer unless the transfer request has been determined ineligible by the registrar of record, due to reasons identified in the Transfer Policy” Option 2 - for eligible domain The TAC is required for a domain name to be transferred from one Registrar to another Registrar and, when presented for an eligible domain, authorizes the transfer.
2. If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording and rationale here.
SLA is not the right term, let's call it "Required Timing for TAC Provision"
2. If your response requires an edit or deletion of Recommendation #7, please indicate the revised wording and rationale here.
We note a grammatical error - missing a comma after “modifications”. Should say “including all successor standards, modifications, or additions”
2. If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording and rationale here.
There may be cases where the Rr needs to NULL the TAC immediately and cannot wait for RNH approval in order to protect the security of the domain and prevent invalid transfer. Propose adding this text: “Rr may reset TAC to NULL without RNH agreement when in the best interests of the RNH.”
2. If your response requires an edit or deletion of Recommendation #13, please indicate the revised wording and rationale here.
Some Registrars are currently using the "info" EPP command to confirm a TAC is valid before initiating the transfer with the registry; their business operations will be disrupted if this can no longer be done. We suggest preservation of the read-only use of the code as the status quo; using the info command to verify is not the same as actually using a TAC to initiate a transfer and so it should continue to be available even with this Recommendation being in place.
2. If your response requires an edit or deletion of Recommendation #22, please indicate the revised wording and rationale here.
The RrSG supports the intent of I.A.3.7.4 but suggests that further revisions should be made for clarity. The final sentence, directing the Registrar to remove the lock, is unclear because the lock has not previously been mentioned. We propose the following revised new text: In all cases, the objection must be provided by the Registered Name Holder on an opt-in basis. If the RNH removes this objection, then the transfer must be permitted within the standard timeframe.
2. If your response requires an edit or deletion of Recommendation #24, please indicate the revised wording and rationale here.
The RrSG proposes additional Implementation Guidance for I.A.3.9.3 to make clear that a Registrar-applied inter-Registrar transfer lock is likely the ClientTransferProhibited EPP Status but a Registrar may instead prevent an inter-registrar transfer via some other method.
2. If your response requires an edit or deletion of Recommendation #26, please indicate the revised wording and rationale here.
Regarding 26.2 “The working group recommends eliminating Section II.B “Availability of Change of Registrant” from the future standalone Change of Registrant Data Policy.” The RrSG supports this recommendation as written but would ask the Working Group to confirm the intent of removing restrictions to the Change of Registrant Data availability while a dispute is in progress. With the removal of the Section II.B, a domain currently in the middle of a dispute (e.g. ownership concerns or UDRP) could still be updated to show new Registrant Data. Was this the desire of the Working Group?
2. If your response requires an edit or deletion of Recommendation #33, please indicate the revised wording and rationale here.
The RrSG strongly supports research into and consideration of either expanding the Transfer Dispute Resolution Policy or creating a new dispute resolution method that would be available to registrants who wish to challenge a transfer which, despite following the Policy, is still improper, such as in cases of stolen domain names.
2. If your response requires an edit or deletion of Recommendation #34, please indicate the revised wording and rationale here.
The RrSG proposes that the Recommendation title should not include the word “Voluntary” as this Recommendation speaks to both voluntary and involuntary full portfolio transfers.
2. If your response requires an edit or deletion of Recommendation #46, please indicate the revised wording and rationale here.
Some concerns exist regarding the potential costs associated with this expansion. If registries can set high prices for the BTAPPA, such as $50,000 (Full Portfolio Transfer Fee Ceiling), this could undermine the recommendation's effectiveness and intended benefits. While the ICANN bylaws foster competition, it is crucial to ensure the costs associated with BTAPPA do not preclude a healthy and competitive market.
Yes, the RrSG appreciates the updated format in this Report and finds it helpful to our review. The new format makes it easy to find the Recommendation and outcomes of the WG’s deliberations while ensuring that further context and info is available if needed but does not get in the way of the crucial information.
The RrSG appreciates the opportunity to comment on this Initial Report, and thanks the Working Group members and ICANN Staff for their many hours of dedicated work on this project.
Domain transfers, both inter-registrar and inter-registrant, are a fundamental aspect of the Domain Name System. Ensuring that the transfer process is secure and appropriately balances maintaining security and appropriate authorization for transfers with ensuring availability to transfer when desired is a very important undertaking.
This Working Group has achieved that balance admirably and consequently has issued a very good Initial Report, with no major significant issues, due to the time and resources put in by the Community and ICANN Staff, as well as an excellent WG leadership team.
Implementation of these Recommendations will represent technical & operational changes for Registrars and Registries, as well as modified user experiences for Registrants which must be communicated to them in a timely manner. The IRT’s work will be extensive, but we expect that to be smooth as the Recommendations are clear and not highly controversial, and Implementation Guidance is provided where appropriate.
Following the conclusion of the IRT’s work, the RrSG proposes a minimum of 12 months implementation buffer window and ideally 18 months; 6 months would certainly not be enough time. This is due to the extent of the changes that will be required, including coordination between Registrars and Registries (possibly even more than with the Registration Data Policy).
As such, the Transfer PDP implementation period must not begin before the Registration Data Policy implementation window is complete (August 2025).
We further note that portions of this Policy may be affected by obligations coming out of the PPSAI IRT work and so those interactions must be carefully considered.
The RrSG will take this opportunity to focus on three high-priority concerns:
1) Some Registrars use the "info" EPP command to confirm the validity of a TAC before initiating the transfer; removing this functionality would interrupt business operations in an unfortunate manner. Instead, we consider that using this “info” command is not the same as actually using a TAC to verify a transfer, so the functionality should remain available.
2) Although the Working Group did not reach agreement to eliminate or substantially change obligations relating to the Losing FOA some Registrars still strongly believe that doing so would benefit domain registrants by speeding up the transfer process while accompanying that change with a lightweight dispute resolution method available to the registrant.
3) The RrSG looks forward to participating in work to provide dispute mechanisms to registrants for cases where a transfer was conducted in accordance with the Policy but is still improper (e.g. due to someone accessing a compromised account)