Thanks Farzi. 1. Agree. 2. Agree. Best, Paul [cid:image001.png@01DCB77D.BD9DC260] Paul McGrady Partner Elster & McGrady 434 Houston St, Suite 261 Nashville, TN 37203 3847 N. Lincoln Avenue Second Floor Chicago, IL 60613 Office Direct: +1 (312) 515-4422 paul@elstermcgrady.com<mailto:paul@elstermcgrady.com> www.elstermcgrady.com<http://www.elstermcgrady.com/> From: farzaneh badii <farzaneh.badii@gmail.com> Sent: Thursday, March 19, 2026 8:27 AM To: Ching Chiao <ching.chiao@whoisxmlapi.com> Cc: Paul McGrady <paul@elstermcgrady.com>; Nick Wenban-Smith <Nick.Wenban-Smith@nominet.uk>; Brian F. Cimbolic <brian@pir.org>; Reg Levy <rlevy@tucows.com>; anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> Subject: Re: [Gnso-dnsabuse-pdp] Re: Straw Proposal Paul If I may, I think people can converse here and also put their ideas in the Google doc. I just want to clarify something about the charter. The charter tries not to be prescriptive, so while it creates a baseline for starting an ADC, it's up to this PDP to come up with indicators. The charter doesn't set the policy. We do. Farzaneh On Thu, Mar 19, 2026 at 6:52 AM Ching Chiao via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> wrote: Dear Paul, I agree. To be clear, I am not suggesting that we take on the role of creating annexes. Rather, I am suggesting that we keep our approach open and avoid focusing too much effort on tweaking Section 3.18.2 without first understanding the early input from stakeholders. Thanks again! Best regards, Ching On Thu, Mar 19, 2026 at 6:42 AM Paul McGrady <paul@elstermcgrady.com<mailto:paul@elstermcgrady.com>> wrote: Thanks Ching. Creating annexes is usually the role of an IRT, not a PDP. We can certainly add something like that to Implementation Guidance if we decided we want to encourage ICANN Staff to build such a thing. But, I think that is jumping ahead. Let’s talk through all the questions, do earlier ideation after each question, firm up what we can, keep swimming until we talk through all the Charter Questions and then congeal around some high level policy and some really useful Implementation Guidance. All while setting the landspeed record. Best, Paul [cid:image001.png@01DCB77D.BD9DC260] Paul McGrady Partner Elster & McGrady 434 Houston St, Suite 261 Nashville, TN 37203 3847 N. Lincoln Avenue Second Floor Chicago, IL 60613 Office Direct: +1 (312) 515-4422 paul@elstermcgrady.com<mailto:paul@elstermcgrady.com> www.elstermcgrady.com<http://www.elstermcgrady.com/> From: Ching Chiao <ching.chiao@whoisxmlapi.com<mailto:ching.chiao@whoisxmlapi.com>> Sent: Thursday, March 19, 2026 5:36 AM To: Nick Wenban-Smith <Nick.Wenban-Smith@nominet.uk<mailto:Nick.Wenban-Smith@nominet.uk>> Cc: Brian F. Cimbolic <brian@pir.org<mailto:brian@pir.org>>; Reg Levy <rlevy@tucows.com<mailto:rlevy@tucows.com>>; anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>>; Paul McGrady <paul@elstermcgrady.com<mailto:paul@elstermcgrady.com>> Subject: Re: [Gnso-dnsabuse-pdp] Re: Straw Proposal You don't often get email from ching.chiao@whoisxmlapi.com<mailto:ching.chiao@whoisxmlapi.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Nick, Paul, and all, I agree with Nick that we are still in the early stages of this process. I suggest we wait for stakeholder's early input to determine if the current discussion for Q1 is sufficient or if additional steps are necessary. Specifically, we may need to consider creating a new appendix to Section 3.18.2. This could serve as a checklist to provide clear guidelines for registrars while ensuring the policy is operationally enforceable by ICANN Compliance. Thank you very much! Best regards, Ching On Thu, Mar 19, 2026 at 6:21 AM Nick Wenban-Smith via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> wrote: Aw Paul you are spoiling our fun, drafting by remote committee is excellent viewing. Seriously though, I think in Mumbai we only really touched on the first of the nine questions set out in the Charter, namely what's the trigger for an ADC. I think that was settled pretty quickly in fact, it's when a registrar knows (or ought to know) that it has a malicious registration on its hands per RRA 3.18.2. However while I think it's really helpful to test out some ideas for how the contractual wording might look like in the black and white text (and in particular to align with existing terminology in the RRA at an early stage), I am not sure we as a group have really grappled with the more tricky questions which are to come including the definition of "associated domain" and also what "investigation" means in practice in this context for the registrars concerned (questions 2 & 3 in the charter). Until those have been discussed and some basic principles agreed then I think there's limited progress that can be made in putting that into meaningful wording which would be actionable in a compliance sense. Best wishes Nick ________________________________ From: Paul McGrady via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Sent: 19 March 2026 09:40 To: Brian F. Cimbolic <brian@pir.org<mailto:brian@pir.org>>; Reg Levy <rlevy@tucows.com<mailto:rlevy@tucows.com>>; anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Subject: [Gnso-dnsabuse-pdp] Re: Straw Proposal Caution: This is an external email and may be malicious. Please take extra care when replying, clicking links or opening attachments. Thanks Brian. I am meeting with Staff today and I hope we can get this Strawperson language into a Google Doc for folks to comment on. Keeping track of this via email string is going to be impossible with a group this size. Please stay tuned and do add your suggestions to Q1 Strawperson as soon as we get that Google Doc live. Best, Paul [cid:image001.png@01DCB77D.BD9DC260] Paul McGrady Partner Elster & McGrady 434 Houston St, Suite 261 Nashville, TN 37203 3847 N. Lincoln Avenue Second Floor Chicago, IL 60613 Office Direct: +1 (312) 515-4422 paul@elstermcgrady.com<mailto:paul@elstermcgrady.com> www.elstermcgrady.com<http://secure-web.cisco.com/1ycb1KaZsRf7jFSzJH1vBR9qRb6_kEVHRk1cZug4_yBIPHQN...> From: Brian F. Cimbolic via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Sent: Wednesday, March 18, 2026 4:14 PM To: Reg Levy <rlevy@tucows.com<mailto:rlevy@tucows.com>>; anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Subject: [Gnso-dnsabuse-pdp] Re: Straw Proposal Hi all - First, thank you all for some great sessions to kick this work off in Mumbai. I thought we already made a lot of progress in our first working session. In advance of Monday’s call, I wanted to float a slightly modified version of the Strawman that Reg (very helpfully!) provided below. I provide a clean version, as well as a screenshot of Redlines so we can all see exactly what I’m proposing we change. Summary of proposed tweaks: * The actual obligation to mitigate DNS Abuse in the RAA is found in 3.18.2, rather than the broader 3.18, which includes other unrelated provisions. Tightening that subsection reference should make it clearer where an Associated Domain Check comes into play. * I tried to harmonize the language from Reg’s version with the terms and definitions set forth in the RAA already. So rather than “domains,” it’s “Registered Name” (again, simply to match the RAA defined terms). 3.18.2 also references “mitigation action(s)” so I incorporated that verbiage rather than the more generic “action." * 3.18.2 already requires that Registrars take mitigation action(s) when they have actionable evidence of DNS Abuse. If the Associated Domain Check is fruitful and the Registrar finds such actionable evidence of abuse, it is similarly obligated to take mitigation action(s). So, I suggest striking the “and take action against those domains where appropriate” as redundant. REDLINE: [Screenshot 2026-03-18 at 4.09.42 PM.png] CLEAN: When a registrar takes mitigation action(s) on a Registered Name under Section 3.18.2 of the Registrar Accreditation Agreement, the registrar shall promptly review other reasonably associated Registered Name(s) to determine whether such Registered Name(s) may be involved in DNS Abuse using information reasonably available to the registrar at the time of review. Looking forward to the call on Monday. Please let me know if you have any questions. Thanks, Brian [Logo]<https://secure-web.cisco.com/1PoC7u7Atiw2TJYkMRMIb21VDCVv77RbWLEb9hUKqreGgGJ...> Brian Cimbolic | Chief Legal and Policy Officer brian@pir.org<mailto:brian@pir.org> | www.thenew.org<http://www.thenew.org/> | Power your inspiration. Connect your world. [cid2922828134*image003.png@01D94119.58E327D0][A green sign with a white star and black text Description automatically generated] Confidentiality Note: Proprietary and confidential to Public Interest Registry. If received in error, please inform sender and then delete. From: Reg Levy via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Date: Monday, March 9, 2026 at 6:19 AM To: anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Subject: [Gnso-dnsabuse-pdp] Straw Proposal All— As noted in the chat in the session today, this is the straw proposal a number of us have been working on for the last few days and we’d love additional input: When a registrar takes action under Section 3.18 of the Registrar Accreditation Agreement, the registrar shall promptly review other domains that are reasonably associated with that domain when there are clear indicators that other domains registered by the same customer may be involved in the same abusive activity, using information reasonably available to the registrar at the time of review, and take action against those domains where appropriate. Servus, Reg -- Reg Levy | Associate General Counsel – Domains +1 (323) 880-0831 Tucows #MakingTheInternetBetter UTC +5:30 This email originated from outside the firm. Please use caution. _______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org> To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org<mailto:gnso-dnsabuse-pdp-leave@icann.org> This email originated from outside the firm. Please use caution. _______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org> To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org<mailto:gnso-dnsabuse-pdp-leave@icann.org> This email originated from outside the firm. Please use caution.
