Component parent/children and which containers/leafs apply to which component "type"

[earies]

Today, much of the modeling under /components is extremely loose and unrestricted as to what nodes apply under which components.

Adding some model-tree excerpts for context:

module: openconfig-platform
  +--rw components
     +--rw component* [name]
        +--rw name                           -> ../config/name
        +--rw config
        |     ...
        +--ro state
        |     ...
        +--rw properties
        |     ...
        +--rw subcomponents
        |     ...
        +--rw chassis
        |     ...
        +--rw port
        |     ...
        +--rw power-supply
        |     ...
        +--rw fan
        |     ...
        +--rw fabric
        |     ...
        +--rw storage
        |     ...
        +--rw cpu
        |     ...
        +--rw integrated-circuit
        |     ...
        +--rw backplane
        |     ...
        +--rw software-module
        |     ...
        +--rw controller-card
        |     ...
        +--rw oc-platform-healthz:healthz
        |     ...
        +--rw oc-linecard:linecard
        |     ...
        +--rw oc-transceiver:transceiver
              ...

Now, for above - one way to think about some of these top-level containers is that they only have relevance when the component type matches. e.g. the integrated-circuit container is only relevant when ../state/type = 'INTEGRATED_CIRCUIT' and the fan container is only relevant when the type is maybe of FAN, FAN_TRAY or FAN_TRAY_CONTROLLER (this one not so intuitive...). This is not gated in the model or any contract today.

To take this a step further, there are also other distributed data nodes (e.g. ./state/temperature/...) that have no categorization in addition to potential overlap to a specific component assumption (e.g. transceiver laser-temperature) somewhere else in a subtree (top-level state -> component level resources, etc..). This is also seen with sporadic leaf nodes (component-redundant-role really only applies to type=CONTROLLER_CARD, etc...)

module: openconfig-platform
  +--rw components
     +--rw component* [name]
        +--ro state
           +--ro temperature
              +--ro instant?           decimal64
              +--ro avg?               decimal64
              +--ro min?               decimal64
              +--ro max?               decimal64
              +--ro interval?          oc-types:stat-interval
              +--ro min-time?          oc-types:timeticks64
              +--ro max-time?          oc-types:timeticks64
              +--ro alarm-status?      boolean
              +--ro alarm-threshold?   uint32
              +--ro alarm-severity?    identityref

In addition, we have the SENSOR type which to be truthful, most data is pulled from a "sensor" of some type that resides on a physical component within the system.

This lack of clarity in modeling and relationships results in intepretation differences that need to be understood out-of-band and lead to divergence. This currently opens up the door for:

• Potential duplicate data (data reported under > 1 component)
• Needing to walk all parent/child relationships to understand and learn where the interesting data resides (not intuitive if you want to know data specific to a FAN but it resides as a separate child component SENSOR somewhere)
• Potentially non-intuitive parent/child relationships when it comes to sensors and the data being represented
• Backwards incompatible shifting of underlying data/relationships while the data-model has not changed

Raising this as an issue for further discussion within the OC community but as out-of-band contracts are being derived in projects such as ONDATRA (which are specific use-cases), these are items not known to the general community looking only at data-models as well as implementations that must stick w/ a static and expected hierarchy. We must conclude on a consistent approach that is available in a well understood contract otherwise divergence, misaligned expectations and potential backwards incompatibilites will continue to be seen.