ICANN Blogs

Read ICANN Blogs to stay informed of the latest policymaking activities, regional events, and more.

Advancing the Operational Design Phase

11 March 2021
By and Göran Marby

We would like to thank the community for working constructively with the ICANN organization (org) on the Operational Design Phase (ODP). Thanks to this cooperation, we are pleased to share that the ICANN Board has reviewed the ODP process paper following two rounds of community input. The org worked closely with the community to draft the ODP paper, incorporating community feedback with each new version. After careful consideration, updates to the paper were developed. An overview of the iterative revisions, detailed in the slides below, may help illustrate the changes.

The purpose of the ODP is to perform an assessment of the Generic Names Supporting Organization (GNSO) Council policy recommendations in order to provide the Board with relevant information for its deliberations. When the Board receives a Recommendations Report from the GNSO Council containing recommendations previously adopted by the Council, the Board has to decide — per the Bylaws — whether those recommendations are in the best interests of the ICANN community or ICANN. The ODP will assess, for example, the recommendations' technical feasibility, resource requirements, and dependencies. The ODP thereby helps inform the Board's discussions by improving existing processes; and it adds transparency and structure to the work the org performs to assess the operational impact of GNSO Council-approved recommendations.

Only the Board can initiate an ODP, and the Board will do so if and when an assessment is warranted, based on the complexity or potential operational impact of the recommendations. By requesting an ODP, the Board will direct ICANN org to perform an operational analysis of the recommendations, based on a Board-determined scope, resulting in an ODP assessment. Once completed, the org will submit the assessment to the Board for its consideration. In addition to relevant materials, such as the Bylaws-mandated Public Comment on the recommendations, the assessment will inform the Board in its determination whether the recommendations are in the best interest of the ICANN community or ICANN. The Board may also decide to initiate an ODP for other types of community-developed recommendations. In all cases, the Board will follow the requirements for an ODP to support transparency in the information that the Board relies upon for its decision.

During an ODP, ICANN org will consult with the community at appropriate stages, as a key part of the process. Consultation — like any other part of the ODP — is not a forum to relitigate questions raised during the policy development process. Consultation takes place via progress updates or requests for community input. The org will provide regular updates on its progress via a number of platforms, including the icann.org website, webinars, and blogs, as well as dedicated sessions during ICANN Public Meetings to offer the community opportunities to ask questions and seek clarification. The Board will also remain involved in the ODP process by receiving relevant status updates and engaging when appropriate with the org and the community. Once the 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 Board, and org are aware of the different input provided. Should any policy questions arise during the assessment, these will be referred to the GNSO Council, who is encouraged to appoint an ODP liaison for this purpose. There are times that the Board will also participate in the engagement with the GNSO Council and the wider community, such as if policy issues emerge.

As laid out in the ODP process paper, regular reviews of the ODP's workings will ensure that the ODP remains a living concept that serves the needs of the Board while working constructively with the community through consultations. The first review will take place once a minimum of two ODPs are completed.

In the coming months, the Board is considering the launch of two ODPs related to:

  • The recommendations on the System for Standardized Access/Disclosure to Nonpublic Registration Data (SSAD) from the EPDP Phase 2.
  • The New gTLD Subsequent Procedures Policy Development Process recommendations that were approved by the GNSO Council on 18 February 2021.

We invite you to review published materials related to the ODP here and look forward to sharing future ODP updates.

ODP_v1 vs Comment vs ODP_v2

ODP Paper v1 Community Feedback ODP Paper v2
Community Design Feedback Group (DFG) formed to provide input into ODP assessment.
  • Questions about composition, charter.
  • Overly engineered.
  • Little or no support for DFG.
  • GNSO Council appoints liaison to ODP.
  • Community consultation via existing mechanisms.
  • Public Comment optional.
  • No more DFG.
  • Consultation on functionality after two ODPs conclude.
Board initiates ODP via resolution. n/a Board initiates ODP in writing, e.g., resolution.
  Concern about "second bite" at policy discussions during ODP.

More clarity provided on:

  • ODP does not affect the substance or intent of the recommendations.
  • Questions on substance/intent put to GNSO Council.
  • Only Council can address policy issues.
  • ODP purpose is to provide the Board with needed info, so it can decide if a recommendation is in the best interest of the ICANN community and ICANN.
ODP initiated after the GNSO Council sends a Recommendation Report to the Board. Timing concerns.
  • Board's reception of the Recommendation Report remains the "natural trigger point" for ODP.
  • ODP aims to finalize work by the second meeting after the Board receives a Recommendation Report.
Based on consultations, ODP can overlap with PDP working group (WG). Support from the community.
  • Continue to have two possible start points for an ODP.
  • Rely on CPIF language for ICANN org to engage with PDP on "implementation-related matters" during PDP WG.

 

ODP_v2 vs Comment vs ODP_v3

ODP Paper v2 Community Feedback ODP Paper v3
  • GNSO Council appoints liaison to ODP.
  • Community consultation via existing mechanisms.
  • Public Comment optional.
  • Consultation on functionality after two ODPs conclude.
  • Community groups other than GNSO Council ODP liaison should be able to provide feedback on ODP assessment.
  • Liaison should not be overburdened, consider to include a team of 3 or 5 members to provide input.
  • Community feedback on the ODP assessment needs to be transparent and visible to all.

Clarification on:

  • GNSO Council liaison input only sought on issues that may pertain to policy and/or substance/intent of questions, as those are the purview of the Council.
  • Upon reaching relevant milestones during the ODP assessment, ICANN org will share findings with the entire community.
  • All feedback will be publicly available.
  • ODP does not affect the substance/intent of the recommendations.
  • Only GNSO Council can address policy issues.
  • Continued concerns about relitigating.
  • Further emphasis that the ODP is not a forum to relitigate questions raised during the policy development process.
  • ODP aims to finalize work by the second meeting after the Board receives Recommendation Report.
  • ODP should not add disproportionately to the length of the overall policy and implementation lifecycle.
  • ODP should be time limited with a set end date.
  • Board aims to initiate ODP by the second Board meeting after receiving the recommendations report.
  • As part of the scope, the Board will also agree on a realistic timeline for ODP completion.
  • Included rationale why time spent on ODP may save time during implementation.

Authors

Maarten Botterman

Maarten Botterman

ICANN Board Member
Göran Marby

Göran Marby

Former President & CEO