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

As stated on page 4, “only the policy recommendation text itself is meant to be considered authoritative.” Therefore, it is critical to note that the two footnotes are not actually incorporated into the recommendation text. To avoid any confusion, this recommendation should be rewritten as follows: (a) Replace the term “initial registration date” with “creation date”, and (b) Fully incorporate the content of footnote 2 into the main body of the recommendation itself. Without these changes, the recommendation fails to fully address the concern and does not effectively avoid doubt. Additionally, the use of “30 calendar days / 720 hours” creates unnecessary ambiguity. One registry or registrar might interpret “30 calendar days,” while another could use “720 hours,” and these are not always equivalent (due to differences in time, such as rounding, where 1:00 a.m. to 11:00 p.m. on the next day could be considered one calendar day but amounts to 46 hours). To avoid such inconsistencies, it is essential that the policy text specify 720 hours as the authoritative duration. The reference to “30 days” should only appear in the explanatory text, which is not authoritative. This approach should be applied consistently throughout the document to ensure clarity and uniform application. Please apply this logic universally, as I prefer not to repeat this comment for each instance where ambiguity arises.

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

I generally support the intent behind Recommendation #17, but I would like to raise a few important points regarding the language and placement of certain sections within the recommendation itself. First, the first two sentences of the text, namely —"The working group did not reach agreement to eliminate or substantially change the Obligations of the Registrar of Record described in Section I.A.3.1 - I.A.3.6 of the Transfer Policy. Therefore, the working group recommends that these requirements will largely remain in place."—should be moved to the Rationale section, as it is purely commentary and does not belong in the authoritative policy recommendation. This statement provides background information on the working group’s deliberations, but it is not a necessary part of the final recommendation text and could cause confusion if left there. The recommendation section should focus solely on the requirements being put in place, leaving the reasoning behind them for the Rationale. Second, as previously discussed in our earlier comments, the use of both “five calendar days” and “120 hours” introduces unnecessary ambiguity into the policy. ICANN should strive for clarity and precision in its recommendations. While the intent is to improve clarity by specifying both calendar days and hours, this approach actually creates confusion, as calendar days and hours are not always perfectly aligned. To avoid any ambiguity, I strongly recommend that ICANN use hours exclusively in the policy recommendation. Specifying timeframes in hours will provide greater precision and ensure that the policy is implemented cleanly and consistently across all registrars. Once hours are defined as the authoritative timeframe, ICANN can reference calendar days in the Rationale or explanatory sections, which do not hold the same level of authoritative weight. This would keep the policy unambiguous while still offering contextual information where needed. The statement in the draft recommendation—"Consistent with the other recommendations in this report, the working group recommends specifying timeframes in both calendar days and hours for greater clarity."—is actually false in practice, as specifying both creates the very ambiguity ICANN aims to avoid. By adopting a clear, hours-based policy in the recommendation itself, ICANN can ensure that the policy is implemented without confusion and is consistent across all registrars. In conclusion, while I support the core of Recommendation #17, I urge ICANN to revise the recommendation text to eliminate ambiguity and ensure the implementation is as clean and precise as possible. Moving commentary to the Rationale and focusing the recommendation on using hours for precise timeframes would greatly enhance clarity and consistency in the policy.

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

