On 08/12/2016 19:11, Juergen Schoenwaelder wrote:
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.
Alas I don't think that this would help. The aim is that the
information is still available on production systems, just not returned
by default.
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.
Assuming that diagnostics information was specified for each of N
different protocols on a device. Then this would seem to mean that
every device would have to install N default NACM deny entries (one for
each supported protocol) to ensure that the device has sensible default
operator semantics. This would seem to be quite a burden on the industry.
A solution that doesn't rely on every server inserting lots of NACM
entries by default seems like a better choice to me.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
