Currently the wording in the Behaviour: Persistence of Updates
section is:
"The API implementation MUST persist updates to the core information properties for the lifetime of a resource uniquely identified by its ID, including consistency over reboots, power cycles, and software upgrades."
I think traditional devices which have fairly static UUID allocations are well covered by the statement.
In terms of more dynamic devices I think we might need to better capture the relationship between persistence requirements and lifecycle/lifetime of resources. I think at the very least we need to define what is the lifetime of a resource.
Some options are:
- A. Does the lifetime of a resource end when the host Node expects to never use its UUID again? (e.g. a Node which has a remove resource workflow that permanently destroys the use of that UUID and future newly created resources are not expected to reuse that UUID).
- B. Does the lifetime of a resource end when its UUID disappears from the APIs hosted by the Node/Device?
For a Node/Device which has a limited number of operating profiles it can swap between, options A
and B
may result in different persistence outcomes.
For A
the Node/Device is required to persist information for every operating profile even if it is currently offline because their lifetime never really ends.
For B
the Node/Device only needs to persist the information for the current online operating profile. Switching away from the current operating profile could clear all associated information as the lifetime of resources ends.
Ultimately I believe our goal is to specify what is the minimum guarantee implementers can rely on.