On Fri, Dec 09, 2016 at 11:46:39AM +0000, Robert Wilton wrote: > Hi Juergen, > > Please can you expand on your proposed solution if using just one NACM > entry.
Perhaps we talk past each other because 'NACM entry' is ambiguous. I mean one 'rule-list' entry, you probably mean N 'rule' entries. > > And why would N hard coded toggles > > in data models be simpler and not a burden for the industry? > 1. Because by default there is no additional filtering cost to excluding > diagnostics data from get/push requests on the operational state datastore. > 2. The names of the RPCs could be defined by convention, and hence handled > in a generic way. I generally dislike any solutions that relies on 'naming conventions'. > 3. Defining RPCs isn't my preferred solution, but it feels like the most > pragmatic one available today. I think that diagnostics is a fundamentally > different level of operational state data that may be better served using a > separate datastore that sits below the operational state datastore. I.e. it > "sees" everything in the operational state datatstore but also contains the > extra diagnostics information as well. The diagnostic specific nodes would > be marked in the schema, same as config, i2rs, etc, presumably defined in a > YANG extension. Perhaps you just want to dynamically enable/disable data models supported by a device? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
