> On 28 Jul 2015, at 15:44, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund <m...@tail-f.com> wrote: > Ladislav Lhotka <lho...@nic.cz> wrote: > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund <m...@tail-f.com> wrote: > > > > > > Hi, > > > > > > Andy Bierman <a...@yumaworks.com> wrote: > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > >> j.schoenwael...@jacobs-university.de> wrote: > > >> > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > >>>> Hi, > > >>>> > > >>>> I would like to open another issue for YANG 1.1, > > >>>> because I don't want to have 1.1 and then 1.2 right away. > > >>>> The NETMOD WG should evaluate the different ways to > > >>>> support ephemeral state, based on Jeff's draft. > > > > > > [...] > > > > > >> The problem with using YANG extensions for important protocol features > > >> is that the YANG spec says these statements MAY be completely skipped > > >> by a tool implementation. This is not acceptable for ephemeral state > > >> (or operational state either). > > > > > > I don't agree that this is a problem. If i2rs defines an extension, > > > then i2rs implementations will have to support that extension. This > > > is the whole idea behind extensions - we should not have to revise > > > YANG everytime we need a new statement. > > > > > > > Yes, it could work in this case as long as modules containing this > > extension are never advertised to regular NETCONF/RESTCONF clients. > > I think it would. Such nodes would just be seen as config false > nodes. > > > I do not agree that YANG extensions are appropriate for defining standard > protocols. > They are fine for extra tools outside the scope of any protocol. > The "get filter" hack in RFC 6241 does not even work since > any tool is allowed to ignore the extension. > > The solution proposed by I2RS changed the config-stmt. > IMO this is a better solution than defining an extension > that every YANG tool MAY ignore. > > > Ephemeral data can be defined in any YANG module, > not in special hack modules that are not allowed to be shared > by NETCONF or RESTCONF in any way, > That would be a terrible solution for ephemeral data.
I am not sure the ephemeral property required by I2RS only means that a given parameter is is stored in volatile memory. In the meeting with Jeff and Alia on Thursday afternoon we (again) discussed the overlay property: they apparently want to be able to override normal config values with a new (ephemeral) value installed by an I2RS client. This would mean that the same data node exists in two instances - one permanent and one ephemeral, and config true/false/ephemeral is then clearly insufficient. That’s why I asked during the session for clarification of the interactions between ephemeral and standard config values. It also has implications for validation - the running config certainly has to be always valid but what about validity of running + ephemeral data? Jeff’s response was that no semantic validation is done in this case, and it is up to the consuming server application to somehow cope with invalid data and do whatever is the most appropriate action. Lada > > > > > /martin > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
