Subject: [Suit] Question about SUIT WG deliverable

From: Basavaraj Patil <[email-masked]>
Date: Thu, 7 Jun 2018 12:44:55 -0500

Sec 7 of I-D: draft-ietf-suit-architecture-00 shows an example flow
depicting the end-2-end process of firmware updates of an IoT device.

Will the SUIT WG develop the protocol/signaling that is depicted in Fig 4
of the I-D?

-- 
Basavaraj Patil

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 7 Jun 2018 20:28:20 +0200

Hello Basavaraj,

to establish a basis, I will quote the 2nd last paragraph of the charter.

> This group does not aim to create a standard for a generic application software
> update mechanism, but instead this group will focus on firmware development
> practices in the embedded industry. Software update solutions that target
> updating software other than the firmware binaries (e.g., applications) are
> also out of scope.

This might seem to imply that conveyance seems to be mostly out of 
scope. The interaction model in the architecture seems most certainly to 
indicate otherwise.

And I think there is a very good reason for this. The content of the 
manifest depends on its applications. If it is declarative guidance to 
be consumed by the target only, it can be minimal and very specific. If 
it is created in work-flows and distributed by entities that discover, 
validate, trust, pull/poll (or some hybrid of it) it in a way that is is 
a container for the actual firmware, it might require different 
conveyance procedures (and manifest content) than if it would "just" be 
pointing to the correct firmware (e.g. via URI) and acts as a type of 
imperative guidance to where to discover which payload that fits your 
"to-be-updated" thing appropriately at a given time.

In a nutshell, SUIT might not mandate or even create specific protocols 
to achieve successful update campaigns. But depending on the application 
of the manifest, there might be multiple work-flows / interaction models 
and trust relationships defined by the SUIT WG in order to get that done 
reliably and trustworthy.

This is an answer of a single individual. Dear WG, please comment about 
anything that might be wrong about what I just wrote :)

Viele Grüße.

Henk

On 06/07/2018 07:44 PM, Basavaraj Patil wrote:
> Will the SUIT WG develop the protocol/signaling that is depicted in Fig 
> 4 of the I-D?
> 
> -- 
> Basavaraj Patil
> 
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 7 Jun 2018 15:50:16 -0500

Thanks Henk.

While the charter itself is clear about not defining a protocol between the
device and the server(s) that store the firmware images, I think it will be
a shortcoming.
The charter statement:
"
This group will not define any new transport or discovery mechanisms,
but may describe how to use existing mechanisms within the architecture.
"
may alleviate the problem to some extent.

However in the absence of a well defined protocol (in addition to the
current goals of the charter), problems of interoperability and lack of
adoption are what I fear.
It would make sense to at the very least have a recommended protocol and
approach that aligns with Fig 4 of the architecture.

Rgds,
-Basavaraj

On Thu, Jun 7, 2018 at 1:28 PM, Henk Birkholz <
[email-masked]> wrote:

> This might seem to imply that conveyance seems to be mostly out of scope.
> The interaction model in the architecture seems most certainly to indicate
> otherwise.
>
> manifest depends on its applications. If it is declarative guidance to be
> consumed by the target only, it can be minimal and very specific. If it is
> created in work-flows and distributed by entities that discover, validate,
> trust, pull/poll (or some hybrid of it) it in a way that is is a container
> for the actual firmware, it might require different conveyance procedures
> (and manifest content) than if it would "just" be pointing to the correct
> firmware (e.g. via URI) and acts as a type of imperative guidance to where
> to discover which payload that fits your "to-be-updated" thing
> appropriately at a given time.
>
> In a nutshell, SUIT might not mandate or even create specific protocols to
> achieve successful update campaigns. But depending on the application of
> the manifest, there might be multiple work-flows / interaction models and
> trust relationships defined by the SUIT WG in order to get that done

-- 
Basavaraj Patil