On Fri, Dec 9, 2016 at 10:10 AM, Robert Wilton <[email protected]> wrote:
> > > 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. > > 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> Thanks, > Rob > > Andy > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
