clarification on parent leaf in openconfig-platform.yang clarification on parent leaf in openconfig-platform.yang

[bjs111981]

In RFC 6020 (https://datatracker.ietf.org/doc/rfc6020/) we have the following -

9.9. The leafref Built-In Type

The leafref type is used to reference a particular leaf instance in the data tree. The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances.

If the leaf with the leafref type represents configuration data, the leaf it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All leafref nodes MUST reference existing leaf instances or leafs with default values in use (see Section 7.6.1) for the data to be valid. This constraint is enforced according to the rules in Section 8.

There MUST NOT be any circular chains of leafrefs.

If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.18.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features.

" All leafref nodes MUST reference existing leaf instances or leafs with default values in use (see Section 7.6.1) for the data to be valid " , But there is no default value for parent leaf.

leaf parent {
  type leafref {
    path "../../../component/config/name";
  }
  description
    "Reference to the name of the parent component.  Note that
    this reference must be kept synchronized with the
    corresponding subcomponent reference from the parent
    component.";
}

There is no "mandatory" statement associated with this leaf, so does this mean that it is fine not to export this for some components? If not, what would be the right value for a "root" component (example - CHASSIS0 in Juniper devices) which does not actually have a parent?

[dplore]

The formal OC platform module description is very permissive. However I do expect that all components have a parent which recursively traces to a component with platform type "CHASSIS". I would expect that CHASSIS to be the root of the hardware component tree and have no parent.

There are a number of functional test for the platform module which express requirements like this. In particular this gNMI-1.4: Telemetry: Inventory expects to trace a number of commonly implemented platform types up to a node with platform-type CHASSIS .