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.

Ce contenu est uniquement disponible en

  • English

Name: Sarah Wyld
Date: 28 Jul 2022
Affiliation: Tucows
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 intent with wording change

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” is incorrect as it should simply be “the RNH at the time of the TAC request” to allow for registrants who use Privacy/Proxy service data. We suggest removal of “, as listed in the Registration Data” so that it reads “to the RNH at the time of the TAC request”. c.f. Recommendation 14.

Please choose your level of support for Preliminary Recommendation 4.
Support Recommendation intent with wording change

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

Tucows suggests that the following points be added to the notification required in 4.3: - The IANA ID of the Gaining Registrar (Optional: providing the name of the gaining registrar) - A link to the IANA registrar ID reference page (allows RNH to lookup the name of the gaining registrar with the IANA ID) Gaining Registrar IANA ID MUST be provided in the EPP Poll notice from the registry to the Losing Registrar, and the Losing Registrar should thus inform the RNH of this IANA ID. This way, the RNH knows exactly where the domain was transferred (can confirm it was to the correct destination).

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.

Yes, the IANA ID should be provided by the registry for use in notification. While some registries have their own system for identifying registrars, a universal standard (IANA ID) would be best. Providing the IANA ID of the Gaining Registrar can save the RNH and Losing Registrar time in cases of domain hijacking.

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 as written
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 intent with wording change

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

​​Tucows suggests that the following changes be made to the recommendation to allow it to be part of the Transfer Policy, separate from 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.

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.
Support Recommendation intent with wording change

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

​​Tucows suggests that the following changes be made to the recommendation to allow it to appropriately convey its intended meaning: 13.1: The maximum Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry, enforced by the Registry. The change from “standard” to “maximum” is in accordance with §13.2 which allows for a shorter TTL but not for a longer one. “Standard” is not the appropriate descriptor for this maximum TTL of 14 days. The change from “enforced by the Registries” to “enforced by the Registry" is to clarify that the registry is authoritative for the TLD in question: only the registry may enforce the TTL and only that registry may do so.

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?

Every Registry–Registrar Agreement includes a provision that indicates that questions of EPP status will be resolved by what is kept at the registry. The registry is authoritative for everything that occurs within that TLD—the registrar's creation of a TAC will be “created” at the time the registry receives confirmation, via EPP, that the registrar has done so. Only the registry can therefore determine when the TAC will expire.


It is not a matter of customer relationship but rather of technical capability.


Registries already deny transfers for various reasons (locks, holds, legal obligations, invalid TAC provided) and registrants are already expected to contact the registrar, rather than registry, in these cases. Enforcement of TAC TTL simply adds one more point of verification to a registry’s existing transfer approval system. This enforcement does not create any relationship between the RNH and a registry.


There are fewer than 50 gTLD registries, but thousands of domain registrars. Enforcement of the TAC TTL can only be done at the registry level.


Tucows 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.

Please choose your level of support for Preliminary Recommendation 14.
Support Recommendation intent with wording change

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

Tucows notes that “Registration Data” could suggest that this includes Privacy/Proxy service data and suggests including an Implementation Note clarifying language in Recommendation 14 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.”

Please choose your level of support for Preliminary Recommendation 15.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 16.
Significant change required: changing intent and wording

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

30 days is too long; 14 days is sufficient. Most chargebacks are filed within 2-5 days of a charge, so 14 days is sufficient time to address chargebacks. For UDRP cases, 14 days is still sufficient; the use case where one might need to refile a UDRP if the domain is transferred while preparing the filing is very rare and is a minor change (it simply requires an update to the filing to match the new registrar information). Regardless of the registrar that currently manages the domain, all registrars still have to lock the domain upon notice from the Dispute Resolution Panel. Note: To avoid RNH confusion, the lock period for both new registrations and inter-registrar transfers should be the same. The lock period should also align with the period allowed to submit a transfer dispute which will be discussed in a later phase of this WG.

Please choose your level of support for Preliminary Recommendation 17.
Significant change required: changing intent and wording

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

Same comment as on Recommendation #16.

Please choose your level of support for Preliminary Recommendation 18.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 19.
Support Recommendation intent with wording change

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

“Evidence of fraud or violation of the Registrar's [policies]” reads as though there must be evidence provided of the violation of policies. The intent of this change was to add “violation of policies” not to add “evidence of violation of policies”. Tucows supports the intent of the change and recommends the following wording: “Violation of the Registrar's domain use or anti-abuse policies or evidence of fraud.” In the alternative, Tucows would support the addition of a comma after “fraud” in the current wording.

Please choose your level of support for Preliminary Recommendation 20.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 21.
Significant change required: changing intent and wording

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

In accordance with our comment to Recommendation 16 and 17, we recommend that I.A.3.7.5 be changed from “requested within 60 days” to “requested within 14 days”. We otherwise support the intent and wording of the additional changes.

Please choose your level of support for Preliminary Recommendation 22.
Support Recommendation intent with wording change

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.”

Are there any recommendations the Working Group has not considered? If yes, please provide details below.

Tucows thanks the ICANN Staff team, WG Leadership, especially the insightful Chair, and all members and alternates of the WG, for their hard work and tireless dedication. We are very pleased to contribute to improving the transfer process and we know it will benefit domain owners.

Summary of Submission

We believe that:

- transfers should be simple (for the RNH) to perform.

- restrictions on when a domain can be transferred should be minimal.

- a transfer should not require sharing of private personal data.


We believe this can be achieved in balance with ensuring that the updated transfer policy does not make it easier to steal domain names. We thank this PDP WG for their efforts towards meeting these goals.