Ladislav Lhotka <[email protected]> wrote: > > > On 24 Feb 2016, at 15:48, Kent Watsen <[email protected]> wrote: > > > > > > Hi Lada, > > > > > > > > > > > > > >>> In yesterday's meeting, Lou (I think?) mentioned a use case for mount > >>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > >>> for being able to specify modules to mount directly in the schema. > >>> Something like this: > >>> > >>> container root { > >>> ymnt:mount-point "lne" { > >>> ymnt:mount-module "ietf-interfaces"; > >>> } > >>> } > >>> > >> > >> It is IMO impossible to use YANG extensions for similar purposes > >> because it fundamentally changes YANG semantics. > > > > > > Please say more. I don’t see the issue. Naturally there would need > > to be an RFC that defines the semantics of this YANG extension, what > > else would be missing? > > Extensions are optional to implement and "MAY be ignored in its > entirety" (sec. 6.3.1 in 6020bis). Otherwise, why have we bothered so > much with backward compatibility in YANG 1.1? Somebody might define, > via an extension, a new list with deep or optional keys, or a floating > point data type or whatever. So in the end everybody would have YANG > exactly to his or her own liking but there would be no standard at > all.
Sure, this is possible. For example we have an extension for YANG 1.0 called tailf:action (it is not needed anymore of course). The point is that we can define standard extensions with a well-defined meaning. They would be optional to implement in general, but we can certainly say that if you implement a module that uses ymnt:mount-point, you MUST also implement the mount-point extension. Just like we do with nacm:default-deny-all. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
