Andy Bierman <a...@yumaworks.com> writes: > Hi, > > I do not agree that ephemeral data should be outside the scope of the > standard. > I do not agree that YANG extensions should be used for IETF standards track > modules. > It was a mistake to define the "get-filter" hack in the first place. > IMO it is a mistake to define Lada's "annotation" statement as an extension. > > I don't think you are correct in your interpretation of "MAY ignore". > My reading of this text is that no YANG tool anywhere (or ever) > MUST or even SHOULD understand any YANG extension.
This was my reading, too. The text actually talks about "compiler" which is even less clear - it may apply to server or client software as well. Lada > I don't see how YANG conformance applies to usage of extension > statements. It only applies to usage of YANG statements. > > > > Andy > > > On Tue, Jul 28, 2015 at 2:45 PM, Martin Bjorklund <m...@tail-f.com> wrote: > >> 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 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
