[GNSO-TPR] ICANN org input on TPR Preliminary Recommendation 19, Transfer Policy Section I.A.3.7.1

Fri Feb 17 16:16:08 UTC 2023

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 at rodenbaugh.com

phone:

+1 (415) 738-8087

On Fri, Feb 17, 2023 at 6:43 AM Emily Barabas <emily.barabas at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20230217/ef295b21/attachment-0001.html>