Re: [Suit] On device resets during manifest processing

[Brendan Moran <[e-mail]>]

Thanks Carsten, Øyvind & Michael,

I’ve updated the below with your suggestions.


Best Regards,
Brendan


Proposed Manifest Text:

Section 6.8: Resilience to Disruption

As required in Section 3 of RFC9019, devices must remain operable after a disruption, such as a power failure or network interruption, interrupts the update process.

The manifest processor must be resilient to these faults. In order to enable this resilience, systems implementing the manifest processor MUST make the following guarantees:

Either:
1. A fallback/recovery image is provided so that a disrupted system can apply the SUIT Manifest again.
2. Manifests are constructed so that repeated partial invocations of any manifest sequence always results in a correct system configuration.
3. A journal of manifest operations is stored in nonvolatile memory so that a repeated invocation does not alter nonvolatile memory up until the point of the previous failure. The journal enables the parser to recreate the processor state just prior to the disruption. This journal can be, for example, a SUIT Report. This report can be used to resume processing of the manifest from the point of failure.

AND

4. Where a command is not repeatable because of the way in which it alters system state (e.g. swapping images or in-place delta) it MUST be resumable or revertible. This applies to commands that modify at least one source component as well as the destination component.




IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.