> 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). 2. It is more flexible: modules can be combined in different ways, and using the same "mounting" module with different sets of mounted modules would require different versions of the mounting module. 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. 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
