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."

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. 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

	Mike Rodenbaugh
	address:	548 Market Street, Box 55819 San Francisco, CA 94104
	email:	mike@rodenbaugh.com
	phone:	+1 (415) 738-8087

On Tue, Dec 6, 2022 at 9:43 AM Sarah Wyld <swyld@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."

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@tucows.com 
_______________________________________________
GNSO-TPR mailing list
GNSO-TPR@icann.org
https://mm.icann.org/mailman/listinfo/gnso-tpr