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
