Add timestamp to know when a component information was retrived

[oscargdd]

In current model you don't know how old is the information. The proposal is to add a timestamp for each component/device to know when a component information was lastr retrived/updated. Note that the retriaval is a time consuming process, so every component/device can have been updated at different time/day. We can debate wheter to have the timestamp per device or per component

[italobusi]

2023-05-17 Network Inventory weekly call

Need to clarify the meaning of the timestamp: whether it is the last time the information has been validated or whether it is the last time the information has been updated (changed) or both

We can define two optional timestamps to allow implementation freedom

Need to define whether these timestamps are defined per component or per device: it is possible to put the integrity timestamp at the device level and the change timestamp on a component level

Need to clarify that these timestamps are not intended to be used for assurance but only for planning, installation or to verify upgrades in the network

Chaode: what about adding a command to request the controller to refresh the information?

A refresh action can be added to the model

The integrity timestamp is also needed for the "non-detectable" information for equipment-room, rack and device: in this case the refresh action is not applicable

Need to clarify better the use cases

• [ ] @oscargdd @FabioPeruzzini @jbouqui153 Provide more information about the use cases

[italobusi]

2023-06-14 Network Inventory weekly call

Need to clarify better the use cases

• [ ] @oscargdd @FabioPeruzzini @jbouqui153 Provide more information about the use cases

Oscar:In general what I've got from operation department is to have the possibility to understand how old are the inventory information.Would be a timestamp indicating when the component was inserted and another one for the last time it was reported.

Nigel:In T-API notification/streaming there is fine grained timestamps but not on traditional T-API GET inventory.

Jeff: will ask in next TIP MUST optical weekly call the other operators but seems more reasonable not to modify our YANG model to consider these timestamps. probably these timestamps can be managed through notifications mechanism at a protocol level.

Discussions about flexibility to have these timestamps vs increased complexity for implementing it.