On Thu, Dec 08, 2016 at 05:49:11PM +0000, Robert Wilton wrote: > > On 07/12/2016 16:13, Juergen Schoenwaelder wrote: > > On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: > > > Alas, xpath filtering is optional, and I'm not sure how many devices have > > > implemented support for it. Further, this still requires every client to > > > be > > > coded to avoid receiving the information that they are very unlikely to be > > > interested in. > > > > > > I would much prefer a solution where the clients don't get this (mostly > > > noise) data unless they explicitly ask for it. Otherwise for an Ethernet > > > interface you might return 10 leaves of potentially useful opstate > > > information, along with 50+ leaves of quite low layer diagnostics > > > information that is likely to be of very little use except for to the > > > select > > > few people that are actively involved in trying to diagnose hardware > > > faults. > > > > > I expect that there will be many augmentations to lets say /interfaces > > (or /interfaces-state). How does a data model writer determine which > > ones are 'noise' and which ones are not? How does a a data model > > writer determine which ones are costly to implement and which ones are > > not (since this may vary widely between systems)? > It isn't so much as it being noise. I see that the two quite different sets > of config false nodes are: > > (1) The first set of nodes are those that are useful to a client to manage a > device and to determine whether the device's actual behaviour matches the > expected behaviour based on the configuration. This is the same set of data > that has traditionally been modeled via SNMP, and I think of as being the > operational state of the device. > > (2) If it is determined from the nodes above that a device is behaving in an > abnormal way, then the second set of nodes are aimed at device > developers/engineers to ascertain why the device is not behaving as > specified. A lot of this internal diagnostics information may only be of > use to a developer who is familiar with the code (or intricacies of the > hardware), and/or has a deep level of understanding of how a particular > feature works. I would see that most of this information is very likely to > be device specific, and presented in a device specific way, and may include > internal debug and dumps of internal data-structures.
The simply disable this module on a production system. > I believe that most of the time, operators are only interested in > interacting with that first set of data because that is all that is useful > and required to manage their devices, and hence that is what I think should > be modeled in the operational state datastore. However, in many cases, > having a standard automated way of fetching that second set of data is still > useful, because it facilitates more efficient diagnostic tools to be created > in the future. Than leave the data model active and make NACM grant access to this data only for engineers. /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
