Hi Michael, Below.
On 5/23/17 4:23 AM, Michael Richardson wrote: > 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. That was the idea. Think a major consumer product manufacturer that has many different products. This doesn't require the manufacturer to create a domain per product. > >> 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? That is- there is a single manufacturer certificate but distinct extensions that both contain URIs but might point to different places (indeed that would be the point). > > >> 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? > Yes. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
