On 25/02/2016 08:43, Martin Bjorklund wrote:
Juergen Schoenwaelder <[email protected]> wrote:
On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote:
I think the use cases are rather obvious. I build a device and I like
to rearrange existing models into a beautiful hierarchy (for some
definition of beauty).
This would be pretty complicated. Suppose I define my own beautiful
structure like this:
container my-interfaces {
x:mount-point "if" {
x:mount-module "ietf-interfaces";
}
}
container my-routing {
x:mount-point "rtr" {
x:mount-module "ietf-routing";
}
}
Note that with the mount-point defined in my draft, each mount-point
becomes itw own "jailed" or "chrooted" tree. So references cannot
cross mount points.
Could be the same here.
In this case, we have references between ietf-routing and
ietf-interfaces. How would they work?
How do they work in your solution? If interfaces is jailed and routing
is jailed, how does routing refer to the interfaces?
My solution does not support "name module mount". It only supports
mouting of a "complete" set of modules (that are chrooted) - simply
because this is what we understand, have implemented, and have been
running for the last ~5 years. (The same goes for ODL, I believe).
I have been wondering whether "name module mount" is really about
mounting only specific modules, or actually allowing the mounting schema
to statically indicate which modules are guaranteed to be present. I.e.
specifically it doesn't explicitly prohibit other modules/data nodes
from potentially also being mounted at the same path, but in the normal
case you wouldn't expect them to be present.
My reasoning is that you don't want to have to statically specify in the
mounting schema all augmentations, deviations and features. But I also
don't think that the mounting schema can guarantee that the mounted
schema will always exactly implement the module(s) specified in the
schema mount and all features without any augmentations or deviations.
So for this to be useful, it means that there has to be a dynamic
mechanism to determine exactly what modules has been mounted (e.g. like
the ietf-yang-structural-mount module or ysdl).
Given this, I think that you could possibly end up with just one "schema
mount" with a couple of options:
The first option would be an explicit list of modules that are
guaranteed to be mounted at that location (or "*" to indicate a
"complete" set of modules (that are chrooted).
The second option would indicate where the runtime details of the
mounted modules can be found: this option might indicate whether details
of the mounted modules can be found inline in the data tree at the mount
point using yang-library, or separately in the
ietf-yang-structural-mount module/ysdl.
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
