Skip to main content

Evolving ICANN’s Multistakeholder Model: The Work Plan and Way Forward

Over the years, ICANN’s multistakeholder model (MSM) has evolved, addressed important issues, and developed policies for the Internet’s domain name and numbering resources. During the development of ICANN’s Strategic Plan for Fiscal Years 2021-2025, the ICANN community raised a number of challenges concerning its effectiveness, efficiency, and overall functioning. That community feedback was the basis for development of the strategic objective on governance, which led to the Evolving ICANN’s MSM process.

Why Is This Work Important?

The Evolving ICANN’s MSM process asked the ICANN community to identify specific work processes, working methods, and culture issues that are hampering the more effective functioning of the multistakeholder model. The process focused on two deliverables that were to be developed through community comment and feedback: an issues list and a work plan. The work plan was developed and presented in draft form to the community at ICANN66. It has now been published as part of the Draft FY21-25 Operating and Financial Plan, as an annex to that document. The work plan proposes six workstreams that will create solutions to address the issues identified in this process.

The ICANN community already has a significant workload and the work plan could be viewed as just another task for the ICANN community to manage. However, this work plan has a unique purpose: To improve the way the ICANN community gets its work done. There is work underway in other community workstreams to improve certain aspects of the functioning of ICANN’s multistakeholder model. This work plan aims to create complementary and targeted solutions to the issues identified in the Evolving ICANN’s MSM process. Those issues include: the continuing accumulation of workstreams that stretch ICANN’s finite volunteer and financial resources in ways that are becoming unsustainable; the difficulties in efficiently achieving consensus and the resulting delays in delivering policies and other community work; and the silo mentality that has become a cultural norm driving stakeholder behavior in ways that frustrate greater efficiency and effectiveness.

This work plan offers the prospect of creating additional tools or approaches to more effectively prioritize, more swiftly achieve compromise and consensus, and more constructively engage across stakeholder groups. This is not to suggest that this work is somehow more important than other work currently underway, nor that there aren’t other important workstreams underway. The nature of this work is unique and critical. Going forward, this work plan should be informed by the other work underway, as well as supported and prioritized by the ICANN community, Board, and org.

The Work Plan and the Process

I would like to share some observations with you about the process and the work product. The presentation of the work plan at ICANN66 and the incorporation of community feedback marks the end of the facilitated phase of this process. Beginning at ICANN64, the facilitated process culminated at ICANN66. Over that seven-month period, the process included three facilitated face-to-face meetings with the community, six webinars, and several face-to-face meetings and calls with ICANN community stakeholder groups at their request. All of those interactions were documented, summarized, and posted online.

The first deliverable, an issues list, was created based on community discussion at ICANN64 and two subsequent requests for Public Comment launched in April and August 2019. Based on the feedback from those Public Comment periods and community conversations, I consolidated, prioritized, and merged the issues into what became the final issues list. As the issues list evolved, it was striking to observe how similarly different stakeholders described the issues. That suggests a community-wide, shared recognition of the problems to be addressed and lends a solidity to the final issues list.

Inviting the community to create a work plan was a bit trickier. First, the work plan would create new workstreams, even though important work that might address the issues was already underway. Given the current workload, I anticipated there may be some reluctance or resistance, and understood the need to balance this process against other work. Second, I asked the community to identify which entities (e.g., the entire ICANN community, Supporting Organizations, Advisory Committees, ICANN Board, or org) should take on the task of developing a solution (or solutions). This is still an area for further discussion. I realized that natural tendencies in a multistakeholder community might lead to resistance from some stakeholders to the suggestion that others take on the task of developing a solution. There could be concern that the stakeholder tasked to develop a solution would do so in a way that serves its interests as opposed to the interests of the broader ICANN community.

The facilitated conversations at ICANN64, ICANN65, and ICANN66 were an opportunity to bring diverse community stakeholders together to collectively identify challenges and create the basis for solutions to those challenges. Stakeholders across the community have different motivations, differing views of how the ICANN multistakeholder model should best function, and, in some cases, different experience with certain issues. Issue identification and creating a work plan is challenging work, yet the community engaged in conversations with constructive energy and candor. The tone was engaged, positive, sometimes critical, and the comments offered helped to create the issues list and the proposed work plan, which is now out for Public Comment.

Next Steps

As noted, the proposed work plan is included in ICANN’s Draft FY21-25 Operating and Financial Plan. This provides the community an opportunity to comment on and shape the final work plan, setting the stage for the process of creating solutions. The next stage of this work will require coordination and collaboration between the ICANN community, org, and Board. The entities offering to help to develop solutions will have to engage with each other (e.g., ICANN org and Board) to address prioritization of the respective workstreams, create project plans, ensure coordination with existing work underway, finalize resources needed, identify gaps, and create timelines to develop and propose solutions.

As the work moves forward, specific dependencies will need to be managed. The work plan identified GNSO PDP 3.0, ICANN’s third Accountability and Transparency Review (ATRT3), and the Cross-Community Working Group-Accountability (also known as Work Stream 2) as dependencies because they have delivered or are developing recommendations that are relevant to issues in the work plan. Additionally, the ICANN Board recently published a draft proposal for Resourcing and Prioritization of Community Recommendations. This draft proposal is relevant to the workstream on prioritization and efficient use of resources.

I have little doubt that the ICANN community, Board, and org will come together to create the tools and solutions that can make ICANN’s multistakeholder model more effective and efficient. Throughout the community engagement process, the ICANN community stakeholders always leaned into the conversations with the intention of moving forward even when the subject matter or tasks became more challenging. It was a pleasure and a privilege to collaborate with such a committed and passionate community to develop the work plan and set the stage to create improvements to ICANN’s processes, methods, and culture.

Comments

    Wayne White  21:08 UTC on 30 December 2019

    Nice Blog

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."