Dear DNSAM PDP 1, Please see the attached outcomes, action items, and notes from Meeting #6. Best, Steve [OUTCOMES] * Nick Wenban-Smith elected vice-chair [ACTION ITEMS] * Staff to post election results and onboard Nick to the leadership team. * Leadership and staff to provide a path forward for the WG meeting schedule, taking into account Monday holidays. * WG members to provide further input on the proposed updated work plan, no later than 3 April [updated work plan attached]. * Jennifer Chung, as Council liaison to the WG, to submit work plan to the Council no later than 6 April. [NOTES] 1. Welcome * None 2. Update on VC Chair Selection * Nick Wenban-Smith elected vice-chair Action Item: Staff to post election results and onboard Nick to the leadership team. 3. Meeting Cadence/Public Holidays * With so many meetings on Monday, leadership is proposing to move the meetings to the second most common acceptable day based on Doodle poll results. * Suggestion from many to leave on Monday and only move to Tuesday if there are “enough” WG members that cannot attend, but don’t cancel. Action Item: Leadership and staff to provide a path forward for the WG meeting schedule, taking into account Monday holidays. 4. Update on Workplan * Leaders and staff have taken into consideration input and has suggested changes to shorten the timeline. Key changes are initial deliberations and time between Initial and Final Report. Some appreciation, but also some discomfort for the shortened work plan. * The initial proposal for the work plan was potentially too conservative; the updated work plan is still designed to be achievable. * Next step is for the work plan to go to Council for acknowledgement via the Council liaison, Jennifer Chung. Action Item: WG members to provide further input on the proposed updated work plan, no later than 3 April [updated work plan attached]. Action Item: Jennifer Chung, as Council liaison to the WG, to submit work plan to the Council no later than 6 April. 5. Continue Deliberation * Early input received from the BC, GAC, IPC, ISPCP, NCSG, RrSG – input is aggregated and stored on the Wiki. Each piece of input will be added into the collaboration tool, relative to the Charter question. * Reviewed Overarching Themes so far from WG discussions, both verbal and on email. Also included relevant sections from Early Input, though full comments should be reviewed on the Wiki: https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/983433230/Comm... * Concern that if the trigger requires action every single time, it represents costs and efforts for the registrars, impacting the ability of registrars to effectively combat DNS Abuse. Noted that we still have a question to determine what the investigation will look like. * Suggestion/reminder to define a maliciously registered domain name based on RAA 3.18.2. * “When Registrar has actionable evidence that a Registered Name sponsored by Registrar is being used for DNS Abuse, Registrar must promptly take the appropriate mitigation action(s) that are reasonably necessary to stop, or otherwise disrupt, the Registered Name from being used for DNS Abuse.” * Reminder that we need to allow for some flexibility in the solutions as bad actors will change their methods. However, the requirements still ultimately need to be enforceable. * The GAC early input talks about how to perform the ADC, as in what represents association – this input connects to a later Charter question. We are blending the charter questions a bit. * If the trigger is not a single maliciously registered domain name based on RAA 3.18.2, what would be the alternative? * Caution from some to avoid listing all ways to identify associated domain names engaging in DNS Abuse as defined by 3.18.2. * Question about proportionality in respect of initial trigger versus ADC – answer from those that are particularly concerned about proportionality, is both. * Reminder from ISPCP early input that the ADC should also be based on the same standard as in 3.18.2. Are there any members suggesting to go beyond these limitations? Seems to be alignment to stick with the RAA definition. * A balance is needed to avoid listing every ADC action, but also not to leave so vague that bad actors can exploit the holes. * Several mentions of a “reasonableness” standard for the ADC, in terms of what needs to be looked at. Continued caution against creating a prescriptive matrix. * Suggestion to create an advisory to help guide what the ADC should include, which can be updated from time to time. Question about how advisories are updated – answer is that there are a multitude of ways to update advisories. * Several members reminded that proportionality is important. However, question about potential harms from investigating whether other DNS Abuse is occurring. * Noted that reasonableness is already a component of the RAA, including for RAA 3.18.2. There is a difference between “what” reasonableness represents for initial trigger versus the reasonableness of “how” the ADC is performed. The advisory notion is more relevant to the latter of “how”. * Some discussion about compromised domains, which are not within scope of this PDP. Question about whether a compromised domain should trigger investigation of the account. * We have not yet discussed what the ADC itself should involve, other than it should not be prescriptive. This aspect is when proportionality will be more relevant. * Reasonableness of the ADC will vary based on the circumstances. And question about how that should be passed on to the reseller. 6. AOB * Planning to have 4 sessions during the standard meetings days for ICANN86. Will try to avoid conflicts to the extent possible. * There will also be a prep-week webinar to provide an update on the progress of this PDP. * Will need to confirm work plan – get it to Council by the 6th. * Staff will continue to update the collaboration tool and the WG should continue to review and provide feedback. Steven Chan VP, Policy Development Support & GNSO Relations Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 Email: steve.chan@icann.org<mailto:steve.chan@icann.org> Mobile: +1.310.339.4410