On Fri, Sep 11, 2015 at 08:48:55PM -0700, Andy Bierman wrote: > > All solutions expect the server to be able to determine applied status for > every leaf > in the intended config. All solutions require basically the same internal > API support > to check the relevant applied config or operational state. > > In every solution, the server will magically know how to check that the IP > address is active. > That's the point. It is better than forcing the client to know how to do > this for every type of server. > > IMO, this requirement is clear, and each draft has a solution approach for > this new API. >
For resources residing somewhere in an OS kernel (e.g. IP addresses of an interface), a proper implementation would require that the kernel knows why the resource is there and not just the fact that the resource is there. If I take an average resource in the Linux kernel, then this information is not kept in the kernel. Daemons and user space application simply create and modify resources in the kernel and then the kernel does what it does. So how would I implement an applied datastore on such a kernel? One obvious option would be that I simply grab the operational state and I match it against the intended config and everything that matches I report as applied config. Of course, this may go wrong in certain cases if there are clashes or the mapping is not trivial 1:1. But unless the piece of code that manages the underlying resource has a way to maintain and manage meta information, this is probably the best an implementation will be able to do. Or am I missing something? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
