On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote: > > Alas, xpath filtering is optional, and I'm not sure how many devices have > implemented support for it. Further, this still requires every client to be > coded to avoid receiving the information that they are very unlikely to be > interested in. > > I would much prefer a solution where the clients don't get this (mostly > noise) data unless they explicitly ask for it. Otherwise for an Ethernet > interface you might return 10 leaves of potentially useful opstate > information, along with 50+ leaves of quite low layer diagnostics > information that is likely to be of very little use except for to the select > few people that are actively involved in trying to diagnose hardware faults. >
I expect that there will be many augmentations to lets say /interfaces (or /interfaces-state). How does a data model writer determine which ones are 'noise' and which ones are not? How does a a data model writer determine which ones are costly to implement and which ones are not (since this may vary widely between systems)? Perhaps it is useful to tell client writers that well behaving clients should ask for what they need (and understand) and that they should avoid asking generic 'give me everything you have' questions. If you have to deal with lazy clients that like to grab everything, you can control them via NACM. Simply exclude access to some branches. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
