<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>It would be helpful for Isabelle and Holida to provide alternate sources for the DNS Abuse definition, as they suggest.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="font-family:arial;font-size:small"><span><br><div dir="ltr" style="margin-left:0pt" align="left"><table style="border:none;border-collapse:collapse"><colgroup><col width="203"><col width="86"><col width="335"></colgroup><tbody><tr style="height:20.25pt"><td rowspan="4" style="border-right:0.75pt solid rgb(0,133,61);vertical-align:middle;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:159px;height:95px"><img alt="Logo" src="https://lh4.googleusercontent.com/S_Oxvn9Vep0rF8IVyiOnDwA4LymtHrWirggIxlsU26JihhEYDv5A5D03ZY0k_npND2t8xfiWCdTM5NTO_LSZMksjO_UlJm5IAP3FEi5cw96AwIPgVzvoOfHIux_qNA26n5UuxvQZ" width="159" height="95" style="margin-left:0px;margin-top:0px"></span></span></p></td><td colspan="2" style="border-left:0.75pt solid rgb(0,133,61);vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;margin-left:3.6pt;margin-top:0pt;margin-bottom:0pt"><span style="font-size:12pt;font-family:Arial;color:rgb(0,133,61);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">Mike Rodenbaugh</span></p></td></tr><tr style="height:18pt"><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;margin-left:3.6pt;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,133,61);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">address:</span></p></td><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.53;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">548 Market Street, Box 55819</span></p><p dir="ltr" style="line-height:1.53;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">San Francisco, CA 94104</span></p></td></tr><tr style="height:12.75pt"><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;margin-left:3.6pt;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,133,61);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">email:</span></p></td><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.53;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><a href="mailto:mike@rodenbaugh.com" target="_blank">mike@rodenbaugh.com</a></span></p></td></tr><tr style="height:24pt"><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;margin-left:3.6pt;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,133,61);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">phone:</span></p></td><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.53;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">+1 (415) 738-8087</span></p></td></tr></tbody></table></div></span></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 17, 2023 at 6:43 AM Emily Barabas <<a href="mailto:emily.barabas@icann.org">emily.barabas@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-5011629438116537457">
<div lang="en-BE" style="overflow-wrap: break-word;">
<div class="m_-5011629438116537457WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear working group members, <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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. <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Kind regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Caitlin, Julie, Berry, Emily<u></u><u></u></span></p>
<div style="border-top:none;border-right:none;border-left:none;border-bottom:1pt solid windowtext;padding:0cm 0cm 1pt">
<p class="MsoNormal" style="border:none;padding:0cm"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p style="margin-right:0cm;margin-bottom:10pt;margin-left:0cm">
<i><span lang="EN-US" style="color:black">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:
<span style="background:white">“Evidence of (a) fraud or (b) the domain presents an active DNS Security Threat as defined here:
</span></span></i><i><span lang="EN-US"><a href="https://www.icann.org/dns-security-threat" target="_blank">https://www.icann.org/dns-security-threat</a><span style="color:black;background:white">."</span><u></u><u></u></span></i></p>
<p style="margin-right:0cm;margin-bottom:10pt;margin-left:0cm">
<i><span lang="EN-US" style="color:black">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. </span></i><i><span lang="EN-US"><u></u><u></u></span></i></p>
<p style="margin-right:0cm;margin-bottom:10pt;margin-left:0cm">
<i><span lang="EN-US" style="color:black">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:</span></i><i><span lang="EN-US"><u></u><u></u></span></i></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="color:black;vertical-align:baseline">
<i><span lang="EN-US">3.7.1 Evidence of Fraud.<u></u><u></u></span></i></li><li class="MsoNormal" style="color:black;vertical-align:baseline">
<i><span lang="EN-US">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.<u></u><u></u></span></i></li></ul>
<p class="MsoNormal" style="margin-bottom:12pt"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<p style="margin:0cm"><i><span lang="EN-US" style="color:black;background:white">ICANN org notes that additional guardrails may be appropriate in the form of implementation guidance, for example:</span></i><i><span lang="EN-US"><u></u><u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<p style="margin-right:0cm;margin-bottom:0cm;margin-left:36pt">
<b><i><span lang="EN-US" style="color:black;background:white">Implementation Guidance:
</span></i></b><i><span lang="EN-US" style="color:black;background:white">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.</span></i><i><span lang="EN-US"><u></u><u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<p style="margin:0cm"><i><span lang="EN-US" style="color:black;background:white">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:</span></i><i><span lang="EN-US"><u></u><u></u></span></i></p>
<p class="MsoNormal" style="margin-bottom:12pt"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="color:black;vertical-align:baseline">
<i><span lang="EN-US" style="background:white">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”. </span></i><i><span lang="EN-US"><u></u><u></u></span></i></li><li class="MsoNormal" style="color:black;vertical-align:baseline">
<i><span lang="EN-US" style="background:white">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. </span></i><i><span lang="EN-US"><u></u><u></u></span></i></li><li class="MsoNormal" style="color:black;vertical-align:baseline">
<i><span lang="EN-US" style="background:white">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.</span></i><i><span lang="EN-US"><u></u><u></u></span></i></li></ul>
<p class="MsoNormal"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<p style="margin-right:0cm;margin-bottom:10pt;margin-left:0cm">
<i><span lang="EN-US" style="color:black">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. </span></i><i><span lang="EN-US"><u></u><u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US">Regards,<u></u><u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US">Isabelle and Holida <u></u><u></u></span></i></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif;color:black">Emily Barabas</span><span style="color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif;color:black">Policy Development Support Senior Manager</span><span style="color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif;color:black">Internet Corporation for Assigned Names and Numbers (ICANN)</span><span style="color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif;color:black">Phone: +31 (0)6 84507976</span><span style="color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif;color:black"><a href="http://www.icann.org/" title="http://www.icann.org/" target="_blank"><span style="color:rgb(5,99,193)">www.icann.org</span></a></span><span style="color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> <u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
_______________________________________________<br>
GNSO-TPR mailing list<br>
<a href="mailto:GNSO-TPR@icann.org" target="_blank">GNSO-TPR@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-tpr" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-tpr</a></div></blockquote></div>