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 #3, please indicate the revised wording and rationale here.
Tucows supports the intent of changing the current 60-day lock to 30 days but recommends making it clear by incorporating the following changes: “within” should be replaced by “for” and “of” by “from” so that the first sentence reads: The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar for 30 calendar days / 720 hours from the initial registration date. We further recommend that the second part of Recommendation #3 be moved to implementation guidance.
2. If your response requires an edit or deletion of Recommendation #5, please indicate the revised wording and rationale here.
The TAC may be issued when a domain is otherwise not eligible for transfer (e.g. locked due to UDRP process), in which case the TAC should not authorize the transfer. This definition should be updated to accommodate that possibility.
2. If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording and rationale here.
This is not properly an SLA and should instead be titled “Required Timing for TAC Provision”.
2. If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording and rationale here.
Sometimes the Registrar may need to NULL a TAC without the agreement of the RNH. This should be an exception rather than the norm, and should be available as such. We support the RrSG’s proposed revised language.
2. If your response requires an edit or deletion of Recommendation #11, please indicate the revised wording and rationale here.
The language of the registration agreement may be English. Propose small wording addition (add "if different"): 11.1: This notification MUST be provided in English and in the language of the registration agreement (if different) and MAY also be provided in other languages.
2. If your response requires an edit or deletion of Recommendation #14, please indicate the revised wording and rationale here.
Tucows supports the maintenance of records for ICANN Compliance and internal usage. However, the Recommendation should be clarified because ICANN cannot contract out of compliance with local laws. We recommend that the final sentence be changed to clarify that ICANN records keeping policies apply to these records; we recommend that the last sentence of the Recommendation be replaced in its entirety with: These records fall under the ICANN Data Retention Specification; the Registrar MUST provide such records to ICANN upon reasonable notice.
2. If your response requires an edit or deletion of Recommendation #17, please indicate the revised wording and rationale here.
Proposed minor wording change to accommodate that many registration agreements are in English (add "if different"): 17.3: The Transfer Confirmation MUST be provided in English and the language of the registration agreement (if different) and MAY also be provided in other languages. Tucows also suggests that the Transfer Confirmation email should include only a way to cancel the transfer and should not provide a way to approve the transfer. The transfer will automatically complete after the 5 day pending period and, should a registrant need to speed up this process, they can contact their registrar to immediately approve the transfer. Most unauthorized transfers are due to a compromise of the Registrants’ data or account. If the Transfer Confirmation email includes a way to immediately approve and complete the transfer, the bad actor would be able to use that Transfer Confirmation to complete the hijack of the domain. As such, not providing this option to the email recipient is an important security measure.
2. If your response requires an edit or deletion of Recommendation #18, please indicate the revised wording and rationale here.
The wording of Recommendation #3 and Recommendation #18 should mirror each other and Tucows supports the intent of changing the current 60-day lock to 30 days and making this clear by incorporating the following changes: “within” should be replaced by “for” and “of” by “from” so that the first sentence reads: The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar for 30 calendar days / 720 hours from the completion of an inter-Registrar transfer. We further recommend that the second sentence of Recommendation #18 be moved to implementation guidance. Finally, we strongly disagree that this transfer lock may be in any way made optional. “Double-hop hijacks” are on the rise for precisely the reason that transfer locks are “optional”. To provide any safety at all, this lock MUST be mandatory and have no exceptions related to a request by the RNH. The lock may potentially be removed because of other ICANN Policy (such as UDRP) and this Policy is in no way intended to modify any other Policy (see Recommendation #23); similarly, the lock MUST be removed to return the domain to the losing registrar in the event of a hijack. “Asking nicely” should not be a reason to invalidate the intent of the Policy.
2. If your response requires an edit or deletion of Recommendation #19, please indicate the revised wording and rationale here.
Proposed minor wording change to accommodate that many registration agreements are in English: 19.1: This notification MUST be provided in English and in the language of the registration agreement (if different) and MAY also be provided in other languages
2. If your response requires an edit or deletion of Recommendation #29, please indicate the revised wording and rationale here.
Without a revised formal transfer dispute resolution policy, having a TEAC is a gesture with very little effect. The change from 4 to 24 hours may be beneficial or may cause further difficulties with delayed responses; either way, there should be work done towards creating a fulsome transfer dispute resolution policy which will protect both registrars and registrants.
2. If your response requires an edit or deletion of Recommendation #33, please indicate the revised wording and rationale here.
Tucows strongly supports expansion of the Transfer Dispute Resolution Policy and/or creation of a new dispute mechanism to include registrant filers and to create a low-cost dispute resolution process which addresses improper transfers such as in cases of compromised or stolen domains. At this time, the only available dispute policy for transfers is a costly process which renders it inaccessible to many. Further, the process is not available to registrants (it can only be initiated by registrars) and most importantly does not address situations where the Transfer Policy is followed but the transfer is still invalid, e.g. an account was compromised. The updated TDRP should have a low price tag, allow Registrants to file, and promote the expansion of criteria to cover invalid transfer due to compromised RNH data. This will still present time and financial costs to registrants and registrars but will overall enhance the security, stability, and resilience of the DNS.
2. If your response requires an edit or deletion of Recommendation #41, please indicate the revised wording and rationale here.
While Tucows supports the intent of the recommendation to expand the BTAPPA process to include registrar agents, we recommend that the Working Group make clear that the qualifying circumstances currently required for BTAPPA should remain required under the new ICANN BTAPPA process. The WG should further consider adding the option for the current (losing) registrar to consent to the BTAPPA in cases where the qualifying circumstances are not met.
Yes, the new format made the report easy to follow and made our review process smooth and successful. Thank you!
Tucows is pleased to comment on the Transfer Policy Working Group’s Initial Report, and thanks the Working Group members, leadership team, and ICANN Staff for all their hard work and dedication over the past few years.
The Transfer Policy is of critical importance to Registrars as it has a direct and significant effect on the security of the domain name system as well as on our registrant customers’ experiences. Tucows participated in this Working Group in order to advocate for a streamlined and secure transfer process which readily allows registrants their choice of registrar while ensuring that illicit domain name transfers (“hijacks”) are guarded against and easily undone. The outcomes in the Working Group’s Recommendations generally meet this goal, although we would have been pleased to see further changes such as full removal of the Losing FOA and a robust transfer reversal process including a low-cost dispute process available directly to registrants. That said, we support the Recommended updates to the Transfer Policy as they will overall improve the process and user experience.
We offer the following final comments:
Regarding Recommendation #17: Losing Form of Authorization (FOA)
The purpose of this Transfer Confirmation step is to ensure that the registrant is aware of the transfer and to allow the registrant to stop a transfer after it has been initiated. This is an important security measure.
Notifications are sent to the registrant when the TAC is issued and when the registrant data is changed (unless they opted out). This should alleviate the concern of a registrant being unaware of the transfer, even without a Transfer Confirmation email.
Most unauthorized transfers are due to a compromise of the Registrants’ data or account. If the Transfer Confirmation email includes a way to immediately approve and complete the transfer, the bad actor would be able to use that Transfer Confirmation to complete the hijack of the domain.
As such, the Transfer Confirmation email should include only a way to cancel the transfer and should not provide a way to approve the transfer. The transfer will automatically complete after the 5 day pending period and, should a registrant need to speed up this process, they can contact their registrar to immediately approve the transfer.
Regarding Recommendation #18: Transfer Restriction After Inter-Registrar Transfer
We strongly believe that the removal of this post-transfer lock should NOT be optional, as this has already been used for “double-hop hijacks”. Rather, this lock MUST be mandatory and have no exceptions related to an RNH’s request. Perhaps the lock could be removed in relation to compliance with other ICANN Policies or to return the domain to the losing registrar in the event of a hijack, but in no event upon request by the RNH.
Regarding the "Introduction to Group 2 Recommendations"
We still believe that there needs to be a formal policy, process, and guidelines for resolving transfer disputes which is (a) available to registrants to initiate at a reasonable, non-prohibitive cost; (b) requires registrar participation; and (c) is available for cases where the Transfer Policy was followed but the transfer is still unauthorized (e.g. hijacked domains). Escalating a transfer dispute to a third-party resolution body as currently under the TDRP should be only a last resort for when a dispute cannot be otherwise resolved.
In the current status quo, registrars are expected to first attempt to resolve the dispute informally; this makes it very challenging for a losing registrar to get a domain back, as the process relies on the gaining registrar deciding to return the domain. With no policy requirements or guidelines provided, the gaining registrar is unlikely to agree to do so.
Registrars that are willing to engage in this informal dispute process have each designed their own criteria for the return of the domain. Some refer to having the registrant sign a Transfer Undo Return Form (“TURF”) while others require Indemnification Agreements from both the losing registrar and the registrant. As these processes are unique to each registrar, many registrars are not able to accept these terms for reasons outside the dispute.
A further concern is that the Transfer Emergency Action Contact (“TEAC”) is only used to facilitate the”'informal process” and is only available as a means of regaining a domain if the gaining registrar does not respond to the emergency request. Expanding the TEAC response requirements does not solve the issue as it merely expands the policy to support a process that doesn't exist.
Work undertaking to implement Recommendation #33 may address some of these concerns, and we will support that process.
Tucows looks forward to continuing to support the work of this Working Group and future Implementation Review Team, and again thanks the Working Group members, leadership team, and ICANN Staff.