Skip to main content

Sharing a Plan for Public Comment Improvements

The Policy Development Support Staff recently assumed day-to-day oversight of ICANN's public comment infrastructure. This responsibility includes coordinating, evaluating, developing and implementing targeted improvements to all of ICANN's community input and feedback mechanisms.

The team has spent considerable time reviewing the existing public comment infrastructure, processes, and procedures and gathering data on community activity to determine what changes inspired by the original ATRT1 recommendations have been effective.

In conjunction with those efforts as well as the recent ATRT2 recommendations being reviewed by the Board, the Staff has been working over the past several weeks to develop a public comments improvement implementation plan. This effort builds on previous feedback from community leaders that identified a number of potential areas for public comment improvements. The plan has been shared with members of the Board of Directors who have encouraged us to move forward with it.

The team expects to move forward with the implementation of specific short-term process improvements after the ICANN Public Meeting in London (ICANN 50). Those short-term changes will be evaluated for their effectiveness after six months while longer-term improvements are developed.

Immediate Short-term Improvements to be Implemented

The immediate improvements to be implemented after the London meeting include:

  • The reply comment phase of public comment forums will be eliminated. Data evaluation and community feedback confirm that this experiment inspired by the ATRT1 recommendations has not been effective.

  • Staff will establish a standardized schedule for the opening of future public comment periods at regular intervals. We intend to open public comment periods on an established monthly schedule - likely two times a month (e.g., first Monday and third Monday of every month). It is hoped that this will enable the various ICANN communities and their members to better organize their work.

  • Expectations will be established and enforced among ICANN staff to ensure prompt creation of post-public comment period summary reports. Compliance with these new processes will be rigorously managed and metrics recorded.

  • A process for community complaints about summary report content and mechanisms for corrections will be instituted.

  • ICANN will return to a minimum comment period format. For the next six months (after the new processes are implemented) the default minimum comment period will be 40 days.

The team will publicize these changes to the community and conduct webinar presentations about the expected new processes and procedures before they are implemented. The likely implementation date is the end of July 2014 – thus the new processes will apply to all new public comment forums opened after that implementation date.

Longer-Term Improvements Under Consideration and Development

In partnership with our online communications colleagues, longer-term improvements to the public comment infrastructure are currently under development as we look for ways to leverage new technologies and the web site capabilities. As the team identifies those opportunities and makes recommendations, we will consult with the community for input and feedback.

The public comment process is a critical component of the bottom-up, consensus-driven policy development processes in ICANN's multistakeholder model and we appreciate all the feedback we've collected so far. I look forward to discussing these upcoming process changes with you during the London meeting and hope that, together, we will identify new areas for continuing improvements to our processes for seeking, receiving and acting on community input. Please reach out to me, Rob Hoggarth or Carlos Reyes when you see us in London.


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