Skip to main content

Budget Discussions at ICANN61

During ICANN61, a major topic of conversation was the FY19 draft Budget and Operating Plan. As you’ve heard from me, 80-85 percent of our budget is already committed to certain projects that are in our Bylaws, our contracts, our operations, and other fixed costs. This means that roughly 15-20 percent of the overall budget can be considered when we are looking at ways to decrease our spending. We must work together to determine the best allocation of the remaining funds, because this is your decision, not mine.

One of the things I greatly appreciated about this meeting was the willingness of our community to look at things differently, to try to think outside the box, and to come up with unexpected ideas.

For example, in Puerto Rico, we talked with the SO/AC leaders who make up the meeting planning group to explore the key drivers of cost and high-level considerations on how we might be able to make ICANN meetings more efficient and effective. Our next step is to supply a more detailed paper outlining options and recommendations for the group to consider.

We also talked a lot about reviews during the meeting, which was a particularly interesting discussion. In the next fiscal year, we have nine reviews running in various stages including a new Accountability & Transparency Review (ATRT3), a continuation of the Registration Directory Services (RDS) Review, and, we expect, the Security, Stability and Resiliency Review 2 (SSR2). Many people are not happy with the high number of reviews because they do not have the time to participate, and raised concerns that for the ATRT3, the Work Stream 2 Accountability recommendations are still being finalized, and for the RDS Review, there is still significant work remaining to address the impacts of the General Data Protection Regulation (GDPR) on the WHOIS system. Delaying either of these reviews would save many hours of volunteer time. Additionally, and more broadly, addressing the timing of reviews, and approach, will contribute to discussing how to make future reviews more efficient and more relevant. Deferring a review that will be impacted by current Policy Development Processes or other outside factors, could have significant savings on productivity and cost. For example, deferring the ATRT3 Review alone would save $700,000 USD, thus impacting next year’s budget.

There were also discussions on staggering or phasing implementation of reviews, changing how certain reviews are conducted (limiting travel, number of review team members, clarity on scope or prioritization of recommendations, etc.), or considering the timing of reviews differently, for example timing the start of the next review based on when the implementation of prior review recommendations is complete. Some of these proposals could require Bylaw changes. These ideas are not about getting around the responsibilities detailed in the Bylaws. I can speak for the org, but I am sure the community and Board would agree, we are committed and accountable to conducting the reviews detailed in the Bylaws, and will work with the community to make any necessary adjustments based on community input and agreement.

I’ve heard many times now, from various members of the community, about the need to and benefit of coordinating the work plans of the Supporting Organizations, Advisory Committees, Board, and org. The aim would be to reduce the number of parallel tracks being worked on, leading to reduced workloads and increased efficiency in developing policies or community recommendations. This coordination could be organized by developing mechanisms to plan together during the development of the next strategic plan.

The ideas stemming from these initial conversations, are just that – initial. It’s important to note that some of the ideas here are inconsistent with the Bylaws, so, if agreed, implementing these ideas may require Bylaw changes.

I am beginning to look at what changes might be made to the cycle of reviews embedded in our Bylaws. I am working with my team to determine the best next steps on this, including holding another public comment period about any changes that might have an effect on either Bylaws or policies. I look forward to your comments on the proposal. Ultimately, it is your decision if you would like to accept any change of the Bylaws. I look forward to working together.

It was good to see so many of you in Puerto Rico and I hope that you had safe travels home. Now, it’s back to work.

Comments

    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."