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.
> 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/>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
