Robert Wilton <[email protected]> wrote: > > > 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.
This was my thinking as well. But then the "random rearrangemt of modules to get a more beautiful layot" use case doesn't apply. And if you start to do "ymnt:require-module" you probably also need to specify "required-feature" and "required-revision"... So, before exploring possible solutions, it would be great if we agreed on the problem to solve. Does anyone have a use case for explicit naming of modules to be mounted in the schema? /martin > > 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
