Centralize storing of the timestamp of the latest attributeValueChangedNotification

[openBackhaul]

Idea: In case of temporary loss of DCN/SDN control plane connection, it would suffice checking this value to assure that there was no change during time of disconnection.

[DanielaSpreafico]

A proposal could be to add a new leaf last-avc-timestamp (or last-attribute-value-changed-timestamp ) on core-model::control-construct as in the following leaf last-avc-timestamp { type yang:date-and-time; default "2010-11-20T14:00:00+01:00"; config false; description "This attribute reports the timestamp of the last notification attribute-value-changed-notification sent by the node and related to any LayerProtocol";

[demx8as6]

avc -> better config change? RFC5277 Section 3.3 Notification Replay

[demx8as6]

Decision at the 5G-xhaul call on 28th of September 2022: A new leaf with name "last-config-change-timestamp" on core-model::control-construct shall be added. This attribute shall be injected the same way as it was done for the "externalLabel" in the EquipmentAugment: UML: ControlContruct_Pac:::lastConfigChangeTimestamp

On yang the result should look like the following

leaf last-config-change-timestamp { type yang:date-and-time; default "2010-11-20T14:00:00+01:00"; config false; description "This attribute reports the timestamp of the last configuration-changed. Configuration changes are AttributeValueChanges, ObjectDeletions and ObjectCreations.";

Just a note to mediator implementation, which is not part of the CoreModel: After a reconnect between Device and Mediator-Instance the Mediator-Instance software should update the "last-config-change-timestamp" with the Re-connect-time.

[openBackhaul]

This issue will be tracked in the equipment issue #26