Re: [Suit] draft-moran-suit-manifest-04 - prescriptive

[Martin Pagel <[e-mail]>]

Hi Brendan, 
Thanks for your background info in your presentation yesterday...

I thought some more about the "no script option". You're right, that we would need to keep the hashes separate then. We still need the download URI list, therefore it would be almost no command list rather than a no command list option. 

In my Feb 13 email (see snippet below), I had also proposed to consider a cloud service enforcing the dependencies rather than to broadcast all manifests and have each device check for applicability based on dependency enforcement commands. Then those dependency commands could be eliminated and it would reduce parsing and processing on the device. For constrained devices this might be another option to consider (kind of a hybrid of the full and the almost no command list option).

I also thought about URIs again and for long URIs compression might result in a smaller manifest, so either relative paths or compression would reduce the manifest size. Any strong opinions from the group?
Best
Martin


From: Martin Pagel 
Sent: Wednesday, February 13, 2019 2:58 PM
...
Cloud vs Broadcast
I believe the current draft is optimized towards the broadcast of many manifests and the device may have to check many manifests in order to determine whether it needs to apply an update while a lot of the manifests would be irrelevant to the device. If however the device could provide its configuration information (vendor and class and version for each of its components) to an Update Server cloud service, the cloud service could just respond with a confirmation that the device is running the proper software or provide a new manifest of the software it should be running. That way the cloud would have the burden of selecting the correct manifest rather than the device. The service may even provide the payload, too, and use channel encryption for privacy. I think it would be beneficial to define a subset which would be simpler and optimized for this scenario, I have no problem if the extra fields (like PreInstallationInfo, DependencyInfo...) would be included for the broadcast scenario.


-----Original Message-----
From: Martin Pagel 
Sent: Monday, March 25, 2019 9:05 PM
To: 'Brendan Moran' <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-moran-suit-manifest-04 - prescriptive

Hi Brendan, 
A quick reply:
- no script option: Even if that's not your intention, why not leave it as an option for constrained devices which rather hardcode the installation process (based on component id for example) rather than implementing an interpreter?
- component id: thanks for the explanation, your proposals is very flexible.
- URIs: The full (prioritized) list would need to list relative instead of full paths. I bet that's better than compression.
Looking forward to further discussions tomorrow.
Martin

-----Original Message-----
From: Brendan Moran <[e-mail]> 
Sent: Thursday, March 21, 2019 9:19 AM
To: Martin Pagel <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-moran-suit-manifest-04 - prescriptive

Hi Martin,

My intent is to produce a generic interpreter. My hope is to make it small enough that it is reasonable to include on very constrained platforms. It’s not really intended for use with none of the scripts populated.


Component IDs:
I don’t think I’ve explained component ID well enough. It’s supposed to be a machine-readable path. To that end, it’s an array of binary strings, which makes it simple for devices to parse. The example I gave was human readable to make it easier to illustrate the point. However, when a device has two places that it can store a payload, it would be possible to use component IDs [h’00’] and [h’01]. If you want a component ID that lets you use an arbitrary offset into flash, then you could have a system as follows:
1. The first element of the Component ID indicates which storage subsystem to use (internal flash, or external SPI flash, for example) 2. For internal flash, the second element could represent an offset.
3. For external SPI flash, the second element could indicate the file name or directory to use.

If internal flash is represented as h’00’ then the component ID for an internal flash target with offset 0 would be: [h’00’,h’00’] With an offset of 0x400, the component ID would be: [h’00’,h’0400’] (in big-endian notation) If external flash is represented as h’01’ then the component ID for a temp file on external flash with path “/tmp/example” could be represented as either:

[h’01’, "/tmp/example”]
Or
[h’01’, “tmp”, “example”]

Because “paths” are extremely application dependent, we have tried to avoid specifying this behaviour much. Perhaps it would be helpful to add a few more examples.

URIs:
Using a mechanism to specify a URI relative path is interesting. How do you see that interacting with the prioritised list of URIs? Another option would be to simply compress the manifest. This is not an option on small devices, but a device that can accept 10 images is not a small device, so a minimal compression library may be a viable option.

I think we should consider adding in some mechanism to deal with this, but I think we should first study whether compression is the right answer.

Dependencies, Unpacking:
You’re right, there aren’t examples of all features. That’s certainly something we want to work towards!

Best Regards,
Brendan

> On 15 Mar 2019, at 23:20, Martin Pagel <[e-mail]> wrote:
>
> Hi Brendan,
> This an impressive re-draft, it's almost a new/separate manifest approach all together. I like the switch from a descriptive approach to a prescriptive one and the fact that the manifest is quite small for the basic cases.
>
> Is your goal to develop a generic installer which could interpret the "script" (apply-image and run-image sections) and apply any number of images on a fairly complicated MCU configuration? (It reminds me a bit of the setup.inf scripting capabilities I added in Windows 2.0) I think that would be quite intriguing for more sophisticated MCUs, but I would expect very constrained MCUs (like the one targeted by MCUBoot) to use a special purpose installer. But because the "script" portions of the manifest are optional, none would need to be present for those cases, correct?
>
> Here are a few specific comments and questions:
>
> * Component Id
> I understand the first parameter is a bstr for name, but what's the second (numeric) parameter? Is that some type of offset? Did I miss the explanation for this parameter?
>
> * URIs
> If you need to install 10 images, the URIs take up a lot of space and there is a good chance they all have the same base URL. How about allowing to specify the base URL and append the component name to that URL?
>
> * Dependency, Unpacking...
> The examples are very useful, but only cover a few manifest options. Can you provide some more examples to cover dependency blocks, unpacking, run_sequence etc?
>
> Thanks
> Martin
>
>
> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Brendan Moran
> Sent: Tuesday, March 12, 2019 3:35 AM
> To: [e-mail]
> Subject: [Suit] Introducing draft-moran-suit-manifest-04
>
> draft-moran-suit-manifest-04 has now been published.
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-moran-suit-manifest-04&amp;data=02%7C01%7CMa
> rtin.Pagel%40microsoft.com%7Cb7d6c8c8dc1741cca1ba08d6ae18e79b%7C72f988
> bf86f141af91ab2d7cd011db47%7C1%7C0%7C636887819324535098&amp;sdata=tMjo
> 5LUmW7WDoK%2BxK0XeiYNA4v5AR0QREOc95SzfZUE%3D&amp;reserved=0
>
> This draft is the result of combining the information model in draft-moran-suit-behavioural-manifests-00 (the 01 version fixes example formatting only) with that in draft-ietf-suit-information-model, then serialising the result in CBOR. This is a significant departure from previous drafts. It attempts to preserve flexibility, fully define the behaviour of recipient, simplify the manifest structure, reduce code-size of the recipient, and reduce the size of the manifest. This ambitious set of goals required a significant change in approach as compared to draft-moran-suit-manifest-03 and before. In order to outline the approach clearly, we have separately published draft-moran-suit-behavioural-manifests-00. draft-moran-suit-manifest-04 focuses more on the serialisation of the manifest.
>
> I look forward to discussing this draft in more detail.
>
> Best Regards,
> Brendan
> 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.
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7CMartin.Pagel%4
> 0microsoft.com%7Cb7d6c8c8dc1741cca1ba08d6ae18e79b%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C636887819324535098&amp;sdata=gYTNV%2F5csvYdPf
> OYcaco4G5AUL2SyZVaSRataXxQ960%3D&amp;reserved=0

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.