Hi Andy,
On 09/12/2016 18:50, Andy Bierman wrote:
<snip/>
Why can't you use a when-stmt?
<top>
<diag-mode>system</diag-mode>
<service>
...
<diag-stats>
// config false
// when "/top/diag-mode = 'system'"
</diag-stats>
</service>
</top>
A when statement has two problems:
i) It affects all clients that are making requests to read the data (or
potentially YANG push subscription requests).
ii)) It turns on diagnostics everywhere.
I don't believe that you can do either of these things safely on a large
production system, since you could easily be increasing the amount of
config false data being generated by the system by a factor of 10 or more.
For the systems that I work on, using CLI based commands, there are 3
ways that diagnostics related information is commonly obtained today:
1) An operator knows that one physical interface (potentially out of a
thousand) has a problem, and wants to obtain some additional diagnostics
information for that specific interface, but not affect any other
interface, or any other management client/request. I think that
fetching the Ethernet clause 45 registers fits into this category.
2) For some other issues that need to be diagnosed it isn't immediately
obvious which area of the system the problem is in. Hence, this second
set of commands fetches a lot of general operational data and
diagnostics information from a subset of the daemons in the system. The
clause 45 registers could be included in this data set, or they may be
omitted because they are slow to retrieve from the hardware.
3) The third category is debug that is enabled and then is streamed to
the console, a telnet session, or a syslog buffer. For our systems, it
would be less common to turn on the debug on a production device, and
more generally this debug would be used during feature development.
It is the data for (1) and (2) that I think could be best served if the
diagnostics leaves were explicitly labelled in the model, and then if
get requests/subscriptions could filter on that label. Perhaps putting
these diagnostics into a separate operational datastore would be a
cleanest way to handle this?
Thanks,
Rob
Thanks,
Rob
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
