Re: [Suit] Question about SUIT WG deliverable

[Basavaraj Patil <[e-mail]>]

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 <
[e-mail]> wrote:

> 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:
>
>>
>> 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
>>
>>
>> _______________________________________________
>> Suit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/suit
>>
>>
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit
>



-- 
Basavaraj Patil