Page History

ALAC-GNSO Council Bilateral Session during ICANN75 on 21 Sep 2022

• Agenda
• Meeting Record
• Summary

ALAC-GNSO Council Bilateral Session during ICANN75 on 21 Sep 2022

The ALAC and the GNSO Council will meet during ICANN 75 to discuss two issues of mutual interest.

Draft Agenda:

1. Introduction and Housekeeping - Staff 
2. Welcome - Maureen Hilyard, ALAC Chair and Sebastien Ducos, Incoming GNSO Chair) (remote) 
3. Introduction to Topics - Justine Chew (ALAC Liaison to the GNSO)

a. DNS Abuse 
- Update by GNSO Council Small Team on DNS Abuse Co-Chairs Mark Datysgeld & Paul McGrady 
- Open discussion

b. Operational Design Phase (ODP) 
- Observations and open discussion on the ODP concept based on experiences with the SSAD ODP and SubPro ODP (composition, effectiveness, challenges, improvements etc) 

4. Closing remarks - Justine Chew 

For notes, click on SUMMARY tab above

Records of Bilateral Session at ICANN75 on 21 Sep 2022

• Zoom Webinar Archive
• English audio archive
• Archive audio en français
• Archivo de audio en español

ALAC-GNSO Council Bilateral Session during ICANN75 on 21 Sep 2022

Re: DNS Abuse Mitigation

• GNSO Council Small Team on DNS Abuse acknowledged and thanked ALAC for input/response to the Small Team's limited outreach exercise; in particular the ALAC's comment regarding consideration of DNS abuse preventive measures, specifically on the possible use of predictive analysis for purpose of identifying and halting abusive DN registrations and promotion of Know-Your-Customer (KYC) as good general practice for Contracted Parties, especially in relation to bulk registrations.
• At this point the Small Team's draft report and recommendations are still subject to GNSO Council's consideration/decision (at its Oct 2022 meeting), in brief, the Council Small Team have structured inputs received through the outreach exercise to identify potential mitigation steps across 5 phases of the DNS abuse life cycles, being:
  • Phase 0 - measures to help CPs identify DNS abuse earlier or even prevent a malicious registration
  • Phase 1 - ensuring harmed parties know how AND to whom a complaint should be reported
  • Phase 2 - report should be well-formed and actionable
  • Phase 3 - well-positioned party (CPs, but could also be web-host, website owner/operator, etc) takes action
  • Phase 4 - enforcement by ICANN compliance, where best positioned party is a CP
• As for the draft recommendations, these are: (with important context contained in the draft report):
  • DNS Abuse targeted by Small Team is as what has been generally adopted by CPs in order to progress work on combating abuse and not to be bogged down by re-defining DNS Abuse.
  • 3 buckets of 'Policy', 'Outreach', 'Contractual Negotiation' are not mutually exclusive and nothing prevents the pursuit of an issue via more than one path, but still all potential in nature.
  • Recommendation #1 - Malicious Registrations (Phase: 0,3,4; Bucket: potentially, tightly focused policy development)
    After the community has been able to process the community outreach and other suggestions made in this report, if further tools are considered necessary, the small team recommends that the Council  considers requesting the development of a Preliminary Issue Report on the topic of malicious registrations. The objective is to prepare the ground for tightly scoped policy development that would consider malicious registrations used for the distribution of malware, phishing or the operation of Botnet command and control systems. The goal of the tightly scoped policy would be to explore whether it is possible to identify indicators of malicious registrations that would trigger actions from Contracted Parties either at the time of registration or shortly after. Any policy development is expected to anticipate that the theme of malicious registrations may not be as clear cut in practice. As such, care must be taken that any proposed measures are balanced and proportional.
  • Recommendation #2 - Bulk Registrations (based on ALAC's submission) (Phase: 0; Bucket: community outreach)
    The small team recommends that the GNSO Council requests the Registrar Stakeholder Group and others (for example, ICANN org and the DNSAI) to further explore the role that bulk registrations play in DNS Abuse as well as measures that Registrars may have already put in place to address this vector. Based on the feedback received, the GNSO Council will consider whether further action on bulk registrations is deemed necessary.
  • Recommendation #3 - DNS Abuse Reporting (Phase: 1,2; Bucket: community outreach)
    With an eye towards outreach, the small team recommends that the Council encourages continued discussion between Contracted Parties and DNS Abuse reporters/potential reporters with the goal of further fine-tuning and promoting existing tools and initiatives, and/or those under development, to further work towards easier, better and actionable reporting of DNS Abuse. Take into consideration additional pipelines that might be helpful.
  • Recommendation #4 - Action & Enforcement (Phase: 3,4; Bucket: community outreach, contract negotiation)
    The small team recommends that the Council reaches out to the RrSG and RySG to share the findings of the small team and requests feedback on how these potential gaps can be best addressed. In addition, this letter should request that Contracted Parties initiate work on the “Suggested Standards” document , in consultation with ICANN Compliance. Based on the feedback received to this letter, the Council will determine next steps, but at a minimum, the Council would expect to be kept up to date on any further work that would be undertaken by Contracted Parties in consultation with ICANN Compliance.
• ALAC/At-Large comments: Must acknowledge that DNS Abuse landscape could and probably would evolve over time, so must ensure definition of "DNS Abuse" can still evolve.

Re: Operational Design Phase (ODP) Concept

• Preliminary GNSO Council discussion appears to reveal an early general opinion that while the ODP has been useful in practice - specifically the SubPro ODP but less so with the SSAD ODP - but that much of the work undertaken during the ODP should be done much earlier, either during the policy development process (PDP), or very shortly after the PDP. This could potentially be achieved by having ICANN org's Global & Domain Strategy send a liaison to each PDPs or WGs to provide input, on a rolling basis, on feasibility, costs etc.
• It is opined that the SSAD ODP presented more weaknesses and offered less consultation, than the SubPro ODP.