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.
6020(bis) says that a tool that doesn't understand the extension statement MAY ignore it. My point is that if I2RS defines an extension estatement, I2RS-compliant tools will have to implement this statement and they can of course not simply ignore it. Again, this is the whole point of having extensions - the language can be extended without having to revise the base specification. > 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, I agree that get-filter-element-attributes is a hack. But that hack really just defines the NETCONF *protocol*. It is not applicable to RESTCONF. I do not agree that a module that defines an extension is a "special hack module". > That would be a terrible solution for ephemeral data. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
