Re: [OPSAWG] [Mud] Declaring something to be a controller in MUD

[Michael Richardson <[e-mail]>]

Eliot Lear <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-