Specific properties

[nigel-r-davis]

https://github.com/ietf-ccamp-wg/ietf-network-inventory/blob/e633109c5dff36ea26e1844c6abd32e664eb9f0a/draft-ietf-ccamp-network-inventory-yang.txt#L573

In TAPI we determined that the following per type properties were relevant:

   |  |  |  +--ro common-equipment-properties
   |  |  |  |  +--ro asset-type-identifier?        string
   |  |  |  |  +--ro equipment-type-description?   string
   |  |  |  |  +--ro equipment-type-identifier?    string
   |  |  |  |  +--ro equipment-type-name?          string
   |  |  |  |  +--ro equipment-type-version?       string
   |  |  |  |  +--ro manufacturer-identifier?      string
   |  |  |  |  +--ro manufacturer-name?            string

and that the following per instance properties were relevant | | | | +--ro asset-instance-identifier? string | | | | +--ro is-powered? boolean | | | | +--ro manufacture-date? tapi-common:date-and-time | | | | +--ro serial-number? string | | | | +--ro temperature? decimal64

is-powered and temperature are questionable properties at this level. Temperature modeling should be independent and probably requires an explicit positioned non-fru to carry the detector which is itself essentially functional. Likewise, power modelling.

[nigel-r-davis]

Meeting 20230621: OK. Aligned,

[nigel-r-davis]

One final challenge here. The generalization to component of equipment and of holder means that a holder (e.g., a slot) has a manufacture-date distinct from that of its containing equipment (which is strange). When discussing this in TMF (some while ago), it was clear that solids and spaces had distinct characteristics. The solid fits well with component as it is a distinct thing, the space does not. The holder is a space with the potential to hold an equipment. In ONF TAPI it is not necessary to have an explicit holder (which is used to deal with the potential to equip.