> On Dec 8, 2021, at 5:50 PM, Andy Bierman <[email protected]> wrote: > > Andy - about use cases. Here is a problem we're trying to address: > > > > There are at least several major router implementations that have this > concept of "hidden config" (i.e. list entries that can be referenced in a > leafref by explicit user config, but those list entries are not returned in a > <get-config>). > > > Clearly not in compliance with RFC 7950.
Andy, can you please point to the part in RFC 7950 that says offline validation must be supported? I believe that this "common understanding” actually lacks a basis, and an equally-valid interoperation is that the <running> must be valid *on the server* vis-a-vis it actually validating <intended>. > IMO the "enable flag" approach to the general problem, presented by Kent a > couple years ago, > is a much simpler and better solution than a new <system> datastore. > The full set of nodes is in <running>. > A generalized "enable" mechanism causes the resource to be used or not, > where it shows up in <intended> and <operational> if enabled=true. > > IMO this fits the original intent of NMDA and does so in a way that requires > the least disruption to current compliant implementations. You have the memory of an elephant ;) That I-D (conditional-enablement [1]) was mostly about how to support JUNOS’s “inactive” annotation. I replaced the negative “inactive” with positive “enabled” for readability. That draft also shined a light on how the “enabled” annotation could be used in firewall pollination for, e.g., 9am-5pm ACL rules. I guess I’m unclear about the relation to the system-defined config - can you say some more? [1] https://datatracker.ietf.org/doc/html/draft-kwatsen-conditional-enablement-00 <https://datatracker.ietf.org/doc/html/draft-kwatsen-conditional-enablement-00> K.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
