Bureaucrats, steward, Administrators, translator
875
edits
Changes
Jump to navigation
Jump to search
mLine 19:
Line 19: − + Line 25:
Line 25: − + + + + + + − + − + + + + + + + + Line 77:
Line 89: − + Line 87:
Line 99: − + Line 98:
Line 110: − + + Line 116:
Line 129: + + − + − + Line 129:
Line 144: − + − + Line 138:
Line 153: − + − + − + − + − * The [[GNSO#GNSO Council|GNSO Council]]
Christiane moved page ICANN 72 - Seattle* to ICANN 72 over redirect: Standardize
==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;
# ICANN establish working procedures and tools for cooperation with governments to review, evaluate, and implement the requirements of national regulations; and
# ICANN establish working procedures and tools for cooperation with governments to review, evaluate, and implement the requirements of national regulations; and
# ICANN encourage multilingual interactions.
# ICANN encourage multilingual interactions.
* In the joint ICANN Board-ALAC meeting, [[Yrjo Lansipuro]] said ALAC can help ICANN reach civil servants at the municipal level especially via [[ALS]]es
* In the joint ICANN Board-ALAC meeting, [[Yrjo Lansipuro]] said ALAC can help ICANN reach civil servants at the municipal level especially via [[ALS]]es.
* In the [[CSG]]-ICANN Board joint meeting, [[Lori Schulman]] and [[Brian King]], both of the ([[IPC]]), offered five pieces of advice:
# 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;
# 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.
===DNS Abuse===
===[[DNS Abuse]]===
* [[Trusted Notifier|Trusted Notifier Framework]]
* 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:
*# 82% of malicious activity is happening at the [[URL]] level, and thus, out of the technical and policy reach of ICANN's contracted parties. Abuse happening at this level falls under the remit of resellers and web hosters.
*# [[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).
** [[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 "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]]
===SSAD===
===SSAD===
On 17 May 2018, the [[ICANN Board]] approved the Temporary Specification for gTLD Registration Data to allow [[CPH|contracted parties]] to [[Contractual Compliance|comply with ICANN contractual]] requirements while also complying with the [[GDPR|European Union's General Data Protection Regulation]], triggering a GNSO Council initiation of a PDP on 19 July 2018. Phase 1 was to confirm the Temporary Specification by 25 May 2019. Phase 2 was chartered to discuss a standardized access model to nonpublic registration data, aka '''SSAD'''.<ref>[https://www.icann.org/en/public-comment/proceeding/initial-report-of-the-expedited-policy-development-process-epdp-on-the-temporary-specification-for-gtld-registration-data-team--phase-2a-03-06-2021 Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A, ICANN Public Comment]</ref>
On 17 May 2018, the [[ICANN Board]] approved the Temporary Specification for gTLD Registration Data to allow [[CPH|contracted parties]] to [[Contractual Compliance|comply with ICANN contractual]] requirements while also complying with the [[GDPR|European Union's General Data Protection Regulation]], triggering a GNSO Council initiation of a PDP on 19 July 2018. Phase 1 was to confirm the Temporary Specification by 25 May 2019. Phase 2 was chartered to discuss a standardized access model to nonpublic registration data, aka [[SSAD]].<ref>[https://www.icann.org/en/public-comment/proceeding/initial-report-of-the-expedited-policy-development-process-epdp-on-the-temporary-specification-for-gtld-registration-data-team--phase-2a-03-06-2021 Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A, ICANN Public Comment]</ref>
* In the public forum, [[Griffin Barnett]] notified the Board that the [[BC]], [[IPC]], the [[NomCom]] appointed representative for the [[NCPH]] did not approve the Phase 2A Final Report at the GNSO Council Vote, because the report does not require differentiation between natural and legal person data processing consistent with the GDPR or publication of a pseudonymized rather than anonymized or web form registrant email (needed to re-enable cross-domain correlation for DNS abuse law enforcement and cybersecurity efforts). [[Mason Cole]] asked why Privacy and Proxy Services Accreditation Implementation ([[PPSAI]]) is being held up by the SSAD ODP. [[Becky Burr]] explained that now it's held up due to [[Prioritization Framework|Prioritization]] in that [[EPDP]] Phase 2A needs to go first.
* [[ALAC]] expressed unhappiness to the [[ICANN Board]] over [[SSAD]] [[ODP]], EPDP phase 2 recommendations, emphasizing SSAD would probably not be worth the cost and would run into trouble with NIS2 when passed.
* [[ALAC]] expressed unhappiness to the [[ICANN Board]] over [[SSAD]] [[ODP]], EPDP phase 2 recommendations, emphasizing SSAD would probably not be worth the cost and would run into trouble with NIS2 when passed.
* The [[BC]] was presented with a model and demo capable of supporting both sides of the SSAD challenge. It provides the verifiable claims to support the evaluation of requests from requesters and allows the logic engine to evaluate the lawfulness of the request, even if the backend remains manual on the [[registrar]] side.
* The [[BC]] was presented with a model and demo capable of supporting both sides of the SSAD challenge. It provides the verifiable claims to support the evaluation of requests from requesters and allows the logic engine to evaluate the lawfulness of the request, even if the backend remains manual on the [[registrar]] side.
** [[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]]====
[[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."
===Prioritization===
===Prioritization===
* ICANN's Office of Planning and Finance presented its plans for developing a [[Prioritization Framework]].
* ICANN's Office of Planning and Finance presented its plans for developing a [[Prioritization Framework]].
* The [[IPC]] is aggrieved, and burned out, that its work is prioritized by the GNSO Council and then de-prioritized as soon as it is passed by the Council; primary example: RPM Phase 1. Deadlines need to be applied to the [[ICANN Board]] and the [[ICANN Organization]] just as they are applied to GNSO Working Groups.<ref>IPC Membership Meeting, ICANN 72</ref>
* The [[IPC]] is aggrieved, and burned out, that its work is prioritized by the GNSO Council and then de-prioritized as soon as it is passed by the Council; primary example: RPM Phase 1. Deadlines need to be applied to the [[ICANN Board]] and the [[ICANN Organization]] just as they are applied to GNSO Working Groups.<ref>IPC Membership Meeting, ICANN 72</ref>
* 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 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, 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]]