The prior concern about the ambiguity (as noted in the comment above for Recommendation #3) of "30 calendar days /720 hours" also applies here. Use 720 hours, to be precise (and can then use the less precise days in the rationale).

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

I have significant concerns with ICANN’s Recommendation #26, particularly in relation to sections 26.2 and 26.3, which propose the removal of crucial language and security measures that directly impact the rights and protection of registrants. 1. Section 26.2: Removal of Key Registrant Rights Language Section 26.2 suggests removing a fundamental provision from the Transfer Policy, specifically Section II.B.1, which states: “In general, registrants must be permitted to update their registration/Whois data and transfer their registration rights to other registrants freely.” This statement is not just a procedural note—it is a critical declaration of registrants’ basic property rights over their domain names. Domain name registrants rely on the ability to update their Whois data and transfer their registration freely as part of their rights as domain holders. To remove this language would be to obscure a fundamental principle that registrants have relied on for years. It is absolutely necessary that this provision remain explicit within the policy. The suggestion that such rights are implicitly "understood" or can be inferred leaves far too much room for misinterpretation or misapplication by various individuals or groups. Different stakeholders may have different understandings of what these rights entail, and removing this explicit language risks diluting registrants’ rights over time. Therefore, this critical statement of registrants’ property rights must remain clearly stated in any future policy. 2. Section 26.3: Conclusion In summary, I strongly oppose Recommendation #26 as currently drafted, particularly sections 26.2 and 26.3. The removal of language that explicitly protects registrants’ basic rights, along with the elimination of critical security checks, would significantly undermine registrant protection. These provisions should remain in place to safeguard the interests of domain holders and to ensure the continued security and integrity of the domain name system. I urge ICANN to reconsider these changes and maintain both the explicit property rights of registrants and the essential security checks that protect their domains.

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

While we recognize the utility of notifications, Recommendation #27 does not resolve the critical security risks posed by Recommendation #26. We urge ICANN to reconsider both recommendations in tandem, ensuring that registrants are properly protected before changes are made to their domain registrations, not just notified afterward.

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

We understand and have sympathy for the operational burdens registrars face, but this should not come at the expense of fairness and consistency. ICANN must treat both registrars and registrants with equal consideration. It is unfair that ICANN would move to extend response times for registrars while continuing to deny registrants a similar extension in UDRP and URS disputes, which often place them at a significant disadvantage. In conclusion, we oppose Recommendation #29 unless registrants are provided with similar accommodations in UDRP and URS response timelines. If ICANN is to fix this problem for registrars, it must also address the identical issue faced by registrants. Until this double standard is corrected, we cannot support extending registrar response times without providing registrants the same opportunity. Fairness and consistency must be at the core of ICANN’s policies. The prior concern about the ambiguity (as noted in the comment above for Recommendation #3) of "24 hours / 1 calendar day" also applies here.

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

While we understand the need for greater flexibility for registrars, ICANN must ensure fairness and consistency for all stakeholders. We cannot support Recommendation #30 unless registrants are afforded the same consideration in UDRP and URS processes. It is time for ICANN to address the double standards that have long disadvantaged registrants and ensure that both parties are treated equally under its policies.

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

By utilizing a centralized system, ICANN can ensure that all communications are documented and tracked through a secure, reliable platform, reducing the risk of miscommunication and improving overall accountability. In the long term, this would create a more efficient and reliable process for handling registrar disputes and transfers, benefiting both registrars and registrants. In conclusion, Recommendation #32 should be revised to incorporate a centralized, neutral communication system rather than relying solely on email. Using a system similar to RDRS would provide the necessary validation and reliability to ensure that registrar-to-registrar communications are properly handled, with less risk of disputes over whether an email was received.

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

ICANN’s focus should be on structural improvements that will benefit the entire internet community and prevent the need for ADR in the first place. It makes no sense to build a costly, complex dispute resolution process for a small number of cases, when the courts already serve this function effectively. In conclusion, we oppose Recommendation #33. ICANN should not be wasting precious resources—including community time, effort, and funds—on creating an unnecessary ADR system. The court system already exists to handle these disputes, and ICANN should focus on what it does best: improving the security of the transfer process with initiatives like the push-based system. The community’s time and energy are finite, and ICANN should respect that by focusing on solutions that provide long-term value rather than duplicating processes that courts already handle.

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

we oppose the $50,000 ceiling as proposed in Recommendation #35. ICANN should work to ensure consistency in how fees are determined across the board, whether for bulk transfers or for .com domain registrations. If Verisign is allowed to maintain its monopoly, fees should be regulated and tied to actual costs, just as they are in other regulated industries. At a minimum, ICANN should conduct a thorough review of the costs involved in bulk transfers and adjust the fee accordingly, as the current figure has no basis in the actual costs of the process.