Hi Ranga, Robert wrote a great review, and I'll respond to him in due course with suggested changes. I wanted to take just a moment to comment to you on your point:
On 8/31/17 12:00 AM, M. Ranganathan wrote: > > > On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <[email protected] > <mailto:[email protected]>> wrote: > > > > Right now, you leave the DHCP server (when it's used) responsible for > clearing state in the MUD controller. Please discuss what happens when > those are distinct elements (as you have in the end of section > 9.2) and > the DHCP server reboots. Perhaps it would make sense for the DHCP > server > to hand the length of the lease it has granted to the MUD > controller and > let the MUD controller clean up on its own? > > > I would like to add a few words to the comprehensive review presented > by Robert Sparks (I hope it is proper etiquette on this list to do so). > > With respect to the observation above: > > There is also a cache timeout in the MUD profile. Does it make sense > that the MUD controller should take the minimum of the DHCP lease time > and the cache timeout and use that to time out the installed ACLs (?) > The DHCP server should also pass to the MUD controller, some way of > identifying the device to which the lease has been granted (for > example the MAC address of the device). > > The draft also not specify how the DHCP server will communicate with > the MUD controller (presumably via a simple REST interface but what is > the URL to be used and how are the parameters passed?). I think this > should be specified for interoperability between DHCP clients and MUD > servers. Maybe words describing this interaction can be added here. That's right. At the moment, this is an "internalized" function. That is to say that the DHCP server is said to be tightly coupled to the MUD controller without standardized interfaces. In my first implementation, I literally just tailed dhcpd syslog entries and triggered MUD based on DHCPREQUEST messages. Clean-up state had to do with RELEASE or periodic SNMP queries. Our implementation at Cisco does something different. However... if the OPSAWG would like, and there is interest, we can formalize that interface. I don't want to do it in THIS draft (it's already fairly involved), but there's nothing to say we couldn't do some follow-on work. Fair enough? Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
