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. 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 <[email protected]> wrote: > Andy Bierman <[email protected]> wrote: > > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund <[email protected]> > wrote: > > > > > Ladislav Lhotka <[email protected]> wrote: > > > > > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund <[email protected]> wrote: > > > > > > > > > > Hi, > > > > > > > > > > Andy Bierman <[email protected]> wrote: > > > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > > > >> [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
