ICANN 72: Difference between revisions
Line 123: | Line 123: | ||
* 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." | |||
===Prioritization=== | ===Prioritization=== |
Revision as of 18:25, 11 November 2021
Dates: | Prep Week: October 12-14, 2021
AGM: October 25-28, 2021 |
Location: | Seattle, WA |
Venue: | Virtual |
Website: | ICANN 72 (registration required) |
ICANN 72 was the annual general meeting for 2021, held in October. The meeting was fully virtual in response to the COVID-19 pandemic. The meeting schedule was based on the time zone of the intended host city, Seattle.[1] Note that users must be logged in to their ICANN account in order to view information about meeting sessions, transcripts, and archived video and audio.
Board Composition & Leadership[edit | edit source]
As with every annual general meeting, a number of board members ended their terms of service: Ron da Silva (ASO), Lito Ibarra (NomCom), Merike Käo (SSAC Liaison), and Nigel Roberts (ccNSO) concluded their terms on the board.[2] Alan Barrett (ASO), Edmon Chung (NomCom), James Galvin (SSAC Liaison), and Katrina Sataki (ccNSO) were elected to the board during the organizational meeting.[3]
Themes[edit | edit source]
Interacting with Governments[edit | edit source]
- ICANN Executive Team Response (Mandy Carver): 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.
- 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;
- ICANN invest resources in working more directly with IGF and ITU;
- 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.
- In the joint ICANN Board-ALAC meeting, Yrjo Lansipuro said ALAC can help ICANN reach civil servants at the municipal level especially via ALSes.
- 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, 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
- pay more attention to ccTLD operators to see how they're managing legislation responses
DNS Abuse[edit | edit source]
- 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 threat mitigation and should be considered together in a comprehensive way to fully understand how ICANN can approach their implementation.
- Trusted Notifier Framework
- Interisle gave a presentation to the BC on its 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 response to Cybersecurity if not directly DNS Abuse
- The ccNSO dedicated two sessions to thinking about what role the ccNSO should play in mitigating DNS Abuse.
- In the first session, James Galvin presented on how the CPH approaches DNS Abuse; John Crain gave a nontechnical summary of ICANN's technical view of what the the ccNSO could do based on its remit; Gabriel Andrews gave the PSWG perspective, focusing on ransomware and Domain Generating Algorithms; and Kristof Tuyteleers (.be), Anil Kumar Jain (.in), and Byron Holland, (.ca) discussed how their ccTLDs handle DNS abuse.
- In the second session, the ccNSO discussed and voted on (via a Zoom poll) the 15 recommendations derived from the six presentations made in session 1.
ccNSO Poll on DNS Abuse Advice for ccNSO Council[edit | edit source]
Recommendation | Agree (%) | Disagree (%) | No Opinion (%) | Debated/Discussed (No immediate supermajority) |
Reasoning |
---|---|---|---|---|---|
Share information with ccTLDs and build awareness | 100 | N | |||
Share information with other parts of ICANN | 87 | 2 | 11 | N | |
Consider a best-practice, educational role | 96 | 2 | 2 | N | |
Consider a role for TLD-OPS or similar group | 61 | 12 | 27 | Y | |
Encourage ccTLDs to participate in DAAR | 71 | 13 | 16 | Y | Opposition: ICANN has to re-establish trust with ccTLDs (Stephen Deerhake). Support: DAAR tells you where the problems are (Anil Kumar Jain) |
Support community developed voluntary frameworks | 65 | 15 | 20 | Y | |
Manage expectations about the role of ccTLDs & registrars | 65 | 7 | 28 | Y | |
Create a global database of abused domain names | 33 | 61 | 6 | Y | Opposition: who maintains it, criteria, how long data remains in the database, may be a problem in different parts of the world; instead, we need to share patterns and trends rather than keywords, then there is what to do with the information; transparency issues (Michele Neylon). Support: Bad actors don't work regionally, they work globally (Anil Kumar Jain); second-level names will move from one TLD to another (James Galvin) |
Create co-operations for regular audit mechanisms | 20 | 43 | 37 | Y | |
Remind all stakeholders that ccTLDs are not gTLDs | 86 | 8 | 6 | N | |
Promote that "one size does not fit all" | 89 | 2 | 9 | N | |
Create an Abuse Mitigation Working Group | 65 | 17 | 19 | Y | |
Do NOT focus all efforts on defining DNS Abuse | 78 | 11 | 11 | Y | |
Promote DNS Abuse mitigation initiatives with care | 86 | 2 | 12 | N | |
Develop a voluntary code of conduct for ccTLDs | 62 | 25 | 13 | Y | Opposition: too much regulation, could lead to disparities (Michele Neylon); It won't be voluntary for long (Regis Masse), this is the role of govt not ICANN (Pierre Bonis). Support: Best practices need to be shared and known, and a code of conduct will help each ccTLD be accountable to it (Byron Holland), good self-regulation by an industry is better than govt regulation of industry (Roelof Meijer) |
SubPro[edit | edit source]
In the GAC Discussions on Subsequent Procedures, Karen Lentz explained that a version of the ODP generally happens anyway following the ICANN Board's reviewing of a Consensus Policy; now it has just been formalized. Likewise, the funding is not outside of what is already happening; rather, it reflects processes that are or would happen as ICANN Organization determined next steps toward implementation (or not).
There were several discussions around incorporating responses to DNS Abuse into the Contractual Compliance obligations of the next round.
- 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
- 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 IDNs. It will be unpredictable for the entire system
- support for RSAC002, 047 (measuring the DNS)
Universal Acceptance[edit | edit source]
- DNS Women held a session on where UA is today, led by Vanda Scartezini and Mark Datysgeld, the main thrust of which was to encourage more and better awareness-raising and outreach in order to acquire new stakeholders.
- Maria Kolesnikova: Key issues are outreach and buy-in to UA readiness; the research is there, but the broad push to incorporate new and different stakeholders is not. UASG needs to reach out to regional influencers for software developers in particular
- Jim DeLaHunt: There is an economic explanation for poor Universal Acceptance. It is the "supply-demand paradox." Suppliers of software and website do not do the work and expense for Universal Acceptance because the users do not use international domain names and email addresses. Users do not use international domain names and email addresses because the software and websites won't accept them. This economic obstacle needs an economic strategy to overcome it.
- 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[edit | edit source]
- 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
- Key topics:
- IDN tables, confusing similarity, and IDN implementation Guidelines - will they now apply to both ccTLDs and gTLDs?
- will the tables be publicized for second-level strings too?
- ICANN Board is asking GNSO to expedite the Guidelines item for security reasons[4]
- interaction with SUBPRO, especially for challenges over validation because not supported by RZ-LGR
- can we assume that label requirements will be built into the algorithmic check in the next round of applications' submission system?
- Key topics:
SSAD[edit | edit source]
On 17 May 2018, the ICANN Board approved the Temporary Specification for gTLD Registration Data to allow contracted parties to comply with ICANN contractual requirements while also complying with the 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.[5]
- 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.
- In the SSAC Public Meeting, Steve Crocker presented a summary of SAC118's three recommendations.[6]
- The GNSO and ICANN Organization should focus on building and operating a timely, reliable, effective, and efficient differentiated access system for competing interests.
- to address issues around legal/natural personal registration data:
- There should be a data element to denote the legal status of the registrant, which can be displayed as publicly available data;
- at the time of new domain registration, registrars should be required to classify all registrants as natural or legal persons;
- Registrants should continue to have the option of making their contact data publicly available; and
- Legal person registrants should be able to protect their data via privacy and proxy services.
- On Pseudonymizing Email Contacts:
- separate the ability to quickly, effectively contact registrants without disclosing personal data from helping investigators correlate registrations with contact information;
- registrars should support registrant-based email contact and develop safeguard requirements for them;
- EPDP Phase 2A should not specify a method for correlating registrations with contact information
- In the ICANN Board-SSAC Joint Meeting, Becky Burr clarified that the SSAD will deliver one thing alone: a single, unified intake system. It will not be predictable and uniform in terms of out products, because it will continue to be up to registrars what the GDPR means to them.
- Steve Crocker responded, "SSAD should be stopped cold now. It is not fit for purpose...Back up and start over."
- 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.
ODP[edit | edit source]
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[edit | edit source]
- 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.[7]
- 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 PDPs but also 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.
- Avri Doria reported numbers from the OEC (part of the ICANN Organization), said there have been 241 recommendations (from CCT, RDS, ATRT3, SSR2, and Work Stream 2 (WS2), of which the board has approved 166 (69%), rejected 18 (7%), placed 44 in pending (18%; 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 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?)
- Becky Burr said, yes it's on the Org, and thus, the Planning department has been restructured to resolve these issues.
- Samantha Demetriou expressed concern over the handling of Rights Protection Mechanisms recommendations, as PDP outcomes are of special interest to the contracted party house, to which Goran Marby responded that transparency slows down the process but makes ICANN decisions and implementation more deliberate.
- Donna Austin said that the ICANN Community is losing faith in ICANN's Multistakeholder Model because there is so much friction and there are so many people paid to show up at this point; Sam responded that we don't have to throw out the model; maybe not doing things sequentially and instead doing things concurrently (perhaps via liaisons) earlier in the process could reduce delays
Data Accuracy[edit | edit source]
- The GNSO Council created a Registration Data Accuracy Scoping Team to consider current enforcement and reporting; measurement of accuracy, and effectiveness[8]; this meeting spent a significant amount of time discussing the definition of accuracy and spent a little bit of time on determining 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.
GNSO PDPs[edit | edit source]
Transfer Policy[edit | edit source]
- The GNSO Transfer Policy Review PDP Working Group focused on enhancing security without limiting options for verification
- In the SSAC Public Meeting, Steve Crocker presented SAC119, which concerns two security risks:
- A domain name can experience a discontinuity of DNS resolution and DNSSEC validation if the transfer of DNS Services is not considered during the process.
- A domain name is more at risk of being hijacked if the authInfo code is not managed based on best practice security principles.
RPM Phase 2[edit | edit source]
- 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.
- Use Consensus Playbook
- 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
References[edit | edit source]
- ↑ ICANN 72 Event Site (registration required)
- ↑ ICANN.org Blog - Preview of ICANN 72, by Maarten Botterman, October 20, 2021
- ↑ ICANN 72 Archive - Annual General Meeting of the Board, October 28, 2021
- ↑ GNSO EPDP on IDNs Meeting, ICANN 72
- ↑ Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A, ICANN Public Comment
- ↑ SSAC Public Meeting, ICANN 72, Oct 26, 2021
- ↑ IPC Membership Meeting, ICANN 72
- ↑ RDA Scoping Team, GNSO Council Meetings