Nick Hilliard writes: > > What's relevant to the IETF is that it needs to make sound technical > recommendations about the usability and appropriateness of standards. > If organisations choose not to keep supporting some or all of their > product lines, this shouldn't impact the IETF's ability to do its job. > > Nick However governments are busy writing up standards for managing the secure deployment of devices. The UK's DCMS has been working on this for a couple of years The local ISOC chapter has been engaging on this. On that count IETF participants might like to keep engaged with those ISOC chapter liaisons? Who I'm sure would be grateful for informed input as well. As a general observation the issue of vendors falling away from supporting devices is at odds with the promoted market model of licensing IPR and maintaining restrictions over IPR after support falls away. Unless that IPR becomes public domain - or opened at least in regards the scope of empowering the right to repair etc. The practicalities of that is something IETF can think through as part of its IPR policies? Another observation is that manufacturer/vendors who force updates on their devices will tend to consider their own devices not others which in context of "IoT" are very likely to also be interoperating from other vendors or FOSS / hardware. That creates space for lots of stools for security to fall between. The issues around interoperability also means serving the responsibility of user administrators across whatever pool of vendors or FOSS supply chains they choose to deploy and commission support. Depending entirely on each vendor you use has never been a good idea if you want a functional system. So specifications to serve interoperability in terms of securing real world installations of devices running from a selection of IETF defined protocols is something IETF can think about too? For discussion? I would expect that thinking to not assume "vendor" lock in but empower user administrated support in concert with vendor support (if chosen (not imposed)) as long as that is available and faciitate open alternatives particularly when that falls away. This also seems a point where IETF specifications can offer guidance. C -- Christian de Larrinaga -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
