[GNSO-TPR] [EXTERNAL] Re: Reason why Losing Registrar may NACK

[Rick Wilhelm]

While I’m sympathetic to this situation, the registrar with IANA number 2482 (Sticting Registrar of Last Resort Foundation) does not have special standing.  It is one registrar accreditation among many.

Granted, it has a different type of “business model” than the typical registrar, but it has the same accreditation.

There might be space in the ecosystem for a special type of registrar accreditation, designated toward warehousing bad domains.  (Think of a “bad registrar” program, modeled after the concept of a “bad bank” IRL:  https://en.wikipedia.org/wiki/Bad_bank .)  But that sort of thing doesn’t exist.

Regardless, it would seem to be a huge step for the Transfer PDP to be moving in the direction of creating distinctions between registrars.

Happy to discuss further on Tuesday.

Thanks
Rick


From: GNSO-TPR <gnso-tpr-bounces at icann.org> on behalf of Mike Rodenbaugh <mike at rodenbaugh.com>
Date: Thursday, December 8, 2022 at 12:30 PM
To: Transfer PDP WG <gnso-tpr at icann.org>
Subject: [EXTERNAL] Re: [GNSO-TPR] Reason why Losing Registrar may NACK
CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.
________________________________
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://protect-us.mimecast.com/s/eRiTCOYzm8C5vyyIEgYBU?domain=icann.org>."

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://protect-us.mimecast.com/s/eRiTCOYzm8C5vyyIEgYBU?domain=icann.org>.  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


[Logo]

Mike Rodenbaugh

address:

548 Market Street, Box 55819

San Francisco, CA 94104

email:

mike at rodenbaugh.com<mailto:mike at rodenbaugh.com>

phone:

+1 (415) 738-8087


On Tue, Dec 6, 2022 at 9:43 AM Sarah Wyld <swyld at tucows.com<mailto: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://protect-us.mimecast.com/s/eRiTCOYzm8C5vyyIEgYBU?domain=icann.org>."

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<mailto:swyld at tucows.com>

_______________________________________________
GNSO-TPR mailing list
GNSO-TPR at icann.org<mailto:GNSO-TPR at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-tpr<https://protect-us.mimecast.com/s/km5kCPNAnQSv3kkH09pR0?domain=mm.icann.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20221212/02754fb7/attachment-0001.html>