On 02/24/2016 04:25 PM, Martin Bjorklund wrote:
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.
I think we need to be very explicit about interactions with YANG-based
systems which choose to ignore a particular extension.
To illustrate on tailf:action, it is not clear (at least to me), if it
is valid to target entities within an extension instantiation with an
augment statement. If a YANG compiler decides to ignore the extension
completely (which I think is valid interpretation of RFC6020), such
augment targets become invalid and YANG modules containing those augment
statements are not universally portable ...
Bye,
Robert
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
