Re: [Suit] Introducing draft-moran-suit-behavioural-manifests-00

[Michael Richardson <[e-mail]>]

I've been through the document and I've read the thread, and I watched the
IETF104 video (I had a conflict).   I have a number of concerns.

I find some of the conversation about the details of the operations
indicative that coming to agreement for an proceedural mechanism may be
rather difficult to get consensus on; but I could be wrong here.

I feel that this proposal brings us away from a declarative manifest that can
be reasoned about without regard to time.  I'm not exactly sure I understand
the rational for the flexibility that is presented.
It could be that I just don't understand this well enough; I tend to
understand things by writing code, and I haven't written any code around
this.

Is there an example (maybe in the draft that I mis-understood) that would
provide a pair of use cases where being able to do things in different
orders, *at the control of the firmware update author* would make sense?
If product A always needs to do action-1 before action-2, and product B
always needs to do action-2 before action-1, I see no value in a behaviour
manifest.
It's when product A sometimes should do action-1 before action-2, and
sometimes action-2 before action-1 that the behaviour makes sense.

Again, maybe I just don't understand the proposal.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-