Re: [Suit] Call for adoption on manifest draft

[Michael Richardson <[e-mail]>]

Brendan Moran <[e-mail]> wrote:
    > Hi Michael, I think it should be pointed out that
    > draft-morean-suit-manifest-04 incorporates the concepts of
    > draft-moran-suit-behavioural-manifest. Can you explain what it is that
    > makes you uncomfortable about the procedural approach?

okay, so I wasn't really sure as I re-read things quickly.
In my quick re-reading, I though that the definition of the proceedures was
still to come.  I guess I read too quickly!!!

Bluntly, it's the stopping problem :-)

But, before we worry about programs that do not terminate due to loops,
(because that issue can be solved... I maintain libpcap afterall!), the
problem that I have is the inability to reason about what the manifest does
by just looking at it.  I'm coming back to this paragraph after the ones
below: I think you've invented a proceedural machine that is trying really
hard not to be proceedural, but as a result it is even less understandable!

Are the problems we are trying to solve so complex, varied and unknown that
we need this?   Assuming that the answer really is yes, then who/what is
going to write these proceedures that we need?  It seems like a highly
technical job, if it's really a proceedure.

Looking at SUIT_Condition, (8.12) again, let me say that maybe the
description of this as a proceedure is really incorrect.  It looks
totally declarative to me.

Where I think it gets less declarative, as I understand it that
SUIT_Directive_RUN_Sequence can take a list of SUIT_Condition, evaluate them,
and then do stuff?   Basically, this is how we do if/then, I think.
The Coerce condition explanation could be better.

SUIT_Directive_Process_Dependancy seems like a way to invoke matching methods
on dependant manifests.    SUIT_Directive_Run, could just be called, "and
now, download stuff, and magic happens".  Yes, okay, it's all signed and the
like, but it seems rather hard to reason about.

I kept reading in detail, to section 9, and I wonder if I understand option 2
correctly.  A device with multiple images to load (and that needs to do in a
specific order, and there might be multiple levels), might have a proceedure
that looks like:

programA:
   if component-one-version < 4
   then
      load manifest for component-one-version=4; process.
   else if component-two-version < 5
   ...

where "load manifest" could effectively overwrite "programA" with the "component-one-program".
After that, the firmware finds it needs to upgrade, and starts programA
again, but this time, component-one is okay, so it proceeds?

I think that section 11, pseudo-code has "SHA256 A", when it should say
"SHA256 B", btw.

I didn't understand if "condition-component-offset" was a test or a action.

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