Hi Brian,
For the distributed version I have focused on addressing comments raised by Bob first.
However, I have changed the definition of the status tracker and it is not an optional component anymore.
Here is the new definition:
- Status Tracker: The status tracker has a client and a server
component and performs three tasks: 1) It communicates the
availability of a new firmware version. This information will
flow from the server to the client.
2) It conveys information about software and hardware
characteristics of the device. The information flow is from the
client to the server.
3) It can remotely trigger the firmware update process. The
information flow is from the server to the client.
You wrote: "But I still don't understand how the target device and the status tracker (or server) discover each other."
The discovery today works mostly by using pre-configured servers. However, dynamic discovery techniques have been proposed (e.g. in ANIMA and in FIDO).
I hope this makes sense.
Ciao
Hannes
-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Sent: Tuesday, October 13, 2020 10:15 PM
To: Hannes Tschofenig <Hannes.Tschofenig@xxxxxxx>
Cc: last-call@xxxxxxxx; draft-ietf-suit-architecture.all@xxxxxxxx; Bob Briscoe <ietf@xxxxxxxxxxxxxx>
Subject: Re: Last Call: <draft-ietf-suit-architecture-11.txt> (A Firmware Update Architecture for Internet of Things) to Informational RFC
Hi,
I can't see any changes in the proposed -13 version that respond to my comments below. I do see that the example that suggested operating without a status tracker has vanished. If the status tracker is now considered essential, that probably needs to be stated. But I still don't understand how the target device and the status tracker (or server) discover each other. This seems like a fundamental part of the architecture.
Regards
Brian Carpenter
On 29-Sep-20 11:34, Brian E Carpenter wrote:
> Hi,
>
> I can't see any changes in the -12 version that respond to my comments below.
>
> Regards
> Brian Carpenter
>
> On 25-Jul-20 11:31, Brian E Carpenter wrote:
>> Hi,
>>
>> I don't understand from the architecture discussion how a firmware
>> consumer discovers the firmware server, especially in the unmanaged
>> (no status tracker) case. It can't be preconfigured, in case the
>> firmware server changes for some reason.
>>
>> Not unrelated:
>>
>>> Installing trust anchors to
>>> devices via the Trust Provisioning Authority happens in an out-of-
>>> band fashion prior to the firmware update process.
>>
>> What happens when the firmware originator goes out of business and
>> somebody else takes over support, or for any other reason the trust
>> anchors become obsolete?
>>
>> Regards
>> Brian Carpenter
>>
>> On 25-Jul-20 10:30, The IESG wrote:
>>>
>>> The IESG has received a request from the Software Updates for
>>> Internet of Things WG (suit) to consider the following document: -
>>> 'A Firmware Update Architecture for Internet of Things'
>>> <draft-ietf-suit-architecture-11.txt> as Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits final comments on this action. Please send substantive
>>> comments to the last-call@xxxxxxxx mailing lists by 2020-08-14.
>>> Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In
>>> either case, please retain the beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>> Vulnerabilities with Internet of Things (IoT) devices have raised the
>>> need for a solid and secure firmware update mechanism that is also
>>> suitable for constrained devices. Incorporating such update
>>> mechanism to fix vulnerabilities, to update configuration settings as
>>> well as adding new functionality is recommended by security experts.
>>>
>>> This document lists requirements and describes an architecture for a
>>> firmware update mechanism suitable for IoT devices. The architecture
>>> is agnostic to the transport of the firmware images and associated
>>> meta-data.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/
>>>
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce@xxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
