Ladislav Lhotka <[email protected]> wrote: > > > On 24 Feb 2016, at 23:39, Juergen Schoenwaelder > > <[email protected]> wrote: > > > > On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote: > >> Juergen Schoenwaelder <[email protected]> wrote: > >>> On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > >>>> Hi, > >>>> > >>>> 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 would be useful if the use case for this could be described in more > >>>> details. Is it a requirement to be able to specify this in the > >>>> schema, or could it be done (as Chris mentioned) in the RFC text? > >>>> > >>>> The reason I ask is that it is probably not as simple as the example > >>>> above. First, you probably need to specify a revision of the module > >>>> to be mounted. Or a min-revision. Then probably a set of features > >>>> that must be enabled. And so on. It turns out that there is already > >>>> a proposal for specifying such a "conformance profile" - YANG Packages > >>>> (see draft-bierman-netmod-yang-package). Maybe it would be better to > >>>> re-use packages? > >>> > >>> We are talking schema mount, right? > >> > >> Yes. > >> > >>> So why would features matter? > >> > >> If you want to mount a certain module, and that module has > >> feature-conditional subtrees, you may want to make sure that those > >> features are supported. If these features are not specified in the > >> schema, we need to invent some mechanism for the server to advertise > >> them for the mounted subtree. This is the job for the inline > >> ietf-yang-library, or /mount-points state data in the structural-mount > >> draft. > >> > >> My point is that while this idea (list the module you want to be > >> mounted) seems simple, there are some issues to solve. Hence I would > >> like to understand the use case before suggesting a solution. > > > > A schema in general does not explain which features an implementation > > of that schema supports. A static schema mount is fully consistent > > with that. > > > > Yes, the current YANG library may not expose features that apply to a > > certain mounted schema but this I do not see this as something that > > makes things more complicated from the schema point of view. > > > > 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). Or I deal with some form of virtualization and > > I write a bunch of nested containers and lists that express this and > > then I mount existing YANG models into this hierarchy. In cases like > > this, I know exactly which model I want to mount where at design time. > > > > In your I-D (if I got this right), you only declare mount-points in > > the schema and then an implementation can mount whatever it likes on a > > mount-point. What is the use case for this? Why is it a feature to not > > express in the schema at design time what can be expected behind a > > mount point? > > > > BTW, in your example on page 10, should > > > > <name>device-root</name> > > be > > <name>logical-device</name> > > > > ? > > > > There are likely many other questions that are largely independent of > > the question whether the schema is fixed in a schema at schema design > > time or only discoverable at runtime. (How do protocols interpret > > instance-identifiers crossing mount points, how do you mix chrooted > > and non-chrooted behaviour, what about edit-configs crossing mount > > points, how does this all play with NACM, etc. Nobody expected this to > > be easy.) > > > > Since you and Lada thought way more about this than I ever did, there > > may be a reason why you both propose to make this runtime data driven > > instead of having a piece of YANG defining how schemas are mounted > > together. > > Three reasons: > > 1. I wanted a mechanism that requires no change in YANG (and, as I > said, using an extension for this is taboo for me).
But *not* using an extension is as bad for the poor client as having an extension it just ignores! In both cases the old client sees a normal data model, and in both cases the data model is in fact extended via mount. > 2. It is more flexible: modules can be combined in different ways, Agreed. > and using the same "mounting" module with different sets of mounted > modules would require different versions of the mounting module. I don't understand what you try to say here. > I > guess the motivation is similar as for NVDL: > > http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compound.html > > 3. This mechanism seems incompatible with groupings, or at least I > cannot imagine how such a mount could be handled inside a grouping. > > BTW, the last item also applies to Martin's mount-point extension: > if it appears inside a grouping, then the same mount point may end > up in different places and the whole concept breaks down. If a mount-point is defined in a grouping, that grouping can only be used once in a module. The mount-point name gets bound to the module that uses the grouping. I will clarify this in my draft. /martin > > Lada > > > > > /js > > > >>> Yes, > >>> there might be interesting versioning issues but how are they > >>> different from an augmentation putting data under root? I naively > >>> considered such a 'static schema defined mount' the simplest case, > >>> then the 'augmented schema defined mount' naturally following from the > >>> way augmentations work: > >>> > >>> augment /some:root { > >>> ymnt:mount-point "lne" { > >>> ymnt:mount-module "ietf-interfaces"; > >>> } > >>> } > >>> > >>> The 'dynamic runtime defined mounts' may be most flexible but then > >>> they require me to read runtime data in order to adapt to the schema > >>> structure, which has its own set of complexities. > >> > >> I agree. > >> > >> > >> /martin > >> > >> > >>> Yes, the versioning > >>> issues go away since I have to adapt to each implementation > >>> dynamically but there is surely a cost involved with that as well. > >>> > >>> Am I missing something? > >>> > >>> /js > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > >>> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
