Skip to main content

Is ICANN Handling Too Many Policy Issues?

Earlier this month, published an article about ICANN’s policy development process. The author, Andrew Allemann, strives for balance but overall leaves the impression that ICANN has “policy overload,” handling too many policy efforts at once. Andrew also cites the technical and complex topics we ask the public to comment upon.

Since I was quoted briefly in the article, I’d like to share some additional thoughts.

Why so much Public Comment?

Public Comment periods are vital in satisfying ICANN’s goal to be a bottom-up multi-stakeholder policy making body and to provide openness and transparency in its policy development processes. An ICANN core value is to employ open and transparent mechanisms in policy development processes. Such openness promotes well-informed decisions, and ensures that people affected by a new policy can participate and assist in the policy’s formation. That’s why the Bylaws mandate public comment periods (for example, see Annex A, Sections 6 and 9).

The Affirmation of Commitments reflects the same principles, calling for ICANN to provide transparent and fact-based policy development, cross-community deliberations, and responsive consultation procedures. In the Affirmation, ICANN committed to provide detailed explanations of the basis for decisions — including how comments have influenced policy considerations.

Thus, the desire to hear all voices on each policy issue comes right from ICANN’s core. Frankly, we don’t want to limit public comments.

Is ICANN handling too many policy processes at the same time?

The answer is “No!” as soon as you consider the alternatives.

Three Supporting Organizations and a number of Advisory Committees can bring policy issues before the community. To which of them would we say, “Sorry, too busy to care about your issue; check back later”? Obviously, none of them.

An ICANN policy development process takes time to gather all viewpoints. Imagine how long it would take ICANN to address your particular policy issue if there were an arbitrary limit. If the ICANN community only handles seven or ten issues at once, that means all other issues remain parked indefinitely, probably for months. Notable achievements from this year, such as IDNs and DNSSEC going into the root, might still be waiting to happen. Do we want to slow our processes? Obviously, no. (Improve and prioritize better? Yes, indeed!)

Andrew reports that “some people” believe there are too many simultaneous policy issues pending, and are worried (with some justification) about overload in our volunteer community. This perception may be due to several factors, including:

• Our list of open issues initially looks confusing because issues have not been prioritized. The GNSO is about halfway through creating a method for prioritizing projects. Ranking their relative importance will help make them easier to take in all at once.
• Many policy-related reports exceed 100 pages. The GNSO has recently resolved that its reports should begin with an Executive Summary. This will help reduce the reading an individual has to do in deciding whether to comment.
• Our large, diverse volunteer community is avid and committed to follow the growing number of policy issues that reflects the increased global impact of the Internet.

We will also be examining the processes and mechanisms we use to manage the public comment process in hopes of identifying more effective and efficient ways to publicize, collect and organize community comments.

Policy development has an ebb and flow. Recently, we seem to be at high tide. Some of the tide will ebb when the new gTLD program launches and GNSO Improvements Initiative winds down. Five working groups will go away (one already has). Optimistically, the bulk of the GNSO improvements effort may be completed in early 2011.

We shouldn’t set an arbitrary limit to the number of issues evaluated by the ICANN Community. The issues arise from the community, and staff works diligently to support that work. We all recognize that many issues are both important and urgent to different parts of the ICANN community. I do not believe that ICANN is handling too many policy issues.

The ICANN community is also working hard to enhance our collective management of so many important issues, which is not always easy. Yet, if the current situation seems difficult, consider the alternative: Further delays in improvements to WHOIS.  The 65% of Internet users who do not speak English await IDNs in their own languages. Communities still waiting more years for their new gTLDs. Phishers continue defrauding consumers using techniques that DNSSEC can stop. If we must err, it is better for ICANN to handle too much, than for ICANN to handle too little.


    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"""" is not an IDN."