Robert Wilton <rwil...@cisco.com> 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. It would be better to model it as config false and work on the protocol to have better filters (like Andy's recently proposed "topic-filter" maybe). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
