Skip to main content
Resources

Community Input and Advice Process

Comment/Reply Periods (*) Important Information Links
Comment Open: 24 September 2012
Comment Close: 25 October 2012
Close Time (UTC): 23:59 UTC Public Comment Announcement
Reply Open: 26 October 2012 To Submit Your Comments (Forum Closed)
Reply Close: 14 November 2012 View Comments Submitted
Close Time (UTC): 23:59 UTC Report of Public Comments
Brief Overview
Originating Organization: ICANN Policy Department
Categories/Tags:
  • Policy Processes
  • Transparency/Accountability
  • Reviews/Improvements
Purpose (Brief): This discussion document is posted at the request of the Board Governance Committee to solicit views from the ICANN community on ways to enhance the process by which the Board seeks advice from the ICANN community beyond the traditional public comment process. This issue stems from the work undertaken by Staff in fulfillment of recommendation No. 6 from the Accountability and Transparency Review Team, and highlights an area where improvements can lead to predictability and consistency for future Board actions. A session is scheduled in Toronto to explore this important issue further.
Current Status: This document is posted for discussion purposes at the Toronto Meeting.
Next Steps: Upon closing of the public comment forum, Staff will post a summary of community input received in Toronto and in this public comment forum. Staff expects to develop a proposal for a streamlined process to be used for the Community Input and Advice Function, for further consideration by the ICANN Community.
Staff Contact: Margie Milam Email: margie.milam@icann.org
Detailed Information
Section I: Description, Explanation, and Purpose

In fulfillment of Accountability and Transparency Review Team (ATRT) Recommendation No. 6, Staff has identified topics that are subject to formal policy development processes, and those that are generally within the ICANN Board level Organizational Administration Function. While Recommendation 6 has been completed, the work performed identified an area in which improvement is required – how the Board obtains the advice that it needs from the ICANN community beyond the traditional public comment process.

The document posted for public comment is intended to guide discussions in Toronto on enhancing the process by which the ICANN Board seeks advice from the community on topics that are not subject to formal policy development processes. It is hoped that these discussions could lead to a consistent and predictable process to be adopted by the ICANN Board for such inquiries.

Section II: Background

ATRT Recommendation No. 6. States that:
"The Board should clarify ... the distinction between issues that are properly subject to ICANN's policy development processes and those matters that are properly within the executive functions performed by the ICANN staff and Board and, as soon as practicable, develop complementary mechanisms for consultation in appropriate circumstances with the relevant SOs and ACs on administrative and executive issues that will be addressed at Board level."

In fulfillment of this Recommendation No. 6, a document was produced that specifically set forth the topics that are subject to policy development processes, and those that are generally within the ICANN Board level Organizational Administration Function. While Recommendation 6 has been completed, the work performed identified an area in which improvement is required – how the Board obtains the advice that it needs from the ICANN community beyond the traditional public comment process. Recently, issues have surfaced where the Board has sought in-depth input or advice from the community, and has specifically requested portions of the community to come together for that purpose.

Through the completion of this work, the BGC identified an area where process improvement will benefit the ICANN community, namely, how the Board seeks community input and advice outside of the formal policy development processes. A brief discussion of some of the hallmarks of this "Community Input & Advice Process" is described in the document posted for public comment. As seen in the rise of cross-community working groups on issues such applicant support in the New gTLD Program, or the Implementation Recommendations Team providing expert guidance on trademark protections, having well-defined mechanisms to provide input and guidance to the Board is necessary.

In Toronto, a working session is scheduled to begin discussions on whether such a mechanism should be formalized to allow for clear understanding of the consultation mechanisms and the issues for which it is helpful to be invoked.

Section III: Document and Resource Links
Section IV: Additional Information

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

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