Skip to main content

A Peek into the ICANN Org Engineering “Factory” and an Update on CZDS

During the recent ICANN69 Prep Week Q&A with the ICANN org executive team, I was asked how the Engineering & Information Technology (E&IT) function prioritizes its work overall, and in particular how work on the Centralized Zone Data Service (CZDS) was progressing. Before I provide an update on CZDS, I'd like to explain how E&IT approaches project prioritization.

E&IT serves as a foundational "service provider" to ICANN. Since systems do not conform exactly to org-defined functional boundaries, E&IT is the place where cross-functional impacts become easily visible. As such, the E&IT team uses an integrative and collaborative process to gather demands for systems and to prioritize work. Twice a year, senior leaders in ICANN org are asked to evaluate their respective function's current and future E&IT-related project demands. Projects can be relatively simple like optimizing computer, network, and storage infrastructure, or more complex like custom-coding fit-for-purpose software systems, along with optimizing the infrastructure to go with such a system. This process includes gathering feedback from each team, aligning project proposals with the org's stated strategies, understanding cross-functional dependencies and impacts, considering input from the community, and prioritizing requests. This leads to an ordered list of E&IT demands for each function within ICANN org.

These project demands are then bounced against available capital (based on community-reviewed and ICANN Board-approved budgets) and E&IT capacity (based on uncommitted E&IT people bandwidth, including outsourced resources). These are the primary factors used to determine how many of the projects dependent on E&IT can be undertaken each semester (January-June and July-December). This helps to place a cut line in the ordered list of demands.

The finalized list of E&IT projects is referred to as the Frozen Delivery Pipeline. Each semester, the Frozen Delivery Pipeline is first reviewed and approved by ICANN Senior Vice Presidents, and then by the ICANN CEO, resulting in a set of projected deliverables. Any changes made to the plan, including project additions or subtractions, will trigger a review by the CEO.

To help with the internal organization and coordination of the Frozen Delivery Pipeline, E&IT work is divided into seven workstreams. The first six are relatively non-overlapping, while all of the workstreams typically converge on the seventh (Leveraged IT Infrastructure) in some shape or form. The seven workstreams are:

  1. Community Engagement: work related to supporting engagement with the ICANN community. For example, systems supporting the ICANN Fellowship Program, ICANN community structures, and travel programs.
  2. Community Collaboration: work primarily relating to tools and websites used by ICANN org, Supporting Organizations (SOs), and Advisory Committees (ACs). The Information Transparency Initiative (ITI) falls into this category.
  3. Contracted Parties: work supporting transactional work related to registries and registrars, including the Naming Services portal (NSp).
  4. Technical Services: work related to the numerous systems used by ICANN org and/or leveraged by the ICANN community to ensure that contractual obligations are met by the contracted parties. Systems like Service Level Agreement Monitoring (SLAM), Zone File Access, and CZDS fall into this category.
  5. Internet Assigned Numbers Authority (IANA) Services: work related to the systems used by the community and the IANA team to execute the IANA functions, including root zone management.
  6. Staff Services: work related to systems that serve the ICANN org, including Enterprise Resource Planning (ERP) functions like HR and Finance, Intranet, email, phone systems, Slack for internal messaging, etc.
  7. Leveraged IT Infrastructure: work related to systems and services used by all of the stakeholders listed above. Includes systems such as Zoom, data centers, cloud, information security, and ICANN Managed Root Servers (IMRS).

With this prioritization process in mind, I would like to address CZDS in more detail due to continued community interest.

A few years ago, the CZDS was reworked by replatforming it onto a combination of Java for the ICANN community-facing requester on the front end, and Salesforce for the contracted parties-approver on the back end (also consolidating this functionality in the NSp). This work was completed in January 2019. While it was a good start, there are additional elements of work that need to be addressed in order for the CZDS to conform with the recommendations made in SAC097 by the Security and Stability Advisory Committee (SSAC) in 2017.

E&IT's CZDS-related work encompasses workstreams three (Contracted Parties) and four (Technical Services). Below is the Frozen Delivery Pipeline related to these workstreams for the upcoming semester (January-June 2021) based on priority and resource allocation, along with brief explanations of the projects.

E&IT Frozen Delivery Pipeline

Technical Services

  • The SLA Monitoring (SLAM) system is undergoing a major update to improve monitoring performance, security, and metrics for registries. The SLAM system is the backbone of ICANN's technical services systems.
    • The Registrar Watch project will enable the provisioning of SLA monitoring for registrars, allowing ICANN to monitor the services provided by registrars per the Registrar Accreditation Agreement (RAA).
    • Enhancements to the ICANN Monitoring System API (MoSAPI) will support Registration Data Access Protocol (RDAP) monitoring, allowing ICANN to provide detailed RDAP information to contracted parties once the monitoring is enabled. This will benefit registries by incorporating additional SLA monitoring metrics.
    • Registration Reporting Interface (RRI) enhancements will allow ICANN's Compliance team to better address Registrar Data Escrow Agent (DEA) notification issues when they arise.

Contracted Parties

  • Work continues on the Naming Services portal (NSp).
    • We are rebuilding integrations with the Technical Services systems that will retire a legacy compliance platform (Kayako), create savings on licensing costs, improve the Compliance team's efficiency, and enhance the user experience for compliance case reporters.
    • NSp compliance will introduce functionality to allow reporters to submit multiple (bulk) compliance cases and will account for the remaining integrations.
    • In the June-July 2021 timeframe, the team looks forward to starting development on CZDS v3.0, which will fulfill a recommendation by the SSAC to auto-extend approved requests for zone files.

To summarize, since 2017 when SAC097 was accepted by the ICANN Board, CZDS-related work has been a priority. Many changes have been made to CZDS, but they have not been visible to end users as they involved changes to the underlying infrastructure used by CZDS. In addition, consultations with the community and internal ICANN org discussions have resulted in the higher prioritization of other projects. However, the upcoming semester's engineering workstreams indicate that work on CZDS will restart mid-2021, based on current priorities and constraints.

Understanding the community's desire to see faster delivery on CZDS projects, the E&IT team is looking at how best to augment capacity within the limits of capital and human resources in the short term. Java resources have been relatively easy to recruit for in the temporary and long term, but Salesforce talent for NSp-related work has proven to be significantly harder to identify and recruit.

I look forward to providing the community with further updates as we enter the next semester of work. In the meantime, thank you for your understanding and patience.

Comments

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