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.
/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
