Ladislav Lhotka <[email protected]> writes: >> Tom, >> >> I think Andy is talking about applicability - to which kind of servers >> do these requirements apply. For example, if it takes more time on a >> certain class of devices to retrieve the difference between applied >> and intended config than it takes to turn intended config into applied >> config, then these requirements may not be applicable (since by the >> time you have finished retrieving the difference it has vanished). > > I think it is not only matter of synchronisation delays between intended > and applied configuration. I have serious troubles understanding how > these concepts map to the class of devices I am mainly interested in. > > Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF > server that supports intended and applied config. Assume the server > implements modules of the acl-model family so that firewall rules can be > configured through NETCONF/RESTCONF. Great. > > Now an admin runs "iptables" to manipulate netfilter rules in the > kernel. How does it affect the applied and intended configurations? > > A. The change isn't reflected in applied configuration. Then applied > configuration is no more "…, the configuration state which is > currently being used by server components (e.g., control plane > daemons, operating system kernels, line cards)." > > B. The change is reflected in applied but not in intended > configuration. This violates requirement 1 sub D, and also it may be > impossible to map the kernel changes back to the configuration. > > For sure, these problems exist also with the good old "running", but I > think the migration to intended-applied would just make things worse.
Perhaps I'm misunderstanding the example, but it seems you have a setup where your netconf/restconf server isn't in sync with actual configuration of the device, regardless of whether is implements these requirements or not. Why isn't this a non-starter? I mean it seems to me that you don't need to worry about new operational state requirements until the most basic functionality is working. Thanks, Chris. > > Lada > > >> >> Andy, did I get this right? >> >> /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/>
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
