**Session Date/Time:** 27 Jul 2023 20:00

# ivy

## Summary

The first meeting of the ivy working group focused on defining the scope and objectives of the working group, particularly concerning a core network inventory model. Several presentations were given on existing models and problem statements related to network inventory, asset lifecycle management, and observability. The meeting concluded with an open discussion to align terminology and identify key priorities for the working group.

## Key Discussion Points

*   **Working Group Scope and Charter:**  Clarification of the working group's scope, focusing on network inventory for devices from layer 0 to layer 3, including hardware and software inventory. Discussion on what falls outside the scope, such as how the inventory model is used (with caveats on usability aspects), but stressing that the charter can evolve over time.
*   **Terminology Alignment:**  Emphasis on the need for a common terminology and clear scoping of what constitutes network inventory, distinguishing it from topology and other related concepts. The idea of creating a glossary was raised.
*   **Existing Models and Approaches:** Presentations covered:
    *   An inventory management model based on RFC 8345, filling the gap for a physical network layer.
    *   A YANG data model for network hardware inventory from CCAMP, focusing on hardware components.
    *   A life cycle management operations (LMO) problem statement for asset management.
    *   An overview of network inventory for network observability.
*   **Use Cases and Requirements:**  Discussion on use cases such as device/component tracking, software updates, hardware component planning, and energy monitoring/control.
*   **Relationship to Topology Models:**  Exploration of how the inventory model relates to existing topology models (e.g., L3NM, L2NM, SAP) and how to establish correlations between different layers (service, network, device). Different approaches were discussed for how to include or link to topology.
*   **Virtualization:**  Clarification that virtualized components, such as virtual routers, are in scope, but virtual network functions (VNFs) are currently not.
*   **Assets vs. Inventory:**  Extensive discussion on how "assets" relate to "inventory," and if "asset" is a hierarchical container of inventory or separate entities. A key point was clarifying that assets are units of deployment or acquisition, while inventory is about the current state.
*   **Physical vs. Logical Inventory:** Debate regarding whether inventory should cover physical assets only or should also include logical inventory (e.g. IP address pools). The need to model system software alongside hardware was discussed.
*   **Planned vs. Deployed Status:**  Discussion of whether the inventory model should include items that are planned but not yet deployed, with some arguing for including them for planning purposes.

## Decisions and Action Items

*   **Prioritize Physical Inventory:** The working group will initially focus on modeling physical inventory due to its relative simplicity and immediate need.
*   **Clarify Scope in Draft:** The first draft of the core inventory model will include a dedicated section clearly defining the scope of the model and what is specifically excluded.
*   **Address Terminology:** A GitHub repository or similar mechanism may be used to gather and address terminology issues in parallel with core model development.
*   **Base Model Approach:** Adopt a modular approach, starting with a basic, simple core model that can be augmented and extended in the future to address additional requirements (e.g., software inventory, licenses, enterprise networks).
*   **One Draft:** Attempt to coordinate contributions into a single draft with a designated set of authors in order to avoid the need to merge multiple drafts.
*   **Operator Driven:** Attempt to structure development by having operators drive the work in order to make the model more successful.

## Next Steps

*   **Schedule Interim Meetings:** The chairs will arrange interim meetings between now and the next IETF meeting to maintain momentum and accelerate progress. Consider weekly or bi-weekly meetings.
*   **Continue Discussion on Mailing List:** Participants are encouraged to continue discussions on the mailing list to reach consensus on outstanding issues.