Re: [netmod] Must offline-validation of <running> alone be valid?

[Kent Watsen <[e-mail]>]

> On Dec 8, 2021, at 5:50 PM, Andy Bierman <[e-mail]> 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.