> On 26 Jun 2019, at 23:26, Michael Richardson <[email protected]> wrote: > > > Eliot Lear <[email protected]> wrote: >>>> There will ALWAYS be a need for an administrator in the enterprise >>>> case. But maybe with the options above we can ease the consumer burden >>>> over time. In the consumer case, you might want an app for initial >>>> device admission control anyway, no? Can we not rely on that >>>> interaction as an approval step in this instance? >>> >>> I think we'd all like to have a generic app (with an RFC standard API) that >>> can onboard any device and can do admission control for any controller. >>> I think this is what you are saying as well. > >> Yes, but I was saying a bit more. Do you expect to fully automate the >> inclusion of a controller into a controller class in the home? How do >> you envision the full flow looking like? > > I expect to fully automate the inclusion of a controller into that class, > yes. I'd like to automate the device into the class too. > > Perhaps your point is that since the controller has to onboard (at the > layer-7) the device in anyway: can we leverage that?
For devices that are designed as controllers, yes. > >>> yes, this is exactly what I was thinking about. >>> >>> Would "mud-urls" / "include" be mutually exclusive? > >> I don’t see why it would have to be. But now let’s back up, just to >> make sure we’re not digging too deep a hole for the application case >> that Ranga wants to get to. If the MUD protected device is declaring >> MUD URLs for MUD controllers and that is what all of this would boil >> down to, then the app case is really a completely separate mechanism, >> because apps don’t have MUD-URLs. > >> If we do a two-stage, then we need a completely separate draft for apps >> anyway, but I was hoping for some commonality. > > Hmm. > Indeed. But let’s not get wrapped around the axle here. I’ll try and have something out for the controller case, and then let’s talk about the other in Montreal. Ok? Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
