Hi Balazs, Andy, Quifang, > I agree a new datastore will just add complexity without any value. > Your solution approach is better, but I think it would require a new YANG > version > to allow config node XPath to reference non-config nodes.
In no case is there a need for a config Xpath to ref non-config. > Another solution is to model the referenced node as config=true, but setup > automatic NACM rules so no user editing is allowed. This works well for > setting up an initial config that gets saved and not changed unless a reset > is done. I don’t like the NACM dependency. > What if <intended> is what is NV-stored? When that occurs, the config > changes from system to user config. > Routers have been saving the combined config for decades. IMO the standards > intentionally avoid discussing the conversion of a datastore to/from > NV-storage. I’m unsure about this point, but a don’t see any dependency on an NV-store needing to use a particular encoding or format. > As I see it this is the same problem that we discussed in > https://github.com/netmod-wg/yang-next/issues/41 > <https://github.com/netmod-wg/yang-next/issues/41>. > > I know this is a radical change, but I think using a new YANG extension to > create a read-only config=true datatype is a much cleaner solution. One which > some companies have already implemented. > > +1 > > Actually, separate running and system would be a radical change, not this. > Cleaner and less disruptive. I disagree with the need to resolve issue #41 here, and I disagree a <system> datastore would be a radical change, or even complicated. That said, something like RFC 6243 (with-defaults) but called “with-system” could work. That is, the “system" config is like <running> config that is hidden until asked to be revealed. It would be interesting to discuss if “with-defaults" returns all of the system config, or just the parts that are used, assuming we define “used” appropriately. Presumably system-defined ordered-list entries cannot be ordered by user, or used as before/after pivots. We could even do both: have a read-only <system> datastore *and* a "with-system" interaction API. Each complimenting the other. FWIW, a "with-system <running>” still may not pass validation if, e.g., templates need to be expanded. Of course, any controller/orchestrator can expand the templates themselves to resolve that concern. Such a system could also fetch <system> without skipping a beat. Thought exercise: a controller is managing 1000 endpoints all running the same software version. Is it better for the controller to get "with-system <running>” 1000 times, or get <system> once and have knowledge for how its merged in? K.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
