On 09/12/2016 15:17, Martin Bjorklund wrote:
Robert Wilton <[email protected]> wrote:
On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote:
Even if they don't break, debug and diagnostics information can be
very
verbose.
If a client had 4 connections to a device for monitoring different
things,
then you don't want to suddenly start sending a large amount of extra
diagnostics data on each of the 4 connections when they have only
requested
it on one connection. Generating this extra data could overload the
client
or the device, or certainly lead to degraded performance in some way
or
another.
Then the client probably should have used a proper filter. Augments
are a key feature of YANG. A client not interested in any additional
data should not (implicitely) ask for it. (It does not matter whether
the additional data is debugging or other information; if you do not
need it, do not as for it if you want to be robust.)
Given that an augmentation could be on any container, then I think
that this ends up that every get request needs a potentially complex
subtree filter to exclude diagnostics information that they wouldn't
really expect to be returned in the first place. Further, if the
diagnostics information was controlled by a debug leaf then they
probably won't ever see this problem during testing, only when someone
needs to get diagnostics information for an Ethernet interface on a
production system would the extra data start showing up.
To me, this seems to be making YANG models easier for the 0.01% of
client request at the expense of the 99.99% of client requests.
The problem is that it is a slippery slope. Anyone that designs a
data model might think that some data probably not is interesting to
all clients, in all cases, so they might just create special RPCs
instead of modelling it as config false data.
I would say that a clear separation is fairly easy to define, and the
industry has managed to do this fairly well for the last few decades:
- If the information is necessary to manage or monitor a device then it
should be included in opstate.
- if the information is only required for an engineer to diagnose why
the device isn't working to the specification then it isn't part of the
opstate.
There are lots of examples of this:
1) a simple car analogy:
- my car dashboard gives me the useful information that I need to
safely drive the car, and to monitor that the car is behaving as designed.
- if the car stops working properly (perhaps it signals a fault on the
dashboard), then I take it to garage, they connect it to a computer,
download and analyze the diagnostics to figure out what is wrong
(normally at large expense).
- as a user of the car, I do not want to see all of that internal
diagnostics information on the dashboard all the time. It would obscure
the information that is actually important, and I probably wouldn't
understand what it all means anyway.
2) My alarm system at home has a "User mode" and "Engineer mode", the
information presented in each mode differs. I think that this sort of
example can probably be repeated for nearly all of the consumer
electronics that I own.
3) The same is for network devices:
As a operator of an Ethernet interface, I care:
- whether the port is up and able to forward packets, or it is down.
- if it is down, whether it is something that I can diagnose and fix
(e.g. config error, dirty cable, missing PHY).
But I don't personally want to know whether the "PHY XS provides
information on transmit path data
delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able
to generate test patterns". However, an engineer might find this
information useful to diagnose why the Ethernet port isn't working the
way that it should.
I think that there is a clear split in the intent of this information,
and what audience the information is targeted to.
I can't see how always lumping these two discrete sets of data together
really helps anyone.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
