---- 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? 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. Tom Petch 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
