This model deals with physical things (solids and spaces). The model does not yet cover some physical aspects such as connectors, cables, strands and physical spans. We have some work that may be helpful in TAPI. We should avoid broad physical modeling such as geographic structures etc.
the ability to hot-swap and to deal with other dynamics should be considered in this model.
Other characteristics such as height, length, width, weight etc. may be best handled in a spec layer. This needs to be discussed in some details. This also applies to the humidity characteristics, fire characteristics, power rating, thermal ratings, physical stress and mechanical vibration characteristics.
The model intentionally does not cover functional aspects. We should work on the relationship between functional and physical. The functional model relationship needs to deal with "equipment protections" which is really functional protections. ONF have some work that may help here.
There are a few cases of mechanical functionality (such as a fan). This could be covered here (e.g., the property fan-speed could be a valid augment to a module that has a fan.
The model of temperature, humidity and other environmental aspects (especially when measured) relate closely and should be considered carefully.
The model of power is unusual in that it is narrow functional. There is a flow etc. The relationship between this model and power needs to be considered carefully. Power is not physical but from the perspective of the other functions it is essentially the motive force. There is no detailed model of power. In other bodies, power is "smunged" into the physical model. This needs to be considered very carefully.
The model of software is complex and should be separate from the model of the physical solution.
State machines associated with the power-up cycle, admin state etc. really related to the functional model and should be considered carefully.
https://github.com/ietf-ccamp-wg/ietf-network-inventory/blob/e633109c5dff36ea26e1844c6abd32e664eb9f0a/draft-ietf-ccamp-network-inventory-yang.txt#L18
This model deals with physical things (solids and spaces). The model does not yet cover some physical aspects such as connectors, cables, strands and physical spans. We have some work that may be helpful in TAPI. We should avoid broad physical modeling such as geographic structures etc.
the ability to hot-swap and to deal with other dynamics should be considered in this model.
Other characteristics such as height, length, width, weight etc. may be best handled in a spec layer. This needs to be discussed in some details. This also applies to the humidity characteristics, fire characteristics, power rating, thermal ratings, physical stress and mechanical vibration characteristics.
The model intentionally does not cover functional aspects. We should work on the relationship between functional and physical. The functional model relationship needs to deal with "equipment protections" which is really functional protections. ONF have some work that may help here.
There are a few cases of mechanical functionality (such as a fan). This could be covered here (e.g., the property fan-speed could be a valid augment to a module that has a fan.
The model of temperature, humidity and other environmental aspects (especially when measured) relate closely and should be considered carefully.
The model of power is unusual in that it is narrow functional. There is a flow etc. The relationship between this model and power needs to be considered carefully. Power is not physical but from the perspective of the other functions it is essentially the motive force. There is no detailed model of power. In other bodies, power is "smunged" into the physical model. This needs to be considered very carefully.
The model of software is complex and should be separate from the model of the physical solution.
State machines associated with the power-up cycle, admin state etc. really related to the functional model and should be considered carefully.