On Fri, May 2, 2014 at 2:29 AM, t.petch <[email protected]> wrote: > ---- Original Message ----- > From: "Andy Bierman" <[email protected]> > To: "Jeffrey Haas" <[email protected]> > Cc: "t.petch" <[email protected]>; <[email protected]> > Sent: Thursday, May 01, 2014 7:10 PM > > On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas <[email protected]> wrote: > > > > > Andy, > > > > > > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: > > > > This has been done a few times. > > > > Most recently April 22: > > > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > > > > > I should respond there, but this was one of the messages that > prompted my > > > question about data (operational state) vs. ephemeral config. > > > > > > I don't believe we want to say "this is the module for monitoring > the rib > > > and now you can write to it". > > > > > > > that is not what the "edit-data" extension does. > > It is a sub-statement that identifies I2RS editable data no matter > what > > YANG module is used to define the data. The YANG config=true > statement > > identifies a data node as part of the configuration datastore. The > edit-data > > extension cannot be used on a config=true node, only > non-configuration. > > > > module foo { > > ... > > import i2rs { prefix i2rs; } > > > > container config-data { > > // NETCONF definitions here > > } > > > > container i2rs-data { > > config false; > > i2rs:edit-data; > > } > > > > container oper-data { > > config false; > > // plain read-only data > > } > > } > > > > Nesting is also possible -- up to the data modeler to decide what to > use: > > > > 1) i2rs-data inside config-data > > 2) i2rs-data inside oper-data > > 3) oper-data inside i2rs-data > > Andy, Jeff > > I wonder if edit-data on its own will be enough. > > 'config true' in base YANG allows the data to be written, but it also > makes it very easy for NETCONF to read what it wants to, with a > get-config RPC. Strictly such a function is unnecessary, it could all > be done with filters, which would be a nightmare and error-prone. So we > have get-config that gets the 'config true' subset of leafs etc. And, > with no apparent downside, there is just the one substatement, 'config > true', the two sets are identical. > > With I2RS, we need writable operational state so we need an edit-data > substatement added to YANG but what about getting the data that I2RS > wants to see? Do we need an i2rs-data substatement so that we can > readily tag the parts of the model that i2rs wants to get, e.g. with a > new 'get-i2rs' RPC? >
If definitions are combined in the same module(s), then there is no way to prevent NETCONF from skipping over these special config=false nodes. I doubt that is a problem. 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. 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. > 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. > Tom Petch > > Andy > p.s. this is one of the issues that I have been wrestling with that I > alluded to in my response to Tom Narten > > > > > IMO, I think we want multiple data stores for configuration for > adding > > > routes to the rib. > > > > > > > > > How many does I2RS need for itself? > > > > > > > > > > > > (I also thought the notification example was clear and didn't need > further > > > comment.) > > > > > > > I don't see how standard I2RS data could use local config data > unless it > > > > was also standardized. > > > > > > Basically, we want to make sure there is WG coordination on modules. > > > If WG has a module and it makes sense for I2RS to use it/extend it, > that's > > > great when it makes sense. Similarly, if we find the need to create > an > > > I2RS > > > module for work covered by another WG, we want to make sure we leave > > > as much re-usable infra for them as we can. > > > > > > -- Jeff > > > > > > > Andy > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
