Skip to main content

We *are* listening to you – the proof!

One of the most important ways for ICANN to be both transparent and accountable is the public comment period.

ICANN is very unusual as an organisation in that all of its work – even when in draft form – is put out for public review. Unfortunately that review system has been under-used for years. And so we have been trying for several months to make the process simpler, easier and more effective. We produced a set of Consulting Principles to make it clear what the system is, and a single public comment webpage to make it extremely easy to see what was going on at any given time. This has, we are very pleased to note, caused a jump in the quantity and quality of comments.

There are still concerns though. Just last week on this blog, one commenter complained that he didn’t feel there was much point in making a comment, even though we now produce a summary/analysis of comments made to the public comment period and request that the relevant body explicitly discuss that summary when making a decision concerning the subject at issue. The GNSO actually put discussion of the summary/analysis of the new gTLD report on its meeting agenda in September. There was then however some dispute over whether the summary was given the correct attention, which we are reviewing and hope to discuss with the community soon, figuring out the best way forward.

Mailing list provocation

There has also been some responses to a provocative post of mine about why people weren’t replying, in which there was discussion about where ICANN gathers feedback from. As general manager of public participation I am still of the view that ICANN cannot be expected to take any comment made on any one of its mailing lists as a formal response to a particular comment period. The logistics are just impossible. But there is a case to be made for continuing to improve the public comment process with better software, more user-friendly approaches and a greater effort to inform people about comment periods rather than expect people to come to ICANN to find out.

The point of this post however is to highlight the latest summary/analysis for the Draft Management Operating Principles. This summary is, we believe, a very good example of its type. It takes comments not only from the public comment period but also from the public meeting that was held over the principles in San Juan, and it combines them into an easy-to-read summary and analysis that outlines the feedback objectively and with the individuals who provided the feedback credited.

We hope that this is exactly what the community is after. It is alot of work to boil down all this information into an easily readable format and so we would really like to draw your attention to it and ask what people think of it. Does it strike the right note? Is it the right length? Is the approach right do you feel? Say now because this is likely to form the template for future summary/analysis of comment periods.

The next step

And while we are considering how to go forward with public comments, your thoughts on another idea is welcome. We aim to make the summary/analysis as objective as possible because that is the only fair way forward as it treats all equally and equitably and so encourages confidence in the system. However, in the course of going through comments over the past four months, it has become clear that there are occasions in which people simply get their facts wrong, or appear to misunderstand a policy or approach. We want to find a way in which ICANN staff can disagree with a statement, or outline the thinking behind an approach. We don’t think it is appropriate to put that in a summary of comments so we are looking for a different mechanism.

Our current thinking is that a second document be produced by the staff which goes through the summary/analysis from an organisational perspective and then have that document also posted. But we could also have it so that ICANN staff respond to individual comments as and when they crop up (that approach may work better with new interactive forum software we are looking at). It would probably be important that that staff document is itself open to comment so if someone feels that the staff have themselves misunderstood a point, that that dialogue can happen. But then we are also wary of the fact that we don’t want to keep adding endless comment periods to policy processes. Your comments and thoughts welcome.

In the meantime, please do review the summary/analysis for the Draft Management Operating Principles – it is available here and the same thing is attached as a Word document at the bottom.


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