Skip to main content

FAQs: Operational Design Phase

  1. ODP Overview

    What is an Operational Design Phase (ODP)?

    An ODP is a defined process, initiated by the Board, through which ICANN org will assess the operational impacts of a set of Consensus Policy Recommendations approved by the GNSO Council as part of a Policy Development Process prior to Board consideration.

    What is the purpose of an ODP?

    An ODP provides the Board with relevant information for its deliberations on whether to approve the said recommendations, including whether the Consensus Policy Recommendations approved by the GNSO Council as part of a Policy Development Process are in the best interests of the ICANN community or ICANN.

    Is the ODP a completely new process?

    The process of the Operational Design Phase may seem new to many. However, the Board has always asked ICANN org to prepare relevant materials to help inform its deliberations and decisions. The Consensus Policy Implementation Framework specifies that ICANN org, in the "Prepare" stage, provides materials and information to support the Board in its consideration of policy recommendations. The ODP is a formalization of the existing processes to ensure a complete, consistent, and robust assessment in situations where the Board determines it is warranted.

    Who can launch an ODP?

    Only the ICANN Board can direct ICANN org to conduct an ODP.

    At what point can the ICANN Board initiate an ODP?

    The natural trigger point for an ODP is after the GNSO Council has transmitted its Recommendations Report to the ICANN Board (as per Annex A, Section 8 of the Bylaws), as the GNSO Council, through its approval, will have finalized the Consensus Policy Recommendations.

    Community feedback during the development of the ODP process supported the idea of an earlier launch of the ODP under certain circumstances. Such an earlier start would mean that the ODP overlaps with the PDP. Therefore, if either the Board or the GNSO Council believes that a particular PDP may benefit from initiation of a formal ODP before the policy development phase concludes, the Board and the GNSO Council may consult and agree on such an earlier start. While other factors may be of relevance, the consultations should demonstrate that, at a minimum, the PDP working group has made sufficient progress on key recommendations to ensure the ODP will be both feasible and constructive.

    Do all GNSO policy recommendations require an ODP?

    No. The Board will initiate an ODP in instances where it determines that the implementation resourcing or the complexity of Consensus Policy Recommendations approved by the GNSO Council as part of a Policy Development Process warrants an enhanced assessment by ICANN org before the Board can decide if adopting recommendations is in the best interests of the ICANN community or ICANN.

  2. ODP Conduct

    What is the scope of an ODP?

    An ODP will assess, for example:

    • The fiscal impact of implementing Consensus Policy Recommendations approved by the GNSO Council under different design scenarios;
    • Design requirements and workflows, assessment of technical decisions and resourcing;
    • Preliminary risk analysis and mitigation plans;
    • Other information that the Board deems relevant for its consideration of whether a Consensus Policy Recommendation approved by the GNSO Council is in the best interests of the ICANN community or ICANN.

    The specific scope for each ODP can vary but will be approved by the Board and published on the subject-specific project webpage; please see

    What is ICANN org's role in an ODP?

    ICANN org performs the entire operational analysis, modeling, and design for the Consensus Policy Recommendations approved by the GNSO Council, based on a Board-determined scope. ICANN conducts the ODP from the perspective of preparing the ICANN Board to make a decision regarding a given set of GNSO-Council approved consensus policy recommendations and makes no judgment on the Board's determination whether to approve these recommendations.

    What is the Board's role once an ODP starts?

    The ICANN Board will remain involved in the ODP process by receiving relevant status updates and engaging with ICANN org and the ICANN community when appropriate.

  3. Community Engagement during an ODP

    What input can the community provide to the ODP?

    ICANN org will consult with the ICANN community at scheduled intervals throughout the ODP, relying on existing community structures and processes to provide updates and seek feedback. Once ICANN org has reached relevant milestones in its assessment, it will consult with the ICANN community to obtain input on the facts, figures, and assumptions that underpin the assessment. Such consultations will take place transparently to ensure that all parts of the community, the ICANN Board, and ICANN org are aware of the different input provided.

    These consultations will be focused on the operational design work and are not a forum to relitigate policy questions addressed during the policy development process.

    How can I stay informed about an ODP once it starts?

    Each ODP will have a subject-specific project webpage which contains the relevant information for that ODP. To ensure the community has opportunities to ask questions and seek clarification, ICANN org will provide regular updates on its progress on an ODP via mechanisms such as webinars, blog posts, and dedicated discussions with community groups, as requested, during ICANN public meetings.

    What if policy questions come up during the ODP?

    Policy questions that may arise during the ODP are referred to the GNSO Council. If the ICANN Board, the ICANN community, or ICANN org are unclear about the intent or substance of a given recommendation, or believe there may be unanswered policy questions, the issue in question is referred to the GNSO Council, typically via a GNSO Council Liaison.

    Who determines if something is a policy question or an operational question?

    While ICANN org may identify a potential policy issue, ICANN org will inform the ICANN Board who in turn will ask the GNSO Council to consider the policy issue. The GNSO Council will then decide whether they agree and how to proceed in case a policy issue is encountered. The GNSO Council is encouraged to appoint a liaison to the ODP, to streamline communications between ICANN org's ODP team and the Council should any such policy questions arise.

    Why is there a GNSO Council Liaison and not a liaison from other SO/ACs?

    Any questions that arise during the ODP pertaining to policy, substance, or intent of Consensus Policy Recommendations that were approved by the GNSO Council will be addressed back to the GNSO Council as the manager of the Policy Development Process. Because the GNSO Council has approved the recommendations and transmitted them to the Board, questions on substance and intent need to be directed back to the Council. The role of the GNSO Council Liaison is to help facilitate these communications.

  4. ODP Outcome

    How long will ICANN org take to conduct the ODP?

    As part of the scope, the ICANN Board will also provide the org with a requested timeline for completion of the ODP. ICANN org will strive to complete each ODP as soon as feasibly possible and within the timeframe stipulated by the ICANN Board.

    What is the final output of an ODP?

    The final output of the ODP is a report called "Operational Design Assessment" (ODA).

    What is contained in the Operational Design Assessment (ODA)?

    The Operational Design Assessment (ODA) is the report that marks the final output of an ODP. Typically, the ODA is structured as a high-level, end-to-end operational design model of how to implement the Consensus Policy Recommendations approved by the GNSO Council as part of a Policy Development Process.

    What happens once ICANN org finalizes the Operational Design Assessment (ODA)?

    Once completed, ICANN org will submit the ODA to the ICANN Board, concluding the ODP. The ICANN Board will use the ODA, together will all other relevant information, such as the GNSO Council's Recommendations Report, the PDP Final Report, and Public Comments, to determine whether adopting the recommendations is in the best interest of the ICANN community or ICANN. In keeping with ICANN org's transparency and publication practices, the ODA will be published on ICANN's website.

    Will the ODP prolong the time to get to a decision by the ICANN Board?

    The ICANN Board will only launch an ODP if it determines that its outcome will add value to its deliberations and that the time spent to conduct the ODP is necessary and important to inform its deliberations in accordance with all relevant Bylaws provisions.

    Additionally, while conducting an ODP might result in the Board making a decision on the Consensus Policy recommendations at a later point, the Operational Design Assessment (ODA) will help streamline the time it would otherwise take to implement the policy.

  5. Development of the ODP Process and Continuous Improvement

    How did the ODP concept and process come into existence?

    The ODP concept and process were developed collaboratively between the three pillars of ICANN: the ICANN community, ICANN org, and with oversight from the ICANN Board. Development of the ODP took place over a six-month period and an outline of the process that was followed can be found here.

    How does the ODP fit into the Consensus Policy Implementation Framework (CPIF)?

    The ODP is part of the generic top-level domain (gTLD) policy implementation lifecycle and eventually will be incorporated into the Consensus Policy Implementation Framework (CPIF). Before modifying the CPIF, ICANN org will conduct a community consultation on the functionality of the ODP after a minimum of two ODPs have concluded, to ensure that the ODP operates effectively and fulfills the needs of the ICANN Board, the community, and ICANN org.

    Will the community have a chance to review the ODP concept and process after the first few ODPs have been completed?

    Yes. The ODP process paper anticipates regular reviews of the ODP process to ensure that it serves the needs of the ICANN Board while working constructively with the community through consultations. After a minimum of two ODPs have been completed, ICANN org will consult with the Board, the GNSO Council, the relevant ICANN org ODP teams, the GNSO Council liaison(s) to the ODP (if appointed), and the wider ICANN community to assess what updates – if any – may need to be made to improve the efficiency and effectiveness of the ODP process. This consultation will be part of continuous improvement efforts regarding the ODP's processes to ensure it fulfils the needs of the Board, community, and ICANN org.

    Where can I find more information about the purpose of an ODP and how it works?

    More information can be found on ICANN org's ODP landing page. Additional information is also 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.

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