Thanks to Isabelle and Holida for this important intervention. We definitely need to revisit this discussion, and ensure that registrars may deny a transfer where anti-abuse terms are violated -- as per the current Policy, and as per the group's earlier consensus. We cannot weaken the Policy in this regard. I am sure there is no consensus to do so. It just needs to be clarified. I also like the idea of separating out the reasons: 1) evidence of fraud; 2) evidence of DNS Abuse; and 3) violation of Anti-abuse Policies. It would be helpful for Isabelle and Holida to provide alternate sources for the DNS Abuse definition, as they suggest. [image: Logo] Mike Rodenbaugh address: 548 Market Street, Box 55819 San Francisco, CA 94104 email: mike@rodenbaugh.com phone: +1 (415) 738-8087 On Fri, Feb 17, 2023 at 6:43 AM Emily Barabas <emily.barabas@icann.org> wrote:
Dear working group members,
As you know, ICANN org Liaisons from Compliance and GDS continue to follow working group deliberations and coordinate org input where it may be helpful to support working deliberations. In reviewing recent revisions to the Preliminary Recommendations, org has provided some specific comments on Recommendation 19 - I.A.3.7.1. Please see below.
The working group will have an opportunity to discuss this feedback when we return to Phase 1(a) topics in the future, but we are sharing it now so that members have an opportunity to digest the input and discuss with your groups, as appropriate.
Kind regards,
Caitlin, Julie, Berry, Emily
*The ICANN organization (org) has been following the conversations in the Transfer Policy Review working group regarding denial of transfers, and specifically regarding section I.A.3.7.1 of the Transfer Policy. ICANN org understands that currently, the working group is considering draft recommendation language that would recommend revising section I.A.3.7.1 of the Transfer Policy to state that a Registrar of Record MAY deny a transfer for the following reason: “Evidence of (a) fraud or (b) the domain presents an active DNS Security Threat as defined here: **https://www.icann.org/dns-security-threat <https://www.icann.org/dns-security-threat>."*
*ICANN org would like to provide some additional feedback on the latest version of this recommendation. In providing this feedback, we want to emphasize that this feedback is for the purposes of providing factual information concerning Contractual Compliance complaints in this area, and Compliance-related issues associated with the language under consideration by the team. As a reminder, the discussion of revising I.A.3.7.1 was in part prompted by observations ICANN org has garnered from the receipt of complaints related to and the enforcement of the Transfer Policy. Throughout the years, ICANN Contractual Compliance has received complaints involving transfer requests which were denied by the sponsoring registrars because such requests involved domain names that were identified as “abusive” by the registrar. The registrars conducted investigations and determined that the domain names were being used to perpetuate abusive and/or illegal activities. These registrars then suspended and locked the domain names for transfers as part of their abuse investigations and responses, and related mitigation efforts. However, under the current Transfer Policy, the suspension of an abusive domain name is not, by itself, a permitted ground for denying a transfer request. Further, many of these cases would also not fall within the scope of the language under consideration by the working group, because these cases were not limited to DNS Security Threats. Specific examples of these compliance cases included domain names allegedly used to perpetuate distribution of Child Sexual Abuse Material (CSAM), medication without prescription or imagery determined by the registrar to be violent and against its terms of service. ICANN org would like to clarify that the new language proposed by the working group would not provide a basis for denial in the scenarios above or similar that are not strictly related to DNS Security Threats. *
*If the working group believes that the Transfer Policy should provide grounds for denial where the domain name has been found to perpetuate the activities cited above (or other harms beyond DNS Security Threats) the language of the draft recommendation would need to be broadened. For example: The Registrar or Registrar of Record may deny an inter-registrar transfer request only in the following specific instances:*
- *3.7.1 Evidence of Fraud.* - *3.7.2 Evidence of the domain name being engaged in an activity expressly prohibited by the Registrar’s domain anti-abuse terms and policies.*
*ICANN org notes that additional guardrails may be appropriate in the form of implementation guidance, for example:*
*Implementation Guidance: **A Registrar may use this denial reason only after determining, through its own investigation, that the domain name subject to the transfer request is used for an activity expressly prohibited by the Registrar’s anti-abuse terms and policies. In all instances, the Registrar must comply with the applicable requirements in this Transfer Policy and the Registrar Accreditation Agreement relating to providing Registered Name Holders with access to transfer processes information and the terms and conditions upon which the Registrar will prohibit the transfer of a domain name. In short, the Registered Name Holder must have access to information explaining that the activity is prohibited and that the consequences for engaging in it may include a transfer denial.*
*ICANN org understands the working group’s concerns that broad provisions could potentially be used by a registrar to unfairly prevent a registrant from transferring the domain to a new registrar. ICANN org notes the following additional considerations that the working group may want to take into account:*
- *Separating the existing subsection in this provision “evidence of fraud” and the new abuse-related denial reason may allow the production of a denial reason that is comprehensive enough to address the concerns of potential misuse with implementation guidance. It may also prevent the potential interpretation that there is some type of dependency between fraud and any other type of abuse which may be considered under this subsection. Under Section II.C.3.6 of the Transfer Policy, registrars can already modify registrant information without following the Change of Registrant process (hence, without obtaining registrant’s consent) when it is done “in response to an abuse complaint”. * - *For most generic top-level domains, registrars are expected to include in their registration agreements with the registrants the list of prohibited activities and the consequences for engaging in these activities. The Transfer Policy also requires the registrar to include in the registration agreement the terms and conditions upon which it prohibits a transfer (if the registrar decides to enact the “clientTransferprohibited” status). Therefore, the registrant must have access to information regarding the instances in which a registrar may deny a transfer request before deciding whether to use such a registrar or not. * - *The information provided to the registrant, coupled with a detailed explanation of the ground for denial can potentially help prevent a potential abuse of this section while still permitting registrars to deny transfers in certain scenarios which do not necessarily involve security threats.*
*Should the working group choose to keep the recommendation focused on DNS security threats as it is currently drafted, ICANN org would like to raise concern that the suggested language references a webpage. As in all agreements and policies, linking to a webpage may create challenges in the future because webpages and the location of content may be modified or no longer be available over time. In addition, the referenced ICANN org webpage is not intended to define DNS Security Threats but rather explain ICANN org efforts in supporting the mitigation of DNS Security Threats. ICANN org suggests that if a link to a definition is included, the link points to a more stable resource. ICANN org can suggest possible resources on request. *
*Regards,*
*Isabelle and Holida *
Emily Barabas
Policy Development Support Senior Manager
Internet Corporation for Assigned Names and Numbers (ICANN)
Phone: +31 (0)6 84507976
www.icann.org
_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr