Possible approach to kick off discussions on Associated Domain Checks
Dear Paul, dear colleagues, During our kick-off meeting, Paul emphasized his preference for keeping our discussions short, meaningful, and focused on practical solutions. I think that is a very helpful framing for this PDP, particularly given the breadth of stakeholders participating in this working group, truly a first in the long chain of PDPs I have participated in over the years. In that spirit, I would like to suggest a possible approach for structuring the early phase of our discussions on Associated Domain Checks (ADC) in a more cooperative spirit. One of the realities that I assume we all recognize is that DNS abuse actors frequently operate across multiple registrars, resellers, and TLDs. Because of this, any meaningful approach to detecting and acting on associated abusive domains that is based on individual parties acting on their own will likely fall short of making a meaningful impact and any ultimately successful effort (however we define success) will likely require contributions from multiple actors in the ecosystem. No single party — whether a registrar, registry operator, reporter, injured party or ICANN itself — is likely to have the full set of data, visibility, or operational tools needed to address the issue on its own. At the same time, this PDP brings together a very wide range of stakeholders: contracted parties, the various ICANN stakeholder groups, advisory committees, and even the ccNSO and GAC are represented in a GNSO PDP in an active role for what appears to me the first time. ICANN Org, Compliance, and others also have a role to play. Each of these groups operates under different mandates, capabilities, and constraints but at the same time has a unique view on the issue and unique skills and information that when put together can be bigger than the sum of its parts. Given that diversity, early discussions in policy processes can sometimes gravitate toward defining obligations for others rather than identifying what each participant can realistically contribute to a solution. With Paul’s goal of solution-oriented discussions in mind, I would therefore like to float a simple procedural idea for the first phase of our work that would run in parallel to the already proposed work track. When done right, this proposal would short-circuit our thinning and let us achieve meaningful progress much faster. So, after this lengthy exposition, here is my proposal: During the first month, starting the day we return from Mumbai, each stakeholder group (or constituency, if that is more practical), as well as associated participants, including ICANN org, would be invited to develop a short strawman proposal describing how ADC could work — with one important constraint: the proposal should focus exclusively on what that group itself could bring to the table. In other words, rather than framing proposals around “others should do X,” the framing would be “this is what we could do.” To keep the exercise focused and productive, these strawman proposals would ideally avoid outlining desired outcomes or wish lists for the broader system, and instead remain tightly focused on potential contributions and capabilities of each group of interested parties. The intention would be to achieve three things right off the bat: • Start from capabilities rather than obligations. By identifying what each group can realistically contribute, we may get a clearer picture of the practical building blocks available for ADC approaches. • Encourage a constructive and cooperative tone early in the process. Beginning with “we will” rather than “you must” could help set the stage for collaborative problem-solving instead of prolonged negotiations. • Create a practical map of available tools and data. Once these strawman contributions are on the table, the working group may be better positioned to identify complementarities and develop workable solution models, and potentially bring in third parties to present their capabilities. Importantly, these initial proposals would not bind anyone to a specific policy position. Their purpose would simply be to seed the discussion and help us understand where meaningful contributions might exist across the ecosystem. Some could execute on the work, some could provide valuable information, some could provide overview, some could provide funding for necessary tool development or platform operations. Some will be better placed than others to contribute, and that is natural given the issues we face, but all in all I believe every single group in this ecosystem has something to give that could be a key element in achieving our mutual goal of reducing DNS abuse. If this exercise works as intended, it might allow us to begin the PDP with exactly the kind of focused, solution-oriented discussion Paul encouraged at the outset. Instead of patching catch-up with the criminals, we would coordinate. Instead of pushing them from platform to platform, we would project a unified front against their actions. I would be very interested to hear whether colleagues think this could be a useful way to get the conversation started. Given the unique composition of this group, I believe we are uniquely placed to tackle this issue from a holistic perspective. I do not wish to hijack the conversation, but I think this could be worth our while and might be worth discussing as a basis for our work. I would be very interested to hear whether colleagues think this could be a useful way to get the conversation started, or how to tweak this proposal to make it workable. Best regards, Volker Greimann, RrSG -- Sincerely, Volker Greimann General Counsel - Registrar Division volker.greimann@centralnic.com<mailto:volker.greimann@centralnic.com> Office: +49-172-6367025<tel:+491726367025> Web: www.teaminternet.com<http://www.teaminternet.com> Team Internet Group PLC (AIM:TIG). Registered Office: 4th Floor, Saddlers House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR. Team Internet is a company registered in England and Wales with the company number 8576358.
Paul, Volker and friends Good that we have started thinking the process. I personally feel that 1. We may start discussing inputs from various SOs/ ACs to whome paul and ICANN org have requested. This will give a wholistic view of ICANN community. 2. We may get inputs from Registrars specially those who got impacted on the subject. 3. We may draw boundaries as per charter of PDP and based on initial inputs we receive. We may clearly define our objects and also draw targeted timelines. 4. ICANN has recently suggested operational guidelines for PDPs to operate. I hope we may follow the same. 5. I agree with Paul that our discussions/ consensus/ agreements may be focussed. Anil Kumar Jain On Mon, 9 Mar 2026 at 14:33, Volker Greimann via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> wrote:
Dear Paul, dear colleagues,
During our kick-off meeting, Paul emphasized his preference for keeping our discussions short, meaningful, and focused on practical solutions. I think that is a very helpful framing for this PDP, particularly given the breadth of stakeholders participating in this working group, truly a first in the long chain of PDPs I have participated in over the years.
In that spirit, I would like to suggest a possible approach for structuring the early phase of our discussions on Associated Domain Checks (ADC) in a more cooperative spirit.
One of the realities that I assume we all recognize is that DNS abuse actors frequently operate across multiple registrars, resellers, and TLDs. Because of this, any meaningful approach to detecting and acting on associated abusive domains that is based on individual parties acting on their own will likely fall short of making a meaningful impact and any ultimately successful effort (however we define success) will likely require contributions from multiple actors in the ecosystem. No single party — whether a registrar, registry operator, reporter, injured party or ICANN itself — is likely to have the full set of data, visibility, or operational tools needed to address the issue on its own.
At the same time, this PDP brings together a very wide range of stakeholders: contracted parties, the various ICANN stakeholder groups, advisory committees, and even the ccNSO and GAC are represented in a GNSO PDP in an active role for what appears to me the first time. ICANN Org, Compliance, and others also have a role to play. Each of these groups operates under different mandates, capabilities, and constraints but at the same time has a unique view on the issue and unique skills and information that when put together can be bigger than the sum of its parts.
Given that diversity, early discussions in policy processes can sometimes gravitate toward defining obligations for others rather than identifying what each participant can realistically contribute to a solution.
With Paul’s goal of solution-oriented discussions in mind, I would therefore like to float a simple procedural idea for the first phase of our work that would run in parallel to the already proposed work track. When done right, this proposal would short-circuit our thinning and let us achieve meaningful progress much faster.
So, after this lengthy exposition, here is my proposal:
During the first month, starting the day we return from Mumbai, each stakeholder group (or constituency, if that is more practical), as well as associated participants, including ICANN org, would be invited to develop a short strawman proposal describing how ADC could work — *with one important constraint: *the proposal should focus *exclusively* on what that group itself could bring to the table.
In other words, rather than framing proposals around “others should do X,” the framing would be “*this is what **we** could do.*” To keep the exercise focused and productive, these strawman proposals would ideally avoid outlining desired outcomes or wish lists for the broader system, and instead remain tightly focused on potential contributions and capabilities of each group of interested parties.
The intention would be to achieve three things right off the bat:
• *Start from capabilities rather than obligations.* By identifying what each group can realistically contribute, we may get a clearer picture of the practical building blocks available for ADC approaches.
• *Encourage a constructive and cooperative tone early in the process.* Beginning with “we will” rather than “you must” could help set the stage for collaborative problem-solving instead of prolonged negotiations.
• *Create a practical map of available tools and data.* Once these strawman contributions are on the table, the working group may be better positioned to identify complementarities and develop workable solution models, and potentially bring in third parties to present their capabilities.
Importantly, these initial proposals would not bind anyone to a specific policy position. Their purpose would simply be to seed the discussion and help us understand where meaningful contributions might exist across the ecosystem. Some could execute on the work, some could provide valuable information, some could provide overview, some could provide funding for necessary tool development or platform operations. Some will be better placed than others to contribute, and that is natural given the issues we face, but all in all I believe every single group in this ecosystem has something to give that could be a key element in achieving our mutual goal of reducing DNS abuse.
If this exercise works as intended, it might allow us to begin the PDP with exactly the kind of focused, solution-oriented discussion Paul encouraged at the outset.
Instead of patching catch-up with the criminals, we would coordinate. Instead of pushing them from platform to platform, we would project a unified front against their actions.
I would be very interested to hear whether colleagues think this could be a useful way to get the conversation started. Given the unique composition of this group, I believe we are uniquely placed to tackle this issue from a holistic perspective.
I do not wish to hijack the conversation, but I think this could be worth our while and might be worth discussing as a basis for our work. I would be very interested to hear whether colleagues think this could be a useful way to get the conversation started, or how to tweak this proposal to make it workable.
Best regards, Volker Greimann,
RrSG --
Sincerely,
*Volker Greimann* *General Counsel - Registrar Division*
volker.greimann@centralnic.com Office: +49-172-6367025 <+491726367025> Web: www.teaminternet.com
Team Internet Group PLC (AIM:TIG).
Registered Office: 4th Floor, Saddlers House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR <https://www.google.com/maps/search/44+Gutter+Lane,+London,+United+Kingdom,+E...> .
Team Internet is a company registered in England and Wales with the company number 8576358.
_______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org
participants (2)
-
anil Jain -
Volker Greimann