Skip to main content
Resources

Operational Design Phase

About the Operational Design Phase (ODP)

Development of the Operational Design Phase (ODP)

Operational Design Phase Frequently Asked Questions (FAQs)

Active ODPs

Closed ODPs

About the Operational Design Phase

Click here to read the Operational Design Phase process paper.

The purpose of the Operational Design Phase (ODP) is to perform an assessment of Generic Names Supporting Organization (GNSO) Council policy recommendations, or other ICANN community-provided recommendations the Board deems appropriate, in order to provide the Board with relevant information for its deliberations on whether to approve said recommendations. The ODP Process Paper, linked above, guides the ODP process. Specific to the GNSO Consensus Policy, the ODP improves upon existing processes within the Consensus Policy Implementation Framework (CPIF) by adding additional transparency and structure to the work the ICANN org performs to assess the operational impact of GNSO Council-approved recommendations.

An ODP will be initiated by the Board in cases where the Board identifies that the GNSO policy recommendations, based on their complexity and potential operational impact, warrant such an assessment. A Board request for an ODP directs ICANN org to perform an operational analysis of a given set of GNSO policy recommendations. The ICANN org performs its analysis based on a Board-determined scope and provides the Board with an Operational Design Assessment (ODA), the expected output of the ODP, within a specified timeframe. Once completed, the ICANN org will submit the Operational Design Assessment to the Board for its consideration. In addition to other relevant materials, such as the recommendations themselves and the Bylaws-mandated Public Comment proceeding on the recommendations, the ODA will help the Board decide whether it believes the recommendations are in the best interests of ICANN community or ICANN.

While it is ICANN org that conducts the ODP, ICANN community feedback plays an important role in the process. Throughout the ODP, ICANN org will provide periodic updates on its progress. Progress updates will be provided via a number of platforms, including the icann.org website, webinars, blogs, and dedicated sessions during ICANN meetings, to offer the ICANN community opportunities to ask questions, seek clarification, and provide general feedback. In addition to these progress updates, once ICANN org has reached relevant milestones in its ODP work, it will report its progress to the ICANN community to provide visibility and to seek input on the facts, figures, and assumptions that underpin its analysis. All updates will take place transparently to ensure the ICANN community, Board, and org are aware of the different inputs provided. It is important to note that ICANN community input — like any other part of the ODP — is not a forum to reopen questions settled during the policy development process. Should any questions that pertain to policy arise during the ODP, these will be referred to the GNSO Council, which is encouraged to appoint an ODP liaison to assist in these communications.

More information about the ODP's purpose and how it is conducted is detailed in the Operational Design Phase - Process Paper. While the paper is authoritative in describing the ODP process, ICANN org has also drafted a flowchart to illustrate how the ODP fits into the policy implementation lifecycle and how the community can provide feedback during the ODP process. Development of the ODP process took place in conjunction with the ICANN community over a six-month period. The steps outlining this process are explained here.

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