**Session Date/Time:** 07 Feb 2024 15:00

# [IVY](../wg/ivy.html)

## Summary

The IVY working group held an inter-meeting to discuss the status of the Network Inventory Core Module draft and to continue the crucial discussion on the definition and boundaries of "network inventory" for the working group. Key topics included updates to the core module, a conceptual framework for categorizing inventory, and an exploration of what falls within or outside the IVY scope, considering temporal aspects (live, planned, historical) and different types of entities (physical, informational). A proposal was made to explicitly define in-scope and out-of-scope items to guide future work.

## Key Discussion Points

*   **Working Group Status:**
    *   Ongoing discussion on network inventory terminology on the mailing list.
    *   This was the last monthly inter-meeting before IETF 109.
    *   The design team continues weekly public meetings for the network inventory core module.

*   **Network Inventory Core Module Draft Status (Presented by Char Liu):**
    *   **Recent Updates (PR #34 and #31):**
        *   Efficiency issue discussions moved to an appendix, as these issues are considered protocol-related (NETCONF/YANG) rather than data model inherent.
        *   Terminology for "container" clarified to distinguish between RFC 8348's slot object and YANG's container.
        *   A new root container was added at the same level as `ne-element` to support inventory of fiber and cable, which are not considered `ne-element`s.
        *   The configuration capability of attributes was discussed; while all attributes are currently defined as read/write, there's a concern that not all inventory attributes should be configurable. This point requires further discussion.
        *   The description of `part-number` of `component` was updated.
        *   `part-number` was removed from `ne-element`. Further discussion is needed on whether to replace it with `assembly-id` or `model-id`.
        *   A basic `component` structure was introduced. Discussion is ongoing regarding the inclusion of a `class` attribute to facilitate filtering when querying specific component types.
        *   Agreement was reached to keep `any-id` and `component-id` in `string` format to allow for flexible implementation.
    *   **Current Discussion Points:**
        *   Whether to remove or rename the `part-number` attribute for `ne-element`.
        *   Whether to retain the `class` attribute in the `component` structure for filtering.
    *   **Next Steps for the Draft:** Continue discussions on terminology and use cases, finalize configuration capabilities, resolve the `part-number` and `component` structure issues, and continue modeling fiber and cable.

*   **Network Inventory Definition and IVY Boundary (Presented by Nigel Davis):**
    *   **Categorization of Inventory:** Proposed a framework to categorize items:
        *   **Physical:** Measurable, tangible (e.g., circuit packs, shelves).
        *   **Functional:** Does something, has behavior, not measurable (e.g., termination points, emergent functions).
        *   **Informational:** Collections of data (e.g., policies, profiles, software, licenses).
        *   **Motive Force:** Electrical power, causes physical things to give rise to function.
    *   **Asset vs. Resource:**
        *   An **asset** is an owned item with financial value, subject to depreciation.
        *   A **resource** is a component or commodity useful for activity, not necessarily owned or depreciating in the same way. A circuit pack can be both an asset and a resource, while a termination point is a resource but likely not an asset.
    *   **Definition of Inventory in IVY:** The English word "inventory" means a list of items. However, IVY's scope is more specific:
        *   It implies a "structure" of particular types of physical things, not just a flat list.
        *   It is not an inventory of *everything* (e.g., not "dogs and spoons").
        *   A specific, narrow definition of "inventory" for IVY is crucial for scoping the work.
    *   **Temporal Scope:**
        *   **Live view:** Critical for current network status.
        *   **Future planning:** Some aspects are necessary (e.g., expected equipment, committed deployments) where specific equipment types are known. More vague, long-term plans may be out of scope.
        *   **History:** The history of what *was* live in the network (e.g., for troubleshooting, fault analysis) appears manageable and useful. It's a capture of past "live" states. The history of abandoned future plans is less clear.
    *   **Proposed IVY Boundaries:**
        *   Initial consideration: "Physical only" vs. "Physical and Informational" (a subset of informational, like software and licenses).
        *   **Out of Scope (or limited scope):**
            *   Detailed geographical layouts (ducts, manholes, physical routes beyond abstract connections).
            *   Modeling the *entire* power network (only what directly powers network elements).
            *   Detailed site/building models (beyond location shims for equipment).
            *   Physical units in transit/shipment.
            *   Emergent functions (local to NEs or networking functions themselves).
            *   Detailed capability specifications (complex area, potentially out of scope for the core model).
        *   **In Scope (or potential scope):**
            *   Software running on equipment, and potentially associated licenses.
            *   Spare physical equipment holdings (e.g., in a cabinet), as they maintain similar properties to deployed equipment (serial numbers, types), though they are not "live."
        *   **Virtual Network Elements:** The IVY model, primarily focused on physical circuit packs, could theoretically apply to blades in servers within a data center. The challenge arises with fully virtual NEs where the underlying hardware is abstracted or managed by a different entity; in such cases, IVY might focus solely on informational elements (software, licenses) and have no direct hardware knowledge.
    *   **General approach to defining scope:** Instead of relying solely on a broad definition, explicitly listing examples of what is **in** and **out**, particularly for boundary cases, would provide clearer guidance and help achieve consensus. This could allow for a phased approach (e.g., initially focusing on physical items, then expanding to informational).

## Decisions and Action Items

*   The next weekly IVY call (following this inter-meeting) will be cancelled due to the Chinese Spring Festival.

## Next Steps

*   Continue the discussion on network inventory terminology and use cases, leveraging the conceptual framework presented.
*   The chairs and presenters will work to propose a simple, plain list of items considered in-scope for the core IVY model to the working group mailing list for discussion and consensus building.
*   Finalize discussions on configuration capabilities of attributes, the `part-number` attribute, and the `component` basic structure.
*   Continue discussion on the modeling of fiber and cable.