[GNSO-TPR] Reason why Losing Registrar may NACK

[Mike Rodenbaugh]

Thanks all for the healthy discussion on this issue on today's WG call.

As I mentioned, perhaps if the registrar has clear and convincing evidence
that a domain is a DNS Security Threat, then it MUST deny the transfer.
This is to prevent registrars from pushing clear DNS Security Threats
somewhere else.

Owen said that would prevent registrars from giving domains to brandowners
who ask for them.  But I am not aware that registrars actually do that.
Would any other registrar rep confirm that happens?

Crystal raises the better point that it would prevent pushing domains to
the Registrar of Last Resort or similar.  But that could be easily carved
out, something like this...

*Registrar MAY NACK a request if it has "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>."*


*Registrar MUST NACK. request if it has "Clear and convincing evidence that
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>.  In such cases, the
registrar MAY transfer the name to the Registrar of Last Resort [defined
here, to include similar things]"*

I do not see how it could be defensible to transfer out a name to any other
registrar under such circumstances.  But I look forward to any arguments
otherwise.

Thanks,
Mike

[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 Tue, Dec 6, 2022 at 9:43 AM Sarah Wyld <swyld at tucows.com> wrote:

> Hello team,
>
>
>
> A smaller group remained on the call after the main team wrapped up today
> to discuss how to adjust the 'evidence of fraud' reason for a registrar to
> NACK a transfer out.
>
>
>
> The updated text that we propose to be used in this area is:
>
>
>
> *"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>." *
>
>
>
> We wanted to balance two things:
>
> 1. Registrars must be able to NACK transfers out in appropriate
> circumstances, such as when the RNH is using the domain for something
> illegal or that threatens the healthy functioning of the DNS.
>
>
>
> 2. Registrants need predictability (e.g. avoiding situations where a
> registrar changes the relevant agreement in a sudden or surprising manner),
> and freedom of choice for their provider.
>
>
>
> We considered referring to DNS Abuse, but with the awareness that ICANN
> has defined "DNS Security Threat" at the link mentioned above, and since
> the 5 categories of harm are essentially the same (compared to the DNS
> Abuse Framework), we decided to go with "DNS Security Threat".
>
>
>
> We also considered that there should be evidence of such a threat, and
> that it should be active as opposed to resolved (e.g. a domain that was
> compromised and used for abuse, but has since been restored to appropriate
> usage).
>
>
>
> We hope that this proposed language will be acceptable to the broader
> team, and look forward to feedback. I would particularly like to know if
> the (a) and (b) structure makes it clear that evidence is required in both
> cases (fraud or security threat).
>
>
>
> Thanks,
>
>
>
> --
>
> *Sarah Wyld*, CIPP/E
>
>
>
> Policy & Privacy Manager
>
> Pronouns: she/they
>
>
>
> swyld at tucows.com
>
>
> _______________________________________________
> 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/20221208/6aa96afb/attachment.html>