I've read through the thread. It took more brain-power that I've had available of recent.
Let me ask some clarification questions about the original proposal. I generally agree with Max that the /.well-known/ part can be omitted. I also prefer passive (static file) initial interactions so that the initial contact point can be most easily maintained over a period of decades. I was surprised when some proprietary uses like this would point at the www.example.com, rather than something more divorced from marketing, like a "bootstrap.example.com". So I rather like the mfg-services reply which is essentially a redirect which can be updated over the years. > https://example.com/.well-known/mfg/modelname > > which would return something like: > >{ > "mfg-services" : [ > "mud", "v1", "https://mud.example.com/Frobmaster3000.json";, > "anima", "v1", "https://masa.example.com/masa-service"; > ] >} correct? In this case, the modelname is there to distinguish phones From printers from home-routers, which might well be very separate divisions. > At the moment, more manufacturers are coming back to me to say that we > should just leave these as separate and distinct mechanisms. I think that's > the simplest approach. Distinct mechanisms, but common certificates? Or distinct certificates? > It seems to me the simplest way to handle this sort of thing is to create a > table that MUD/ANIMA controllers simply download when they see the URL. It > might look something like this: When you say ANIMA controller, I think you mean the JRC? -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
