<div dir="ltr"><div>Dear NCSG members,<br><br>This email is a briefing on the DNS Abuse Mitigation PDP1 Working Group (DNSAM PDP1). It is long <span class="gmail_default" style="font-family:arial,sans-serif">and we are working on another comprehensive doc which we will send soon. But I thought an update email was in order.  </span><br><br><br>WHAT IS THIS PDP ABOUT?<br><br>The DNSAM PDP1 Working Group is developing ICANN policy on Associated Domain Checks (ADCs) - the practice of requiring registrars, when they find one domain<span class="gmail_default" style="font-family:arial,sans-serif"> (this is being contested)</span> in a registrant's portfolio to be abusive, to investigate other domains held by the same registrant. The WG is working through nine Charter Questions (CQs) and will eventually produce an Initial Report followed by a Final Report.<br><br>This is consequential for NCSG. Done right, ADC can be a useful abuse-mitigation tool. Done wrong, it becomes a surveillance mechanism that profiles legitimate registrants based on guilt by association.<br><br><br>TIMELINE<br><br>The WG has meetings scheduled through October 2026. Seville is a progress checkpoint where the WG will conduct lightweight, iterative impact assessments<span class="gmail_default" style="font-family:arial,sans-serif"> (human rights and global public interest along with other convo)</span> - these do not replace the final required assessment. The Initial Report is a post-summer deliverable at the earliest.<br><br>- 26 May 2026: Next WG call (moved to Tuesday due to holiday)<br>- 20-21 May 2026: ICANN86 Prep Week (virtual)<br>- 8-11 June 2026: ICANN86 Seville - 4 DNSAM sessions<br>- Aug-Oct 2026: Continued deliberations, Initial Report drafting<br>- TBD late 2026: Initial Report published for public comment<br><br><br>WHERE THINGS STAND AND OUR POSITION<br><br><br>CQ1 - What triggers an ADC?<br><br>The dominant WG view is that a single confirmed abusive domain is sufficient to trigger a full portfolio investigation. NCSG's position is that ADC should be triggered by a combination of contextual signals, not just one reported domain - blocklist presence, shared infrastructure, registration timing, ties to documented abuse campaigns, prior reports. These signals are publicly available and don't require access to registrar back-end systems. Profiling an entire registrant portfolio from a single abusive domain risks sweeping up legitimate registrants, particularly journalists, activists, and small businesses. This is not about blocking investigation - it's about requiring a threshold of evidence before one confirmed domain unlocks access to everything else a registrant owns. This remains contested and we need to hold this position in CQ7 language.<br><br><br>CQ2 - What defines "association" between domains?<br><br>The WG has generally supported flexibility over a fixed checklist. NCSG agrees with flexibility but wants explicit language that over-broad association criteria require correspondingly stronger supporting evidence before action is taken. Sharing a nameserver or IP address, for example, is a weak signal that could sweep in thousands of unrelated registrants using shared infrastructure. The same criteria should not disadvantage registrants at smaller registrars. We are partially aligned with the WG direction but need to make sure flexibility doesn't become a blank check.<br><br><br>CQ3 - What is a "reasonable investigation"?<br><br>Draft language requires checking at least one internal data point, with the option to use additional technical or abuse intelligence signals. NCSG's position is that the investigation standard must be genuinely proportionate - calibrated to the severity of the suspected abuse, portfolio size, and registrar business model. We object to any language that could be read as requiring or incentivising commercial third-party intelligence feeds (cost, accuracy, and data-sharing concerns). "May use" is acceptable; "should use" or any implied pressure is not. There is also an inconsistency between CQ1 (ADC after mitigation) and CQ3 (ADC before/during/after) that needs to be resolved without expanding registrar investigative power beyond what is necessary.<br><br><br>CQ4 - Data access and privacy safeguards<br><br>The WG is debating whether "strictly necessary" or "reasonably necessary" should govern data use during an ADC. NCSG accepts "reasonably necessary" but wants it clearly linked to the specific investigative purpose, with explicit language that data gathered during an ADC cannot be used for unrelated commercial or enforcement purposes. Existing RAA and <span class="gmail_default" style="font-family:arial,sans-serif"> privacy standards and </span> obligations are the floor - we don't need new retention rules that normalise surveillance of registrant accounts<span class="gmail_default" style="font-family:arial,sans-serif"> and if the data prtection impact assessment finds that the current data protection in RAA is not sufficient we need more data protection</span>.<br><br><br>CQ5 - Remedies for adverse impact on legitimate registrants<br><br>This is <span class="gmail_default" style="font-family:arial,sans-serif"></span>o<span class="gmail_default" style="font-family:arial,sans-serif">ne of our most important issues. </span> WG has acknowledged that ADC processes can harm legitimate registrants through wrongful suspensions and erroneous account-level actions, but has largely characterised recourse as outside the current PDP scope. NCSG's position is that this cannot be left as a footnote. At minimum, the WG must formally refer registrant recourse to GNSO Council as a priority follow-on item with specific language in the Initial Report. We<span class="gmail_default" style="font-family:arial,sans-serif"> might</span> also<span class="gmail_default" style="font-family:arial,sans-serif"> be</span> pursuing a transparency and accountability approach: requiring registrars to report on wrongful suspensions, registrant complaints received, and remedies provided - through ICANN's existing Domain Metrica platform rather than a new mechanism. The goal is to shift incentives from "take down as much as possible" to "take down accurately."<br><br>ACTION ITEM (due before 26 May): NCSG <span class="gmail_default" style="font-family:arial,sans-serif">DNS Abuse </span>members are asked to provide examples of potential adverse impact on legitimate registrants from over-broad ADC. This was specifically requested from NCSG at the 18 May WG meeting. Please send examples to the list or directly to NCSG policy leadership<span class="gmail_default" style="font-family:arial,sans-serif"> if you have some. We advocate for remedy in some shape or form (both at the council and during the WG - perhaps advocate for listing remedies available generally to domain name registrants)</span><br><br><br>CQ6 - Timelines<br><br>The debate is between a fixed 72-hour deadline and the existing RAA "promptly" standard. NCSG's concern is accuracy, not speed. Rushed investigations produce false positives and harm legitimate registrants. We support "promptly" precisely because it allows for contextually appropriate timelines - a sophisticated abuse campaign requires deeper analysis than a simple phishing domain. We should oppose any fixed deadline that creates perverse incentives to act fast rather than act correctly, and should ensure the record reflects that "promptly" does not mean "immediately" in all cases. We are broadly aligned with the WG majority here.<br><br><br>CQ7 - Implementation requirements vs. best practices<br><br>This is where CQ1-6 get drawn together into policy recommendations. The language is being locked in now. NCSG's position is that implementation details should be best practices or advisory guidance (updatable over time), while core obligations - trigger threshold, investigation standard, registrant notification, and recourse referral - must be binding requirements. <span class="gmail_default" style="font-family:arial,sans-serif">We might have to come to a compromise on this issue since remedy, transparency don't gain enough traction even with our allies.</span><br><br><br>CQ8 - Metrics for policy effectiveness<br><br>This has not yet been formally deliberated. NCSG's position is that metrics must measure both effectiveness and <span class="gmail_default" style="font-family:arial,sans-serif"> impact on access </span> - not just how many ADCs were triggered or how many domains were taken down (which incentivises over-removal). Our proposed metrics framework, which we will raise formally when CQ8 comes up:<br><br>- Aggregate ADC checks triggered per registrar (activity)<br>- Abuse types detected through ADC (effectiveness)<br>- Domains actioned vs. cleared - the false positive rate (proportionality)<br>- Wrongful suspensions reported and remedied (accountability)<br>- Time to remedy for wrongful suspensions (registrant protection)<br><br><br><br>CQ9 - How can registrars demonstrate compliance?<br><br>Also not yet formally deliberated. NCSG's position is that compliance evidence must include what happened when things went wrong - wrongful suspensions, complaints received, remedies provided - not just takedown numbers. Any compliance framework should also be transparent to the public at an aggregate level, not only visible to ICANN Compliance.<br><br><br>NCSG'S OVERARCHING HUMAN RIGHTS WORK<br><br>The charter requires the WG to assess human rights impact - whether any recommendations are necessary, proportionate, and legitimate. NCSG has been actively shaping this assessment throughout the deliberations rather than waiting for it to be conducted at the end.<br><br>In practice, our human rights work has taken three forms. First, NCSG has argued - with concrete real-world examples - that triggering a full portfolio investigation from a single abusive domain risks catching civil society actors, journalists, and activists in the net, particularly where their domains touch on politically sensitive topics. The contextual signals approach we have been advocating is itself a proportionality argument: it requires a threshold of evidence before one confirmed domain unlocks access to everything else a registrant owns.<br><br>Second, our push on the recourse gap is a due process argument. Without any notification to registrants that an ADC has been opened on their portfolio, and without any accessible remedy for wrongful suspension, the policy fails the "legitimate" and "proportionate" tests the charter sets out.<br><br>Third, our accountability reporting framework - requiring registrars to report on wrongful suspensions and remedies, not just takedown volumes - is a proportionality argument in practice. It creates a feedback mechanism that makes over-removal visible and therefore costly.<br><br>The groups most at risk that NCSG has identified are: journalists and activists holding domain portfolios; small businesses using shared registrar infrastructure; and registrants in high-risk jurisdictions where government pressure on registrars is a real concern - and where an ADC could be weaponized to expose portfolio information that authorities could then act on.<br><br><br>W<span class="gmail_default" style="font-family:arial,sans-serif"></span>A<span class="gmail_default" style="font-family:arial,sans-serif">NT TO FOLLOW THIS ISSUE?</span><br><br>1. URGENT - before 26 May: Send examples of legitimate registrant harm that could result from over-broad ADC. This is an open action item from the 18 May WG meeting.<br><br><br><span class="gmail_default" style="font-family:arial,sans-serif">2</span>. Attend ICANN86 Seville sessions if you can - 4 DNSAM sessions planned across 8-11 June. Remote participation is available.<br><br><span class="gmail_default" style="font-family:arial,sans-serif">3</span>. Watch for the recourse referral - if CQ7 language does not include a formal Council referral on registrant recourse, we will propose explicit language before the Initial Report is finalised.<br><br><span class="gmail_default" style="font-family:arial,sans-serif">4</span>. Be ready to support the metrics and transparency framework when CQ8 deliberations begin.<br><br><span class="gmail_default" style="font-family:arial,sans-serif"></span>L<span class="gmail_default" style="font-family:arial,sans-serif">et me know if you have any questions. Along with the DNS abuse team at NCSG we are going to send you a report soon. </span><br></div><div><span class="gmail_default" style="font-family:arial,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:arial,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:arial,sans-serif">Best regards, </span></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="verdana, sans-serif">Farzaneh </font></div></div></div></div></div>