Changes

==Themes==

==Themes==

===Interacting with Governments===

===Interacting with Governments===

* ICANN [[Executive Team]] Response ([[Mandy Carver]]): [[Engagement#GE|ICANN's Government Engagement]] is growing to meet the need to learn about and give input on DNS-related legislation around the world; this is not the purview of the [[GAC]].  

* ICANN [[Executive Team]] Response ([[Mandy Carver]]): [[Engagement#GE|ICANN's Government Engagement]] is growing to meet the need to learn about and give input on DNS-related legislation around the world, as this is not the purview of the [[GAC]].  

* In the joint ICANN Board-GAC session, the GAC recommended that:

* In the joint ICANN Board-GAC session, the GAC recommended that:

# the board engage in ''less'' formal and ''more'' substantive interactions with the GAC to get more done toward working with governments on geopolitical Internet issues;  

# the board engage in ''less'' formal and ''more'' substantive interactions with the GAC to get more done toward working with governments on geopolitical Internet issues;  

# how to coordinate messaging to governments and IGOS: ICANN's tripartite arrangement (ICANN  Board, Org, and Community) is important but for the purpose of advocacy, it might not be the best model. We should be one in messaging, and unified talking points should be circulated.

# how to coordinate messaging to governments and IGOS: ICANN's tripartite arrangement (ICANN  Board, Org, and Community) is important but for the purpose of advocacy, it might not be the best model. We should be one in messaging, and unified talking points should be circulated.

#  tracking legislation: ICANN should better engage internally and make a hub to access information from all of the ICANN volunteers; figure out who our friends are on [[cybersecurity]], [https://www.europarl.europa.eu/thinktank/en/document.html?reference=EPRS_BRI(2021)689333NIS2 NIS2], and [[Whois]] issues (to help us interpret them); make better use of [[GAC]] member for early warning signs of potential legislation-related issues; stop thinking of GAC as a monolith;  

#  tracking legislation: ICANN should better engage internally and make a hub to access information from all of the ICANN volunteers; figure out who our friends are on [[cybersecurity]], [https://www.europarl.europa.eu/thinktank/en/document.html?reference=EPRS_BRI(2021)689333NIS2 NIS2], and [[Whois]] issues (to help us interpret them); make better use of [[GAC]] member for early warning signs of potential legislation-related issues; stop thinking of GAC as a monolith;  

# GAC members should bring along their cybersecurity, [[Data Privacy]], and Intellectual property office representatives to gain their perspectives earlier, as they offer a clear picture of the balance between commercial and public interests in their nations

# GAC members should bring along their cybersecurity, [[Data Privacy]], and Intellectual property office representatives to gain their perspectives earlier, as they offer a clear picture of the balance between commercial and public interests in their nations; and

# pay more attention to [[ccTLD]] operators to see how they're managing legislation responses

# pay more attention to [[ccTLD]] operators to see how they're managing legislation responses.

===DNS Abuse===

===[[DNS Abuse]]===

* In the public forum, [[Steve DelBianco]] asked the Board if they would support updating contracts to enforce DNS abuse mitigation across the industry. [[Becky Burr]] said [[Contractual Compliance]] believes it has the right tools for right now.  

* In the public forum, [[Steve DelBianco]] asked the Board if they would support updating contracts to enforce DNS abuse mitigation across the industry. [[Becky Burr]] said [[Contractual Compliance]] believes it has the right tools for right now.  

* In the [[NCSG]] membership meeting, [[Theo Geurts]], of [[Realtime Register#RiskReact|RiskReact]], presented a demonstration of [[Realtime Register]]'s DNS abuse monitoring system<ref>[https://realtimeregister.com/blog/security-threat-monitoring-beta/ Security Threat Dashboard, Realtime Register Blog]</ref> and discussed the implications of a couple of significant findings:

* In the [[NCSG]] membership meeting, [[Theo Geurts]], of [[Realtime Register#RiskReact|RiskReact]], presented a demonstration of [[Realtime Register]]'s DNS abuse monitoring system<ref>[https://realtimeregister.com/blog/security-threat-monitoring-beta/ Security Threat Dashboard, Realtime Register Blog]</ref> and discussed the implications of a couple of significant findings:

*# [[Compromised Domain|Hacked websites]] are now overtaking [[Malicious Domain|maliciously registered domains]] in terms of DNS abuse, which limits access to investigative tools and necessary evidence to catch the perpetrators. Regulation flowing down the hierarchy cannot reach this type of activity because the hackers do not provide accurate email addresses, money trails, or registration data. At best, investigators may find something in the payload. In turn, phishing attacks can go unnoticed and unpunished.

*# [[Compromised Domain|Hacked websites]] are now overtaking [[Malicious Domain|maliciously registered domains]] in terms of DNS abuse, which limits access to investigative tools and necessary evidence to catch the perpetrators. Regulation flowing down the hierarchy cannot reach this type of activity because the hackers do not provide accurate email addresses, money trails, or registration data. At best, investigators may find something in the payload. In turn, phishing attacks can go unnoticed and unpunished.

** [[Samaneh Tajalizadehkhoob]] said ICANN's [[OCTO]] is wondering how to choose which [[RBL]] to use because the office is developing a methodology for selecting RBLs, and Theo responded: look at the metrics (where they get their data from, check for alignment with what you are looking for, a large number of hits).

** [[Samaneh Tajalizadehkhoob]] said ICANN's [[OCTO]] is wondering how to choose which [[RBL]] to use because the office is developing a methodology for selecting RBLs, and Theo responded: look at the metrics (where they get their data from, check for alignment with what you are looking for, a large number of hits).

** [[Stephanie Perrin]] explained that much of the activity is not DNS abuse and perhaps not even criminal; so, how do we regulate this realm? ''Theo explained that he only looks at RBLs that focus on DNS Abuse (and [[CSAM]], which is automatically taken down)''. Also, how do we regulate state-sponsored mischief?  

** [[Stephanie Perrin]] explained that much of the activity is not DNS abuse and perhaps not even criminal; so, how do we regulate this realm? Theo explained that he only looks at RBLs that focus on DNS Abuse (and [[CSAM]], which is automatically taken down). Perrin also asked: how do we regulate state-sponsored mischief?  

* In the [[CSG]]-[[ICANN Board]] joint meeting, [[Avri Doria]] explained that the [[CCT]] and [[Second Security, Stability, and Resiliency Review]] (SSR2) generated a significant number of recommendations that address [[DNS Abuse]] and [[DNS Abuse Responses|threat mitigation]] and should be considered together in a comprehensive way to fully understand how [[ICANN]] can approach their implementation.

* In the [[CSG]]-[[ICANN Board]] joint meeting, [[Avri Doria]] explained that the [[CCT]] and [[Second Security, Stability, and Resiliency Review]] (SSR2) generated a significant number of recommendations that address [[DNS Abuse]] and [[DNS Abuse Responses|threat mitigation]] and should be considered together in a comprehensive way to fully understand how [[ICANN]] can approach their implementation.

* [[Trusted Notifier|Trusted Notifier Framework]]

* In the "CPH DNS Abuse Work Group Community Update", [[Keith Drazek]] presented on the [[RySG|Registries]] and [[RrSG|Registrars]] Stakeholder Groups' [[Trusted Notifier Framework]], which is a guide for parties entering [[Trusted Notifier]] arrangements.<ref>[https://rrsg.org/wp-content/uploads/2021/10/Final-CPH-Notifier-Framework-6-October-2021.pdf Trusted Notifier Framework, CPH, RRSG.org]</ref> The framework explains the role, responsibilities, and expectations of Trusted Notifiers.

* [[Interisle]] gave a presentation to the [[BC]] on its [https://www.interisle.net/PhishingLandscape2021.html ''Phishing Landscape 2021''].

* [[Interisle]] gave a presentation to the [[BC]] on its [https://www.interisle.net/PhishingLandscape2021.html ''Phishing Landscape 2021''].

* [[Goran Marby]] pointed to [[DNS Security Facilitation - Technical Study Group]] recommendations as an indication of the 12 steps ICANN could take in [[DNS Abuse Responses|response]] to [[Cybersecurity]] if not directly [[DNS Abuse]]

* [[Goran Marby]] pointed to [[DNS Security Facilitation - Technical Study Group]] recommendations as an indication of the 12 steps ICANN could take in [[DNS Abuse Responses|response]] to [[Cybersecurity]] if not directly [[DNS Abuse]]

* In the ICANN Board and SSAC Joint Meeting, [[Maarten Botterman]] asked [[Geoff Huston]] whether there would be a way to know if the DNS can survive future rounds of additional TLDs and second-level strings. His response:

* In the ICANN Board and SSAC Joint Meeting, [[Maarten Botterman]] asked [[Geoff Huston]] whether there would be a way to know if the DNS can survive future rounds of additional TLDs and second-level strings. His response:

** Sac117 (see also octo-15). Root zone can’t grow infinitely. Is there a way to see whether there will be imminent demise of the dns? We can collect and analyze data about the DNS's behavior/nature but it’s not possible to have an early warning system or no when it will collapse

** Sac117 (see also octo-15). Root zone can’t grow infinitely. Is there a way to see whether there will be imminent demise of the DNS? We can collect and analyze data about the DNS's behavior/nature but it’s not possible to have an early warning system or no when it will collapse

** flattening the DNS solves some technical issues but creates problems around resolving queries for which the hierarchical architecture is better suited; if different labels lead to different behaviors, then we will be in unchartered territory; we've seen a little a bit of this with [[IDN]]s. It will be unpredictable for the entire system

** flattening the DNS solves some technical issues but creates problems around resolving queries for which the hierarchical architecture is better suited; if different labels lead to different behaviors, then we will be in unchartered territory; we've seen a little a bit of this with [[IDN]]s. It will be unpredictable for the entire system

** support for RSAC002, 047 (measuring the DNS)

** support for RSAC002, 047 (measuring the DNS)

** [[Ram Mohan]]: Universal Acceptance is not *really* a technical issue. The biggest challenge is not technology, it is overcoming apathy and lack of care from providers. The various ideas on increasing education and getting governments involved are useful. If governments required UA-Readiness as a pre-requisite to bid in procurements, I suspect we would see an immediate jump in acceptance.

** [[Ram Mohan]]: Universal Acceptance is not *really* a technical issue. The biggest challenge is not technology, it is overcoming apathy and lack of care from providers. The various ideas on increasing education and getting governments involved are useful. If governments required UA-Readiness as a pre-requisite to bid in procurements, I suspect we would see an immediate jump in acceptance.

====IDNs====

====[[IDN]]s====

** [[ccNSO]] updated the GNSO on ccPDP4 on validation and delegation of ccTLD [[IDN]] variants and what triggers IDN ccTLD retirements

** [[ccNSO]] updated the GNSO on ccPDP4 on validation and delegation of ccTLD [[IDN]] variants and what triggers IDN ccTLD retirements

** GNSO held a session on the [[EPDP on Internationalized Domain Names]]

** GNSO held a session on the [[EPDP on Internationalized Domain Names]]

** [[Rod Rasmussen]] (SSAC Chair) responded, 1) SSAD's problems are going to lead to a lack of adoption. 2) ICANN is spending too much time focusing on fixing problems and not enough time on what we want to accomplish, which could be a way forward on unification.

** [[Rod Rasmussen]] (SSAC Chair) responded, 1) SSAD's problems are going to lead to a lack of adoption. 2) ICANN is spending too much time focusing on fixing problems and not enough time on what we want to accomplish, which could be a way forward on unification.

* In the CPH-ICANN Board joint meeting, [[Becky Burr]] pondered whether something could have been done sooner (by the ICANN Board or its liaisons) to foresee issues with [[SSAD]] and consider the implications earlier in the [[PDP]]; this is now the point of the [[ODP]].

* In the CPH-ICANN Board joint meeting, [[Becky Burr]] pondered whether something could have been done sooner (by the ICANN Board or its liaisons) to foresee issues with [[SSAD]] and consider the implications earlier in the [[PDP]]; this is now the point of the [[ODP]].

====ODP====

====[[ODP]]====

[[ICANN Organization]] gave a third update on the progress of the [[SSAD]] [[ODP]], focusing in particular on how legal/natural persons may be verified through a "centralized AA."

[[ICANN Organization]] gave a third update on the progress of the [[SSAD]] [[ODP]], focusing in particular on how legal/natural persons may be verified through a "centralized AA."

* At the ICANN Board-CPH joint meeting, [[Donna Austin]], speaking on behalf of the [[CPH]], explained that volunteers feel disempowered and discouraged because their work is not being implemented in a reasonable timeframe, which she reminded the [[ICANN Board]], goes against the [[ICANN Bylaws]], especially for [[PDP]]s but also [[ICANN Reviews|review]] recommendations. Volunteers may not be up to taking up new work as a consequence. Maybe scoping reviews could limit the number of future recommendations. But in the CPH, concerns remain over the backlog of recommendations sitting with the board, retrospectively applied prioritization, the credibility and legitimacy of ICANN externally and internally, the addition of processes before implementation; the potential for a chilling effect on the [[ICANN Community]]; and the "[[Accountability]] of ICANN" to implement recommendations within a reasonable time frame.

* At the ICANN Board-CPH joint meeting, [[Donna Austin]], speaking on behalf of the [[CPH]], explained that volunteers feel disempowered and discouraged because their work is not being implemented in a reasonable timeframe, which she reminded the [[ICANN Board]], goes against the [[ICANN Bylaws]], especially for [[PDP]]s but also [[ICANN Reviews|review]] recommendations. Volunteers may not be up to taking up new work as a consequence. Maybe scoping reviews could limit the number of future recommendations. But in the CPH, concerns remain over the backlog of recommendations sitting with the board, retrospectively applied prioritization, the credibility and legitimacy of ICANN externally and internally, the addition of processes before implementation; the potential for a chilling effect on the [[ICANN Community]]; and the "[[Accountability]] of ICANN" to implement recommendations within a reasonable time frame.

** [[Matthew Shears]] said the board could offer transparency on what they're doing and that the board is very aware of the sentiment of frustration across ICANN constituencies at the backlog.  

** [[Matthew Shears]] said the board could offer transparency on what they're doing and that the board is very aware of the sentiment of frustration across ICANN constituencies at the backlog.  

** [[Avri Doria]] reported numbers from the [[OEC]] (part of the [[ICANN Organization]]), said there have been 241 recommendations (from [[CCT]], [https://www.icann.org/en/system/files/files/rds-whois2-review-03sep19-en.pdf RDS], [[Third Accountability and Transparency Review|ATRT3]], [[Second Security, Stability, and Resiliency Review|SSR2]], and Work Stream 2 (WS2), of which the board has approved 166 (69%), rejected 18 (7%), placed 44 in pending (18%; [[:Category:ICANN Staff|ICANN staff]] has to research the topics so that the Board can decide), the remaining recommendations (6%) were passed on. This year the board is focusing on the [[Third Accountability and Transparency Review]] and [[Cross Community Working Group on Enhancing ICANN Accountability|Work Stream 2]].  

** [[Avri Doria]] reported numbers from the [[OEC]] (part of the ICANN [[Board Committees]]), explaining the Board had received 241 recommendations (from [[CCT]], [https://www.icann.org/en/system/files/files/rds-whois2-review-03sep19-en.pdf RDS], [[Third Accountability and Transparency Review|ATRT3]], [[Second Security, Stability, and Resiliency Review|SSR2]], and Work Stream 2 (WS2), of which the board has approved 166 (69%), rejected 18 (7%), placed 44 in pending (18%; [[:Category:ICANN Staff|ICANN staff]] has to research the topics so that the Board can decide), the remaining recommendations (6%) were passed on. This year the board is focusing on the [[Third Accountability and Transparency Review]] and [[Cross Community Working Group on Enhancing ICANN Accountability|Work Stream 2]].  

** Donna Austin responded with questions about how long implementing those recommendations will take and is it the community's responsibility to prioritize old recommendations (isn't it an issue with resource management on the part of ICANN org?)

** Donna Austin responded with questions about how long implementing those recommendations will take and is it the community's responsibility to prioritize old recommendations (isn't it an issue with resource management on the part of ICANN org?)

** [[Becky Burr]] said, yes it's on the Org, and thus, the [[Planning]] department has been restructured to resolve these issues.

** [[Becky Burr]] said, yes it's on the Org, and thus, the [[Planning]] department has been restructured to resolve these issues.

===Data Accuracy===

===Data Accuracy===

* The GNSO Council created a Registration Data Accuracy Scoping Team to consider current enforcement and reporting; measurement of accuracy, and effectiveness<ref>[https://community.icann.org/display/gnsocouncilmeetings/Registration+Data+Accuracy+Scoping+Team+-+ICANN72 RDA Scoping Team, GNSO Council Meetings]</ref>; this meeting spent a significant amount of time discussing the [https://www.icann.org/resources/pages/raa-whois-accuracy-2015-11-16-en definition of accuracy] and spent a little bit of time on determining [https://community.icann.org/download/attachments/175244888/Working%20draft%20-%20Discussion%20timeline%20-%20upd%2022%20October%202021.pdf how much time each step will take] to answer whether changes should be recommended to improve accuracy levels; how and by whom they would be developed; and whether existing contractual requirements may necessitate a PDP or contractual negotiations.

* The GNSO Council created a Registration Data Accuracy Scoping Team to consider current enforcement and reporting; measurement of accuracy; and effectiveness<ref>[https://community.icann.org/display/gnsocouncilmeetings/Registration+Data+Accuracy+Scoping+Team+-+ICANN72 RDA Scoping Team, GNSO Council Meetings]</ref>. This meeting spent a significant amount of time discussing the [https://www.icann.org/resources/pages/raa-whois-accuracy-2015-11-16-en definition of accuracy] and spent a little bit of time on determining [https://community.icann.org/download/attachments/175244888/Working%20draft%20-%20Discussion%20timeline%20-%20upd%2022%20October%202021.pdf how much time each step will take] to answer whether changes should be recommended to improve accuracy levels; how and by whom they would be developed; and whether existing contractual requirements may necessitate a PDP or contractual negotiations.

* In the [[GAC]] session called 'GAC Discussion: WHOIS and Data Protection,' [[Laureen Kapin]] led a discussion on the need for validated "operational" accuracy, as opposed to merely syntactical accuracy, in terms of registrants' contact information, as GAC members often represent law enforcement and regulatory bodies.

* In the [[GAC]] session called 'GAC Discussion: WHOIS and Data Protection,' [[Laureen Kapin]] led a discussion on the need for validated "operational" accuracy, as opposed to merely syntactical accuracy, in terms of registrants' contact information, as GAC members often represent law enforcement and regulatory bodies.

===GNSO PDPs===

===[[GNSO]] [[PDP]]s===

====Transfer Policy====

====Transfer Policy====

* The [[Policy Development Process to Review the Transfer Policy|GNSO Transfer Policy Review PDP Working Group]] focused on enhancing security without limiting options for verification

* The [[Policy Development Process to Review the Transfer Policy|GNSO Transfer Policy Review PDP Working Group]] focused on enhancing security without limiting options for verification

# A domain name can experience a discontinuity of DNS resolution and [[DNSSEC]] validation if the transfer of [[:Category:DNS Services|DNS Services]] is not considered during the process.

# A domain name can experience a discontinuity of DNS resolution and [[DNSSEC]] validation if the transfer of [[:Category:DNS Services|DNS Services]] is not considered during the process.

# A domain name is more at risk of being [[Domain Name Hijacking|hijacked]] if the authInfo code is not managed based on best practice security principles.

# A domain name is more at risk of being [[Domain Name Hijacking|hijacked]] if the authInfo code is not managed based on best practice security principles.

====RPM Phase 2====

====[[Rights Protection Mechanisms]] Review Phase 2====

* The [[IPC]] held a discussion on scoping concerns for the [[UDRP]] Review (by [[Susan Payne]]), from [[John McElwaine]]'s email PowerPoint framework to [[GDD]], including reducing the negativity toward the UDRP to reflect the reality of the majority report; making it data-driven (from [[WIPO]], providers, trends for analysis, [[INTA]]); and not starting from scratch. The [[BC]] supports the IPC's concerns.  

* The [[IPC]] held a discussion on scoping concerns for the [[UDRP]] Review (by [[Susan Payne]]), based on a list of suggestions sent by [[John McElwaine]] to [[GDD]], including reducing the negativity toward the UDRP to reflect the reality of the majority report (that it has been a relative success); making it data-driven (from [[WIPO]], providers, trends for analysis, [[INTA]]); and not starting from scratch. The [[BC]] supports the IPC's concerns. Their suggestions included:

**Use [[Consensus Playbook]]  

** Use [[Consensus Playbook]]; and that

**RPM Phase 1 was a disaster, spent too much time on chartering; must do it differently this time ([[Lori Schulman]]), use [[WIPO]] reports as precedent, use data that is already available

** RPM Phase 1 was a disaster, as the WG spent too much time on chartering; the group must do it differently this time (said [[Lori Schulman]]); use [[WIPO]] reports as precedent; and incorporate data that is already available.

==References==

==References==

{{reflist}}

{{reflist}}

[[Category:ICANN Meetings]]

[[Category:ICANN Meetings]]