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.
Contenido disponible solo en los siguientes idiomas
If yes, please explain.
This comment is on behalf of the ICANN Business Constituency (BC). It was drafted by John Berard, Howard Neu, and Vivek Goyal, with advice from Zak Muscovitch and Arinola Akinyemi. This comment was approved in accord with the BC Charter.
If your response requires an edit or deletion of Preliminary Recommendation 3, please indicate the revised wording and rationale here.
The BC acknowledges that the proposed new Notification of TAC Provision intends to speed up and streamline the transfer process. However we are concerned whether in all circumstances a RNH will be able to invalidate a TAC upon receipt of such notification, and therefore encourage the WG to further explore this issue to ensure that RNHs always have an opportunity to effectively invalidate a TAC prior to transfer.
If feasible and practical, notification to the Losing Registrar should include the IANA ID to avoid confusion and streamline the process.
Given the registries’ concerns and given the deliberations of the Working Group as set out in the Initial Report, the recommended standard registrar managed 14 day TTL appears reasonable and prudent.
The BC specifically concurs with the registries that TTL remain under control of registrars, who maintain the customer relationship with registrants.
If your response requires an edit or deletion of Preliminary Recommendation 16, please indicate the revised wording and rationale here.
The BC Supports Rec 16, and adds the following comment solely to document internal BC discussions that led to our support for this Recommendation. 60 days is preferable to 30 days from the BC perspective, although 30 days is a reasonable compromise. The longer the better from a trademark enforcement perspective as it prevents having to redo a UDRP or demand letter, and also assists with preventing registrar “hopping” when a registrar is asked to take enforcement proceedings against an infringing or unlawfully used domain name. We note that shortening the period could be an issue for registrars, in that a registrant may take advantage of promotional / loss-leader type pricing for the initial year and then the customer moves away to another registrar.
If your response requires an edit or deletion of Preliminary Recommendation 17, please indicate the revised wording and rationale here.
The BC Supports Rec 17, and adds the following comment solely to document internal BC discussions that led to our support for this Recommendation. This lock does not appear to be of significant concern as it would usually coincide with a change of registrant lock. However, a registrant should not be prevented from transferring a domain name from one registrar to another, even after a recent registrar change, unless there is another type of lock at play. The BC recognizes that it is unlikely that a post inter-registrar transfer lock will often be an issue for business registrants. Nevertheless, the BC has concerns that if in the unusual event a business registrant wishes for an important business reason, to change registrars after a recent registrar change such as an acquisition or change in service provider, a 30 day lock would be a hinderance. If the registrant’s registrar is willing to allow the transfer notwithstanding the default inter-registrar transfer lock, then that is something that should be between the business and its service provider, the registrar, rather than an across the board mandatory lock. Nevertheless, if there is to be a lock, the 30 day lock appears to be of a reasonable and manageable length.
The attachment is a duplicate of the responses filed in this form, and is provided just to document all our responses in a single PDF for convenience of BC members.
The ICANN Business Constituency (BC) supports all recommendations except Rec 3, and we have provided explanation for other recommendations that we have supported.