Hi Brian, I have just published v14. It should address your comments as follows: > 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. This can be done either using per-configured hosts, or using a discovery mechanism such as DNS-SD: > Devices also require a mechanism to > discover the status tracker(s) and/or firmware servers, for example > using pre-configured hostnames or [RFC6763] DNS-SD. And, for the second comment >> 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? This is addressed (perhaps somewhat indirectly) in the list of areas that fall outside the IETF’s efforts, but do require consideration: > * Ensuring that firmware updates addressing critical flaws can be > obtained even after a product is discontinued or a vendor goes out > of business. Fundamentally, this requirement must be enabled by the trust provisioning authority. They must be responsible for ensuring continuity of service in the event that a firmware author becomes unresponsive to defects for any reason. Best Regards, Brendan 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
