> FWIW, JUNOS “solves” this by *hiding* these system-nodes, such that > clients must use a special command just to discover them. And, yes, if ever > any of these are hidden-nodes are reference, offline-validation of <running> > will fail.
Other implementations have a similar concept with the same consequence. > The <system> datastore being discussed effectively mimics this > aspect of the JUNOS solution. > > There is a separate thread for if *offline* validation of <running> *alone* > must succeed. The soft (fallback) solution is to have clients copy/paste the > referenced-subset of the system-defined nodes into <running>. The theory > being that, since it’s just a subset, it won’t clutter things up too badly > and, as > it is already the case that some system-defined nodes must be copy/pasted > into <running> in order for clients to configure descendent nodes (e.g., some > tunable for the system-defined “lo” interface), the water is already over the > bridge, so to speak, on the copy/pasting debate. The only holdout for not > already demanding client’s also copy/paste the subset of referenced system- > defined nodes is that it is completely unnecessary, unless trying to ensure > offline validation of <running> alone. Yes - so only users/clients with this requirement would need to explicitly configure the referenced subset. Anyone else can just do nothing and continue on as they do today. Jason > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Kent Watsen > Sent: Monday, November 29, 2021 5:50 PM > To: Andy Bierman <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Should the origin="system" be required for system > configurations copied/pasted into <running>? > > Hi Andy, > > > RFC 7950 rules about leafref validation are very clear. > > Adding a new datastore to these rules requires a massive change to NMDA > > and all implementations. > > Not really or, rather, it seems like it would be just part of adding support > for > <system>, which implies adding support for <intended> (if not supported > already) and doing the validation on <intended> instead. > > > > 2) As Juergen points out, servers populate the system config in <running> > and the operator is > > free to ignore it, reference it, or possibly change it. The premise of > <system> seems to > > be that this approach is not "pure enough" for NMDA and <running> MUST > only contain > > operator-created configuration. Why? What real problems would this > change solve? > > Servers populating <running> (beyond coping <startup> into <running>) has > never been a supported idea. We’ve always maintained that <running> > should only contain client-provided config, right? > > I’m unsure what the “change” in your last question points to. But note that > on JUNOS-based systems, there are many hundreds of system-defined > nodes available to be referenced by config in <running>. Putting all these > nodes into <running> would clutter the config immensely. > > FWIW, JUNOS “solves” this by *hiding* these system-nodes, such that > clients must use a special command just to discover them. And, yes, if ever > any of these are hidden-nodes are reference, offline-validation of <running> > will fail. The <system> datastore being discussed effectively mimics this > aspect of the JUNOS solution. > > There is a separate thread for if *offline* validation of <running> *alone* > must succeed. The soft (fallback) solution is to have clients copy/paste the > referenced-subset of the system-defined nodes into <running>. The theory > being that, since it’s just a subset, it won’t clutter things up too badly > and, as > it is already the case that some system-defined nodes must be copy/pasted > into <running> in order for clients to configure descendent nodes (e.g., some > tunable for the system-defined “lo” interface), the water is already over the > bridge, so to speak, on the copy/pasting debate. The only holdout for not > already demanding client’s also copy/paste the subset of referenced system- > defined nodes is that it is completely unnecessary, unless trying to ensure > offline validation of <running> alone. > > > > > Andy > > Kent, as a contributor. > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
