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 your response requires an edit or deletion of Preliminary Recommendation 2, please indicate the revised wording and rationale here.
We agree that the transfer process should, as noted in the Initial Report, be "simple, quick, and efficient". Accordingly, the removal of the 5-day delay caused by the Losing FOA procedure, on its face, would appear to be an improvement for registrants. Nevertheless, we have serious concerns regarding this Preliminary Recommendation since the proposed new procedure would apparently not provide a genuine opportunity for registrants in all cases, to invalidate a TAC upon receiving notice of it. Further explanation is provided below in our response to Preliminary Recommendation #3.
If your response requires an edit or deletion of Preliminary Recommendation 3, please indicate the revised wording and rationale here.
Preliminary Recommendation #3 expressly states under 3.2, that a registrant will receive "Instructions detailing how the RNH can take action if the request is invalid (how to invalidate a TAC)". Nevertheless, it is our understanding that a transfer may already have been effected by the time that the RNH receives this notice and/or is able to act upon it, thereby rendering the purported instructions to invalidate the TAC, ineffective in some cases. Accordingly, we encourage the Working Group to further explore this issue to ensure that RNHs always have the intended opportunity to invalidate a transfer prior to the transfer being effected. We recognize that a RNH who is able to request a TAC through its registrar, will presumptively be authorized to obtain the TAC and therefore in most cases, the TAC will have been legitimate obtained and there will be no need to invalidate it. We also recognize that if a RNH's registrar or email account has been penetrated, there will likely be no utility in sending a notice with instructions on how to invalidate the TAC via the same registrar account or email address that has already been penetrated by a hijacker such that the hijacker is the one that receives the notice. Nevertheless, in those cases where a RNH is still able to receive such notification, the ability to invalidate a TAC would still be very useful and help avoid a fraudulent transfer. For example, if a RNH receives notice via a different email address than is associated with the RNH's registrar account, i.e. an Admin email address, then that could provide an additional layer of security for the RNH that would seem to not be available under the current proposal. We therefore encourage the Working Group to explore whether it is possible to maintain a genuine opportunity for registrants in all cases to invalidate a TAC or to deny a transfer request. This could possibly involve a delay which is shorter than 5-day window as is featured in the current policy, provided that there remains a reasonable opportunity for registrants to stop an unauthorized transfer. Lastly, we believe that for many companies and individuals, domain names have evolved to be mission-critical and extraordinarily valuable assets. As such, security protocols and measures have become increasingly important. We recognize that some registrars have employed security protocols which provide additional and voluntary security for registrants while not unnecessarily impeding the portability of domain names. Where appropriate, such best practices deserve consideration for inclusion in Transfer Policy itself so that they become requirements of registrars. We recognize that not all registrants desire the identical balance between security and portability. Some may want more security even at the cost of faster portability and some may want faster portability even at the cost of less security. We therefore also encourage the Working Group to explore whether RNHs can be given the option for a faster transfer (e.g. as per the proposed new policy) or a slower transfer (as per the original policy including the NACKING opportunity) which nevertheless may provide greater comfort and security to RNHs.
If your response requires an edit or deletion of Preliminary Recommendation 4, please indicate the revised wording and rationale here.
Subject to our concerns set out above in connection with Recommendation 3.
It appears that if the notification to the Losing Registrar included the IANA ID it would be of assistance in avoiding confusion and streamlining the process.
If your response requires an edit or deletion of Preliminary Recommendation 7, please indicate the revised wording and rationale here.
It could possibly increase security for the transfer process in some cases if the TAC were able to have embedded within it, the identification of the specific gaining registrar as intended by the RNH when requesting the TAC. This would provide additional comfort and security to the RNH as it would provide confirmation in some cases, that the transfer was indeed going to the desired registrar which could serve as some confirmation that the authorized transferee was receiving and using the TAC at the identified and agreed registrar.
If your response requires an edit or deletion of Preliminary Recommendation 12, please indicate the revised wording and rationale here.
We are concerned with the proposed 120 hour maximum period. It would seem that a registrar would and should generally be able to provide the TAC in a much shorter time frame if not instantaneously. We believe that the Transfer Policy should generally require adherence to the best practices of registrars rather than cater to those registrars who are not equipped with up-to-date systems or who are are otherwise unable or unwilling to provide a TAC in a timely manner to RNHs. Therefore we encourage the Working Group to explore whether the 120 period can be substantially shortened in order to make transfers easier and more efficient. Moreover, it is important to note that this 120 period is of course >>not<< a mandatory waiting period that would provide additional notice to RNH of a pending TAC request and thereby enable a RNH to take action to prevent the TAC from being issued. Rather, some registrars will provide the TAC immediately. This 120 hour period therefore appears to merely cater to the slowest of registrars, which does not appear to be good policy.
If your response requires an edit or deletion of Preliminary Recommendation 13, please indicate the revised wording and rationale here.
We are concerned that although some registrars may set the TTL to null after a period of less than 14 days in order to increase security of the TAC, the permitted maximum of 14 days appears to be unnecessarily long given that the longer that it is available the generally greater chance that there is of its misuse. A shorter maximum length of time would therefore be prudent and we encourage the Working Group to consider shortening this period.
Given the registries’ concerns and given the deliberations of the Working Group as set out in the Initial Report, a registrar-managed TTL appears reasonable and prudent, subject to our concerns regarding its length as explained above.
If your response requires an edit or deletion of Preliminary Recommendation 16, please indicate the revised wording and rationale here.
Simply stating as the Interim Report does, that "For registrants who legitimately want to transfer a domain name shortly after registration, the working group believes that the 30 days is a reasonable period of time to wait", is wholly unsatisfactory to those registrants who wish to legitimately and for their own important business reasons, transfer a domain name earlier than 30 days from creation. We therefore believe that the length of the restriction should not only be lowered but that it should always be up to a registrar and its customer - the registrant - to agree to override any default restriction in appropriate circumstances. For example, where a registrar has no concerns about payment issues, no apparent ownership issues, no identification issues, and there are no apparent misuse issues, there is no genuine basis for denying a transfer. The goal of making restrictions consistent at 30 days is ultimately less important than permitting a registrant to transfer a domain name for its own business or other reasons when there is an absence of any reason for denying a transfer. That is not to say that a 30 day default period is unsatisfatory, provided that it is merely a default period that can be overridden in appropriate circumstances.. We also recognize that some registrars may have important business reasons (such as charge backs) for wanting to institute a restricted period, and indeed some registrars may choose to impose an restricted period that is even longer than as mandated by the Proposal. Conversely, some registrars may have business systems and payment validation services which make such delays unnecessary, or may have select clientele that pose low or no risk for expedited transfers without a restricted period.
If your response requires an edit or deletion of Preliminary Recommendation 17, please indicate the revised wording and rationale here.
As with our comment above in connection with post-creation restrictions, we believe that as a general principle, there should be no restrictions on transfer unless circumstances warrant. If a general default restriction is adopted, then a registrar and its customer, the registrant, should be able to agree to override the restriction in appropriate circumstances where warranted. We recognize that some registrars may have important business reasons (such as charge backs) for wanting to institute a restricted period, and indeed some registrars may choose to impose an restricted period that is even longer than as mandated by the proposal. Conversely, some registrars may have business systems and payment validation services which make such delays unnecessary, or may have select clientele that pose low or no risk for expedited transfers without a restricted period. We disagree that, "For registrants who legitimately want to transfer a domain shortly after registration, the working group believes that 30 days is a reasonable period of time to wait" as a general proposition. A registrant may have good reason to require a transfer right away, and in such circumstance ICANN policy should not require a registrant to "be patient" without a compelling basis for the delay. Particularly if the registrar itself acknowledges that it has no payment issues whatsoever, the parties involved are known to and identified by the registrar, and if there is no apparent or likely potential UDRP proceeding, then there is no considered reason for delaying a transfer request. In any event with regard to UDRPs, there is a transfer lock for UDRPS which provide adequate protection for complainants once the UDRP is commenced. We also strongly encourage the Working Group to propose a Transfer Dispute Resolution Policy which registrants can access and employ themselves, so that they are empowered to rectify unauthorized transfers, even when the domain name has hopped more than once to a different registrar. This would lessen the burden on registrars in having to deal with such situations and would enable registrants to be more confident that despite permitting the override of a default restriction as explained above, there is readily available recourse for registrants who currently are forced to rely entirely on registrars employing the Registrar Transfer Dispute Resolution Policy and are even then limited to dealing with only a single gaining registrar rather than multiple.
If your response requires an edit or deletion of Preliminary Recommendation 18, please indicate the revised wording and rationale here.
We suggest that the portion of the Transfer Policy which specifically includes restrictions on transfers, if any, be reproduced in a separate companion document that is in an easily understandable format for average registrants, along with commentary and guidance provided by ICANN.
If your response requires an edit or deletion of Preliminary Recommendation 19, please indicate the revised wording and rationale here.
We have serious concerns with regard to enabling registrars to prevent the transfer of a domain name away from their registrar due to an alleged violation of their "use policy". We recognize that most registrars are likely to employ reasonable use policies and interpret them fairly. Nevertheless, registrars are generally free to enact any kind of use policy that they want. For example, a registrar could enact a use policy which forbids any domain name from being used to support a particular lawful political candidate or a particular lawful policy. The registrar is then free to disable such domain, but why should it also be empowered to prevent the registrant from moving its domain name to a different registrar which does not have such a policy that infringes upon the registrant's lawful freedom of expression? Registrars should not necessarily be compelled to provide service to everyone that demands it and can tell a registrant to take its business elsewhere, but to allow a registrar to additionally prevent a desired transfer, would essentially enable a registrar to hold a domain name "hostage" and use its powers as a registrar to influence or prevent lawful freedom of expression. While we recognize that most credible registrars would have reasonable policies that permit lawful use of a domain name, we cannot presume that is always the case or presume that some registrars may interpret their own use policies in a broad, self serving, or capricious manner. We therefore strongly oppose this Preliminary Recommendation as it unduly empowers registrars to play a role in censorship and deprive lawful registrants of the lawful use of their domain name. This issue may become particularly acute if the registrar is located in a jurisdiction wherein the national authority exercises substantial control or influence over a registrar, thereby enabling a government to effectively prevent the use of a domain name which may be perfectly legal in another jurisdiction.
If your response requires an edit or deletion of Preliminary Recommendation 20, please indicate the revised wording and rationale here.
We reiterate our concerns with respect to the 30-day period of restrictions on transfer post- creation or post-registrar transfer, as explained above.
If your response requires an edit or deletion of Preliminary Recommendation 22, please indicate the revised wording and rationale here.
With regard to transfer restrictions, we reiterate our concerns regarding the proposed restrictions as set out above, and we will have more comments on change of registrant restrictions when the issue is addressed in Phase 1(b).
The Internet Commerce Association expresses its gratitude to the Transfer Policy Working Group for its diligent, thoughtful, and timely Interim Report. The Transfer Policy obviously presents complex issues which are challenging to navigate, and on the whole we support the Proposals made in the Interim Report. Nevertheless, we do have some significant concerns regarding particular Proposals within the Interim Report which we ask the Working Group to continue to thoughtfully explore after taking into account all Public Comments.