ICANN 76: Difference between revisions
No edit summary |
No edit summary |
||
Line 48: | Line 48: | ||
*The [[ccNSO]] discussed getting more involved by developing an Internet Governance Liaison<ref>[https://static.sched.com/hosted_files/icann76/9c/TRANSC_I76CUN_Sat11Mar2023_ccNSO-%20Internet%20Governance%20Liaison%20Committee-en.pdf IGLC Session, ICANN 76]</ref> | *The [[ccNSO]] discussed getting more involved by developing an Internet Governance Liaison<ref>[https://static.sched.com/hosted_files/icann76/9c/TRANSC_I76CUN_Sat11Mar2023_ccNSO-%20Internet%20Governance%20Liaison%20Committee-en.pdf IGLC Session, ICANN 76]</ref> | ||
===DNS Abuse=== | ===DNS Abuse=== | ||
====GNSO==== | |||
*The [[CPH]] hosted a [[DNS Abuse]] outreach session that included an update on DNS abuse negotiations, CPH responses to GNSO correspondence on DNS abuse, and upcoming ICANN community work on DNS abuse. | *The [[CPH]] hosted a [[DNS Abuse]] outreach session that included an update on DNS abuse negotiations, CPH responses to GNSO correspondence on DNS abuse, and upcoming ICANN community work on DNS abuse. | ||
*A team of [[Registrar]] and [[Registry]] representatives are negotiating changes to the [[RAA]] and [[Registry Agreement]] (RA) with [[:Category:ICANN Staff|ICANN Staff]]. The revised contractual language will be published for comment by June 2023 (ICANN 77)<ref>[https://opensrs.com/blog/icann76-recap/ ICANN76 Recap, OPENSRS]</ref> | *A team of [[Registrar]] and [[Registry]] representatives are negotiating changes to the [[RAA]] and [[Registry Agreement]] (RA) with [[:Category:ICANN Staff|ICANN Staff]]. The revised contractual language will be published for comment by June 2023 (ICANN 77)<ref>[https://opensrs.com/blog/icann76-recap/ ICANN76 Recap, OPENSRS]</ref> | ||
*The Business Constituency session included a presentation about Whois Extensible Markup Language Application Programming Interface research findings on DNS abuse. | *The Business Constituency session included a presentation about Whois Extensible Markup Language Application Programming Interface research findings on DNS abuse. | ||
====Cross-Community==== | |||
*the ALAC, BC, and IPC sent a joint letter seeking consultation on the DNS abuse negotiations with the Contracted Parties (precedent from 2009 and 2013). ICANN Board said Contracted Parties entered DNS abuse negotiations with a specific scope with ICANN Contractual Compliance for more enforcement tools. ICANN Board will consider conducting a listening session with the ICANN community. | *the ALAC, BC, and IPC sent a joint letter seeking consultation on the DNS abuse negotiations with the Contracted Parties (precedent from 2009 and 2013). ICANN Board said Contracted Parties entered DNS abuse negotiations with a specific scope with ICANN Contractual Compliance for more enforcement tools. ICANN Board will consider conducting a listening session with the ICANN community. | ||
====GAC==== | |||
*The GAC Public Safety Working Group ([[PSWG]]) advocated for improved measures to combat DNS Abuse, explained the importance of [[WHOIS]] data and mitigating DNS Abuse, shared U.K. and U.S. [[cybercrime]] statistics, and updated the GAC on [[DNS Abuse Responses|initiatives]] from the community.<ref>[https://gac.icann.org/contentMigrated/icann76-cancun-communique?language_id=1 ICANN76 Cancun Communique, GAC, ICANN.org]</ref> | |||
*The GAC expressed concerns over the negotiations in relation to Recommendations 14 (ICANN should include provisions in the agreements to provide incentives, including financial incentives for registries, especially open registries, to adopt proactive anti-abuse measures<ref>[https://www.icann.org/en/system/files/files/cct-final-08sep18-en.pdf CCT Review 1 Final Report, pg98]</ref>) and 15 (ICANN should establish thresholds of abuse at which [[Contractual Compliance]] inquiries are automatically triggered, with a higher threshold at which registrars and registries are presumed to be in default of their agreements. If the community determines that ICANN org itself is ill-suited or unable to enforce such provisions, a DNS Abuse Dispute Resolution Policy (DADRP) should be considered as an additional means to enforce policies and deter DNS Security Abuse<ref>[https://www.icann.org/en/system/files/files/cct-final-08sep18-en.pdf CCT Review 1 Final Report, pg99]</ref>) from the [[First Competition, Consumer Trust, and Consumer Choice Review|Competition, Consumer Trust, and Consumer Choice Review]]. | *The GAC expressed concerns over the negotiations in relation to Recommendations 14 (ICANN should include provisions in the agreements to provide incentives, including financial incentives for registries, especially open registries, to adopt proactive anti-abuse measures<ref>[https://www.icann.org/en/system/files/files/cct-final-08sep18-en.pdf CCT Review 1 Final Report, pg98]</ref>) and 15 (ICANN should establish thresholds of abuse at which [[Contractual Compliance]] inquiries are automatically triggered, with a higher threshold at which registrars and registries are presumed to be in default of their agreements. If the community determines that ICANN org itself is ill-suited or unable to enforce such provisions, a DNS Abuse Dispute Resolution Policy (DADRP) should be considered as an additional means to enforce policies and deter DNS Security Abuse<ref>[https://www.icann.org/en/system/files/files/cct-final-08sep18-en.pdf CCT Review 1 Final Report, pg99]</ref>) from the [[First Competition, Consumer Trust, and Consumer Choice Review|Competition, Consumer Trust, and Consumer Choice Review]]. | ||
Line 59: | Line 63: | ||
The GAC Consensus Advice on the [[EPDP for Specific Curative Rights Protections for IGOs]] aka "curative rights" called for a permanent pre-registration notification system. The ICANN Board does not support that approach and proposed an alternative post-registration notification system. The ICANN organization was remiss in delivering that alternative system and the board will consult with the GAC to determine if its curative rights are still consistent.<ref>ICANN76 policy outcome report, published 10 Apr 2023, pgs7-8</ref> | The GAC Consensus Advice on the [[EPDP for Specific Curative Rights Protections for IGOs]] aka "curative rights" called for a permanent pre-registration notification system. The ICANN Board does not support that approach and proposed an alternative post-registration notification system. The ICANN organization was remiss in delivering that alternative system and the board will consult with the GAC to determine if its curative rights are still consistent.<ref>ICANN76 policy outcome report, published 10 Apr 2023, pgs7-8</ref> | ||
===ICANN-Wide Process Improvements=== | ===ICANN-Wide Process Improvements=== | ||
====Work Stream 2==== | |||
The [[HRILWG]] updated the [[GAC]] on the implementation of [[Work Stream 2]] (WS2) Recommendation 1 on diversity, including the work of the WS2 Community Coordination Group (CCG) on developing tools and reminded the GAC to make the Fiscal Year 2024 Additional Budget Request for sign language at [[ICANN Meetings]]. | |||
====Volunteer Appreciation==== | ====Volunteer Appreciation==== | ||
* The [[ALAC]] and [[ICANN Board]] grappled with the ICANN-wide issue of volunteer burnout and how to help volunteers feel appreciated and heard. Ideas included: emeritus status for leaders to ensure support going to newcomers; tools to make engagement in ICANN more accessible and sustainable; and recognizing contributions through travel support tied to emeritus status. ALAC explained that it is having trouble retaining newcomers, despite their use of the [[ICANN Fellow]] Program and subscription features on the ICANN [[Information Transparency Initiative]] Platform. [[ICANN CEO]] [[Sally Costerton]] proposed focused, topic-based engagement on issue tracks. [[RALO]]s and the regional [[GSE|Global Stakeholder Engagement]] are also trying to work better together.<ref>ICANN76 policy outcome report, published 10 Apr 2023, pgs15</ref> | * The [[ALAC]] and [[ICANN Board]] grappled with the ICANN-wide issue of volunteer burnout and how to help volunteers feel appreciated and heard. Ideas included: emeritus status for leaders to ensure support going to newcomers; tools to make engagement in ICANN more accessible and sustainable; and recognizing contributions through travel support tied to emeritus status. ALAC explained that it is having trouble retaining newcomers, despite their use of the [[ICANN Fellow]] Program and subscription features on the ICANN [[Information Transparency Initiative]] Platform. [[ICANN CEO]] [[Sally Costerton]] proposed focused, topic-based engagement on issue tracks. [[RALO]]s and the regional [[GSE|Global Stakeholder Engagement]] are also trying to work better together.<ref>ICANN76 policy outcome report, published 10 Apr 2023, pgs15</ref> | ||
Line 79: | Line 86: | ||
#When should outside expertise be brought in (such as system scoping)? | #When should outside expertise be brought in (such as system scoping)? | ||
#What would have been improved through additional community input without adding to the overall timing? | #What would have been improved through additional community input without adding to the overall timing? | ||
====IRT | ====IRT==== | ||
The ICANN Board asked the [[CPH]] about concrete steps for improving the [[Implementation Review Team]] process. Complexity is often a result of [[PDP]] scoping. The [[RySG]] responded that they plan to: more narrowly tailor their PDPs with a more clearly defined charter, have the early involvement of the ICANN Board and ICANN organization liaisons, include observations from the [[ODA]] during the PDP, and break up the IRT. The [[RrSG]] responded that it would be helpful to have a more regular cadence and detailed agendas for IRT work sessions, include default language for IRT work from the PDP, and escalate issues to the GNSO Council or ICANN Board.<ref>ICANN76 policy outcome report, published 10 Apr 2023, pgs9</ref> | The ICANN Board asked the [[CPH]] about concrete steps for improving the [[Implementation Review Team]] process. Complexity is often a result of [[PDP]] scoping. The [[RySG]] responded that they plan to: more narrowly tailor their PDPs with a more clearly defined charter, have the early involvement of the ICANN Board and ICANN organization liaisons, include observations from the [[ODA]] during the PDP, and break up the IRT. The [[RrSG]] responded that it would be helpful to have a more regular cadence and detailed agendas for IRT work sessions, include default language for IRT work from the PDP, and escalate issues to the GNSO Council or ICANN Board.<ref>ICANN76 policy outcome report, published 10 Apr 2023, pgs9</ref> | ||
====[[:Category:Organizational Reviews|Reviews]]==== | ====[[:Category:Organizational Reviews|Reviews]]==== |