Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)

From: Brendan Moran <[email-masked]>
Date: Tue, 7 Nov 2017 22:55:01 +0000

Hi Henk,

Just yesterday I met with a vendor that does firmware upgrades in isolated computing context slices of singular things - and they were amazed that "providing the capability of indicating block-device lables/indexes", "block-offsets in a block-device" and semantic relationships, such as "requires", "supersedes", or "patches" is not an obvious thing to be included in a manifest. The literal question they voiced was: "Why going through the hassle of creating a manifest for metadata, if you are not going to put useful metadata in it?" And I could understand their point of view.

[Hannes] I am not sure I understand their comment.

[Brendan] These concepts are partially built-in to the manifest format already. Where a filesystem is present, the StorageIdentifier can absolutely be interpreted as a filesystem path. Where only block devices are present, it can be a block-device label/index. Providing for an offset beyond that can be done in two ways: either with a string format in the StorageIdentifier, or with a directive, that states “block device offset”.

[Brendan] "requires", "supersedes", or “patches” can (and should) be implemented as conditions.

Additionally - on one hand - I would like to support the term claim in respect to the mix of terms highlighted by Martin:

> It's not just terminology.  There are three discrete fields in the
> draft for conditions, directives and extensions.  I am suggesting that
> there only needs to be one.

[Brendan] Conditions and directives have a semantic difference: Conditions are evaluated before acceptance of a manifest. Directives are executed after acceptance of a manifest. This is a distinction that is trivial to implement and simplifies processing on the target device. I believe that this is sufficient to justify splitting the field.

On the other hand, I am not so certain about this statement, Martin:

> storageIdentifier seems especially problematic.  If you have a device
> type identifier, then that should suffice for those cases where there
> are multiple update targets on a device.  That is, you can identify by
> generically identifying the type of thing that this update applies to:
> "vendor foo alarm clock configuration" rather than "vendor foo alarm
> clock" and it all works neatly.  Right now the storageIdentifier is
> all tied up in the way that the update is identified.

Optional standard claims that MAY be used to provide additional semantics to a manifest do not sound so bad to me. Am I missing something here?

[Hannes] Martin would like to combine elements while we had proposed to separate them. To me it feels like defining an attribute 'name' vs. having two attributes, 'first name' and 'last name'. I personally don't have a strong opinion about this topic.

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.