Hi Juergen,
> On Nov 29, 2021, at 6:49 PM, Jürgen Schönwälder > <[email protected]> wrote: > > On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote: >> >> IMO the least disruptive solution possible should be used. >> There is a use-case for adding "origin" support to the <running> datastore >> in the <get-data> operation. >> This allows an NMDA client to identify system config that is not being used >> in <operational>. >> > > Looking at Figure 2 of RFC 8342, I wonder how system config gets into > running - other than a client writing it into running, at which point > the config becomes explicit config subject to the usual update rules > of <running>. Conceptually, you can have a system daemon acting as a > client updating <running> (perhaps even controllable by NACM). The > "origin" was not designed to track from which application config data > in <running> is originating, that's to be solved by other mechanisms. This idea is to mimic RFC6243’s “default” annotation and the "with-defaults" RPC. Just like with the “explicit” mode server, if a client writes to <running> and default value w/o the annotation, the server assumes it is explicit config (not the default anymore). Same here, if the client writes a “system” node w/o the annotation, the server assumes it is explicit config (not the <system>-defined node). In both cases, if the client includes the appropriate annotation, and the value/node matches the default/system value, then the server assumes that it’s actually the default/system value/node. FWIW, about 5 months ago (June 29), I offered this modified version of Figure 2 (Note the <system> box on the left). The “underlay” comment is meant to imply that <running> always overrides <system> when they’re merged: +-------------+ +-----------+ | <candidate> | | <startup> | | (ct, rw) |<---+ +--->| (ct, rw) | +-------------+ | | +-----------+ | | | | | +-----------+ | +-------->| <running> |<--------+ | (ct, rw) | +-----------+ | +----------+ | // configuration transformations, | <system> |-------------->| // e.g., removal of nodes marked as | (ct, ro) | // underlay | // "inactive", expansion of +----------+ | // templates v +------------+ | <intended> | // subject to validation | (ct, ro) | +------------+ | // changes applied, subject to | // local factors, e.g., missing | // resources, delays | dynamic | +-------- learned configuration configuration | +-------- system configuration datastores -----+ | +-------- default configuration | | | v v v +---------------+ | <operational> | <-- system state | (ct + cf, ro) | +---------------+ K.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
