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 >>> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
