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.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
