> On 1 Jul 2019, at 09:20, Qin Wu <[email protected]> wrote: > > 发件人: OPSAWG [mailto:[email protected] <mailto:[email protected]>] > 代表 Eliot Lear > 发送时间: 2019年6月24日 17:48 > 收件人: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 主题: [OPSAWG] Declaring something to be a controller in MUD > > Hi everyone, > > A few of us are just trying to put out an initial draft that addresses one > gap in MUD (there are several). In a MUD file one can say that one wants to > access a controller in two ways: either "my-controller” meaning a controller > that services devices of a particular MUD URL or a “controller” class that > services devices based on a particular class name of controller. > > In either case, right now the administrator has to manually know and populate > information, to say - some device 1.2.3.4 is a controller, either for MUD URL > https://example.com/mud <https://example.com/mud> or a class > http://example.com/mudclass1 <http://example.com/mudclass1>. That can be > laborious. To assist, we are examining ways to have a controller declare > itself as a candidate controller. > > [Qin]: Since MUD in RFC8520 has already specify DNS extension and DHCP > extension, why not configure MUD manager with controller’s declaration? So > the RESTFUL interface can be defined between NMS and controller, if my > understanding is correct. > I believe this is network initiated solution, you might have client initiated > solution, but probably more complicated than network initiated solution.
Can you say a few more words? I’m not sure I’m quite following you. Eliot > > That at least provides a hint to the administrator that this particular > device is capable of serving in a particular role. > > To make that declaration, the device must- > Form the declaration; > Find the MUD manager; and > Send it. > > Forming the declaration is easy: we can make this a YANG grouping and then > place it in various spots. > > Finding the MUD manager depends on one question: > Was the device built to be a controller or is it a general purpose device > that has an app that is intended to be a controller? > > If the device was built to be a controller, we can simply cram the > declaration into that devices own MUD file as an extension. If the device is > a general purpose computer, things get a bit more interesting. In this case > we have two choices: > > Either create a MUD file that points somewhere internally - this doesn’t seem > very plug and play. > Make the declaration directly to the MUD manager. > > I’m going to focus on the latter for the moment. It is easy enough to create > a RESTful interface for this purpose, but it requires a mechanism to > discovered the MUD manager, which up until now has been an internal part of > the network infrastructure. > > Let me call this out plainly: letting the app itself directly call the MUD > manager requires that the MUD manager itself become exposed to the user > infrastructure, which is a change. > > One possibility to address this is to incorporate the new RESTful endpoint > into an ANIMA BRSKI join registrar, which may already be exposed. But that > requires that ANIMA BRSKI be in play, which it may not. > > My thinking is that we do this work in two stages. First handle the easy > case, which is the MUD file extension, and then figure out how to do the app > version of this. > > Thoughts? > > Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
