Modeling holder

[nigel-r-davis]

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

It is assumed that the component is a solid thing, i.e. and equipment in TAPI. TAPI also models the holder where the equipment is composed of holders and other things. The holder identifies the opportunity to accommodate another equipment. This is a vital piece of the model.

Traditionally, the holders have been modeled explicitly such that an equipment is reported with all of its holders indicating their equipping level. This provides a clear view of the available slots etc. This is the approach TAPI takes. It would be possible to instead provide a machine interpretable specification of the structure of the equipment (all invariant data) that could then be used by a client to understand the level of equipping etc. In this approach, the nested equipment would need to reference a slot in the parent (removing the need for explicit holders.

However, it has proved challenging to define the spec model of capability (hence my https://datatracker.ietf.org/doc/draft-davis-netmod-modelling-boundaries/ work. As the number of holders is very small, I recommend explicit modeling as opposed to the more forward-looking/futuristic spec approach.

The holder has properties: | | | | +--ro holder-category? holder-category | | | | +--ro is-guided? boolean | | | | +--ro holder-location? string

Clearly, again, a spec model should be used to describe the holder and its capabilities.

[nigel-r-davis]

Meeting 20230621: It was explained that component represented both equipments and holders. It was emphasized that the model was to report what is, not what could be.

[nigel-r-davis]

Meeting 20230621: Separately, there needs to be a model of capability but this is separate from describing inventory.

[nigel-r-davis]

Equipment capability will potentially covered elsewhere.