On Tue, Nov 30, 2021 at 02:24:52AM +0000, Kent Watsen wrote: > Hi Juergen, > > > > On Nov 29, 2021, at 6:49 PM, Jürgen Schönwälder > > <j.schoenwael...@jacobs-university.de> 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) | > +---------------+ >
Your first paragraph does not match the figure. In your figure, system config does not go into <running> instead it goes into a magic merge box which is not shown (there is just an arror pointing to an arrow) and then the result goes into intended. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
