On Mon, Dec 13, 2021 at 5:31 PM Kent Watsen <[email protected]> wrote: > > > 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>. > > I think sec. 6.4 and sec. 8 are clear enough how validation of the <running> datastore is done. Leafrefs in <running> are not allowed to point to a node outside of <running>.
Andy > > 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 > > > K. > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
