On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > I picture the operational state as the mixing bowl for the 2 config sources > and data learned from protocols and system events. It seems > both NETCONF and I2RS would be able to pick the data is cares about > out of that.
I think this is what I'd like to see personally. > This is a weakness in YANG that may get improved in YANG 1.1. > Since it is officially just for NETCONF, there are no mechanisms > (other than vendor extensions) to tag the data as specific to > some subset of protocols. As I mentioned elsewhere, I'm hoping we don't go down the path of "editable operational state", instead configuration semantics for our purposes. > > I think that we will, that is the set of YANG leafs etc that I2RS will > > want to edit and the sets of leafs that I2RS will want to get in a > > straightforward manne will not be the same (eg the latter will include > > read-only statistics and 'config true'). And yes, it could all be done > > with filters, which could be a nightmare. > > > > > Examples of read-only data that only I2RS would want to get would help. I believe that it would largely overlap config false state desired for normal module purposes in many cases. For example, interface statistics would likely be part of the standard interface module. Where things get interesting are specific augmentations that tie different information domains together - interface stats correlated against routing, for example. (For prefix X, traffic is seen - similar to IPFIX exports.) -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
