Subject: [Suit] suit charter points

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Nov 2017 10:05:22 +0100

To repeat my comments on the mike in the BOF:

1. I would like to make sure that the charter allows for the following two points to
be defined into the architecture mentioned by the charter, even if not
all devices may be able to support them. IMHO these are mandatory for really
reliable firmware upgrade and it would be a wasted opportunity to do all this work
and yet only produce results for devices thart will not provide real reliable
ugprade solutions.

a) Ability for automatic downgrade, eg: automatic unless some external verification of
correct operation of the new firmware has succeeded. Ideally, verification of
the new firmware is trial-run download of yet another firmware image or the
like.. 

b) ability to query the device for capabilities thart will allow to understand
what firmware/signing/etc of a firmware will be accepted by the device.

2. Wrt to "new" components: Instead of saying "charter does not allow new work XXX"
(XXX = transport, serialization etc..). A better rule would be not do something new unless
evaluation shows that new work is required especially because of footprint of existing
solutions being too large for class 1 devices.

Toerless

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 14 Nov 2017 03:04:44 +0000

Comments are inline below marked DAW.

Thanks,

Dave

________________________________
From: Suit <[email-masked]> on behalf of Toerless Eckert <[email-masked]>
Sent: Monday, November 13, 2017 5:05 PM
To: [email-masked]
Subject: [Suit] suit charter points

[DAW: (As chair) The charter does not prevent a resulting solution from supporting these capabilities. If chartered, the group will need to discuss this as part of our work on the architecture.

(as a participant) I believe there is room for this proposed working group to develop guidance on why some of these features are desirable, and to discuss how the solution may be used to support these features.]

[DAW: (as chair) I think we need to do more work in this space before we get to a point where this might even be proven true. If we discover gaps in existing work, we can always recharter in the future to take on new work, or work with other WGs (or SDOs) to address these gaps, whichever is most appropriate.]

Toerless

_______________________________________________
Suit mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C63f0c192ac66414c728508d52a75b1bd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636461607336306761&sdata=vHfdE3BsiYP%2BQxpMgg%2BgU8fpRi2vXPHy7DaNVpDs9W8%3D&reserved=0

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2017 06:19:24 +0000

Hi Toerless,

> a) Ability for automatic downgrade, eg: automatic unless some external verification of correct operation of the new firmware has succeeded. Ideally, verification of the new firmware is trial-run download of yet another firmware image or the like..

[Hannes] Wouldn't this be an implementation detail?

> b) ability to query the device for capabilities thart will allow to understand what firmware/signing/etc of a firmware will be accepted by the device.

[Hannes] I am trying to understand what you are trying to design here. Do you expect the firmware update server to reach out to IoT devices, to ask them for the firmware version being installed, and then send a firmware update?

Ciao
Hannes

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.