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. > /martin > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
