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?
>> 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.
--
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
