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 #6, please indicate the revised wording and rationale here.
Rather than the term SLA for TAC Provision, this recommendation should be titled as “Maximum Time/Required Timing/Mandatory Timing for TAC Provision”. SLA implies that 5 calendar days would be the norm/expected, when it is really the outer limit.
2. If your response requires an edit or deletion of Recommendation #25, please indicate the revised wording and rationale here.
Specifically for recommendation 25.3, we would like to highlight that privacy and proxy are indeed different services and changing the proxy service provider would be an entire change of registrant. We don't believe it’s appropriate to treat proxy and privacy services as if they are identical services because the ownership under those business models is very different and in the case of the proxy service provider, they are the registered name holder. If the proxy service provider changes for example, it should be considered a change in registrant data and therefore trigger a notification to the RNH by the registrar or its affiliates.
2. If your response requires an edit or deletion of Recommendation #26, please indicate the revised wording and rationale here.
After taking into account the introduction to this section of recommendations, and the proposed changes for recommendation 26, including removing the approval from the previous and new registrant contacts and removing the 60-day lock, we are concerned that someone could initiate a transfer away from the current registrar before the original registrant has been notified within the newly stated 24-hour period that there has been either a change in registrant entirely or a change to the data such as an email address. This could be going from one extreme, with all the required approvals and lock in the current policy, to the other extreme, requiring no approvals or lock and only notifying the registrant within 24 hours after a change. If possible, we should put into place an immediate automatic notification email sent to the current registrant that the registrant data itself has changed, such as an email address or that the registrant contact has been changed entirely.
2. If your response requires an edit or deletion of Recommendation #34, please indicate the revised wording and rationale here.
Recommendation title change to include “fees associated with voluntary/involuntary full portfolio transfers over 50,000 domain names”. Additionally, section 34.2 should be split into two parts; One: The registry MAY waive the fee associated with full portfolio transfers. Two: in full portfolio transfers resulting from an involuntary Registrar termination, i.e., where a Registrar is terminated by ICANN due to non-compliance with the Registrar Accreditation Agreement, the working group recommends the Registry MUST waive any fee associated with a full portfolio transfer. This way it is abundantly clear differentiating between the two situations.
Yes. The updated format is extremely helpful. We were able to easily find the information pertaining to each recommendation and the reasoning behind such recommendations.
The format has a great formula that allows even novices to follow what is being detailed. As transfers can range from instantaneous completion to agonizing steps, this document properly covers what to expect and how to hopefully enhance the process.
Com Laude would find it helpful if the implementation window for the Transfer Policy does not overlap with the Registration Data Policy implementation window. While the impact of many of the recommendations are identified as low, lots of low impact recommendations do add up.