Hi Brendan, On 22-Oct-20 03:24, Brendan Moran wrote: > 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. Thanks. As I mentioned, this is also a problem we could easily solve with the ANIMA mechanisms too, in a fully autonomic network. > 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. Yes, that covers it I think. For information only, ANIMA has a similar problem, discussed at https://www.ietf.org/archive/id/draft-ietf-anima-bootstrapping-keyinfra-44.html#name-updating-or-extending-vouch Thanks Brian -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
