Subject: [netmod] explicit mount

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Feb 2016 16:08:06 +0100 (CET)

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?

/martin

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 24 Feb 2016 09:13:36 -0500

> On Feb 23, 2016:10:08 AM, at 10:08 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

	A question: is the point to manually/explicitly mount a specific container/s 
or the root of a device?  I’d like to understand the use case better here too
because, as you say, it can easily get complicated quickly.

	—Tom

> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Feb 2016 15:26:54 +0100

> On 23 Feb 2016, at 16:08, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

It is IMO impossible to use YANG extensions for similar purposes because it fundamentally changes YANG semantics.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Feb 2016 14:48:26 +0000

Hi Lada,

>It is IMO impossible to use YANG extensions for similar purposes because it fundamentally changes YANG semantics.

Please say more.  I don’t see the issue.  Naturally there would need to be an RFC that defines the semantics of this YANG extension, what else would be missing?

K.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Feb 2016 16:08:39 +0100

> On 24 Feb 2016, at 15:48, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Lada,
> 
> 
> 
> 
> 
> 

Extensions are optional to implement and "MAY be ignored in its entirety" (sec. 6.3.1 in 6020bis). Otherwise, why have we bothered so much with backward compatibility in YANG 1.1? Somebody might define, via an extension, a new list with deep or optional keys, or a floating point data type or whatever. So in the end everybody would have YANG exactly to his or her own liking but there would be no standard at all.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Feb 2016 16:25:26 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> >> It is IMO impossible to use YANG extensions for similar purposes
> >> because it fundamentally changes YANG semantics.
> > 
> > 
> > Please say more.  I don’t see the issue.  Naturally there would need
> > to be an RFC that defines the semantics of this YANG extension, what
> > else would be missing?
> 
> Extensions are optional to implement and "MAY be ignored in its
> entirety" (sec. 6.3.1 in 6020bis). Otherwise, why have we bothered so
> much with backward compatibility in YANG 1.1? Somebody might define,
> via an extension, a new list with deep or optional keys, or a floating
> point data type or whatever. So in the end everybody would have YANG
> exactly to his or her own liking but there would be no standard at
> all.

Sure, this is possible.  For example we have an extension for YANG 1.0
called tailf:action (it is not needed anymore of course).  The point
is that we can define standard extensions with a well-defined meaning.
They would be optional to implement in general, but we can certainly
say that if you implement a module that uses ymnt:mount-point, you
MUST also implement the mount-point extension.  Just like we do with
nacm:default-deny-all.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Feb 2016 17:09:33 +0100

> (see draft-bierman-netmod-yang-package).  Maybe it would be better to

We are talking schema mount, right? So why would features matter? 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" {

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

---

From: Robert Varga <[email-masked]>
Date: Wed, 24 Feb 2016 19:52:59 +0100

> MUST also implement the mount-point extension.  Just like we do with

I think we need to be very explicit about interactions with YANG-based 
systems which choose to ignore a particular extension.

To illustrate on tailf:action, it is not clear (at least to me), if it 
is valid to target entities within an extension instantiation with an 
augment statement. If a YANG compiler decides to ignore the extension 
completely (which I think is valid interpretation of RFC6020), such 
augment targets become invalid and YANG modules containing those augment 
statements are not universally portable ...

Bye,
Robert

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 24 Feb 2016 21:04:00 +0000

Juergen, I think you are correct.  Also alias-mount and peer-mount (not just schema-mount) specify mountpoints in the schema.  They are not about mounting arbitrary data in arbitrary places, but defining a model with mountpoints declared.  
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, February 24, 2016 8:10 AM
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] explicit mount

> (see draft-bierman-netmod-yang-package).  Maybe it would be better to 

We are talking schema mount, right? So why would features matter? 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" {

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Feb 2016 22:30:40 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> 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,
> structure, which has its own set of complexities.

I agree.

/martin

> Yes, the versioning

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Feb 2016 23:39:13 +0100

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2016 00:16:54 +0100

> Juergen, I think you are correct.  Also alias-mount and peer-mount (not just schema-mount) specify mountpoints in the schema.  They are not about mounting arbitrary data in arbitrary places, but de…

My reading of draft-clemm-netmod-mount-03 is that you proposed:

ac:mountpoint foo {
  ac:target "pointer-to-place-where-remote-system-information-can-be-found";
  ac:subtree "/a/b/c";
}

I guess you intend to mount everything below the path /a/b/c,
independent of where the path ends and how many augmentations etc. are
there - you mount everything in the subtree. Lada and Martin I think
do not propose to mount arbitrary paths but only complete YANG modules
and everything (in particular instance identifier) is interpreted
'inside' like if you did a chroot (at least this is how I understood
things so far). It is not clear yet to me how 'inside' and 'outside'
translate to NETCONF and RESTCONF but that is for the protocol people
to figure out I guess.

My understanding is that Martin can mount several YANG modules on a
single mb:mount-point, your mountpoint is restricted to a single
specific path. Lada does not need mount points, the stuff goes to any
place the implementations likes to put it.

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 25 Feb 2016 00:42:45 +0000

Hi Juergen,

your particular example is from peer mount (i.e. remote mount).  Yes, you are mounting everything below /a/b/c, including augmentations etc.  You mount indeed instance information (not just a schema to instantiate just under that mountpoint).  So, I think our understanding is consistent.  However, the mountpoint itself (foo) is part of a model.  You cannot place foo dynamically just anywhere, attaching data/mountpoints into random points in the tree "after the fact", but you need a model in which you define the mountpoint, using the YANG mountpoint extension - this is what I meant with regards to defining a model with mountpoints declared.  (And, while each mountpoint is restricted to a single path, there is nothing that would prevent you from defining multiple mountpoints (each referring to a different path).)  

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2016 3:17 PM
To: Alexander Clemm (alex) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]
Subject: Re: [netmod] explicit mount

ac:mountpoint foo {

I guess you intend to mount everything below the path /a/b/c, independent of where the path ends and how many augmentations etc. are there - you mount everything in the subtree. Lada and Martin I think do not propose to mount arbitrary paths but only complete YANG modules and everything (in particular instance identifier) is interpreted 'inside' like if you did a chroot (at least this is how I understood things so far). It is not clear yet to me how 'inside' and 'outside'
translate to NETCONF and RESTCONF but that is for the protocol people to figure out I guess.

My understanding is that Martin can mount several YANG modules on a single mb:mount-point, your mountpoint is restricted to a single specific path. Lada does not need mount points, the stuff goes to any place the implementations likes to put it.

/js

---

From: Robert Varga <[email-masked]>
Date: Thu, 25 Feb 2016 01:47:38 +0100

> express in the schema at design time what can be expected behind a

The use case for this is implemented in OpenDaylight, where the RESTCONF 
northbound exposes an ietf-network-topology (ancient draft), where each 
nt:node represents a network element accessible via NETCONF. 
Configuration and state of that network element is exposed as a 
mointpoint anchored at that particular node. Data exchange is mediated 
(and validated) by OpenDaylight. Models available are limited by the 
network element, OpenDaylight only interprets them at runtime (and pulls 
them from network element as needed).

Bye,
Robert

---

From: <[email-masked]>
Date: Wed, 24 Feb 2016 20:54:58 -0500

> express in the schema at design time what can be expected behind a

B/c that schema may not be written yet, or known about by the mounting
model authors, etc. Think of the case we have been driving this with (i.e., a
virtual router running inside a host router), in this case we want all
the modules at the mount point which the virtual router has at it's
root. The schema that defines this mount point (the
logical-network-element schema) wouldn't pre-specify all known models,
and additionally we do not want to require model authors to augment the
logical-network-element schema to add their schema to it. We just want
it to work, and by not restricting what can be mounted there (other than
to say it mirrors the root of the LNE), it does.

Thanks,
Chris.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Feb 2016 08:34:11 +0100

> On 24 Feb 2016, at 23:39, Juergen Schoenwaelder <[email-masked]> wrote:
> 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Feb 2016 09:00:54 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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: 
> 
> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Feb 2016 09:23:57 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> 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.

In this case, we have references between ietf-routing and
ietf-interfaces.  How would they work?  What happens with the
references if I do:

  container my-interfaces1 {
    x:mount-point "if1" {
      x:mount-module "ietf-interfaces";
    }
  }
  container my-interfaces2 {
    x:mount-point "if2" {
      x:mount-module "ietf-interfaces";
    }
  }
  container my-routing {
    x:mount-point "rtr" {
      x:mount-module "ietf-routing";
    }
  }

> Or I deal with some form of virtualization and

This is the logical device use case - Chris replied to this.

> express in the schema at design time what can be expected behind a

See above.  Another use case is what we are using in our NCS software,
and ODL is using - a manager/controller/orchestrator that mounts the
data models of the devices it manages/controls/orchestrates.  These
models are not known at design time.

Yes.

> points, how does this all play with NACM, etc. Nobody expected this to

Well, I think that the current mount-point w/ a chrooted behaviour
simplifies this a lot.

> instead of having a piece of YANG defining how schemas are mounted

Hopefully this is clear now from the use cases we have presented.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2016 09:24:17 +0100

> that uses the grouping.  I will clarify this in my draft.

Thats odd, no? An extension statement (which may be ignored) causes a
constraint on a grouping so that it can only be used once? Why not
refer to the mount point by path to avoid this?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2016 09:32:28 +0100

> becomes itw own "jailed" or "chrooted" tree.  So references cannot

Could be the same here.
 
> 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?

> What happens with the references if I do:
> 

Why is this any different in yours or Lada's solution? The question
what is accessible to whom is I think independent from the question
whether the schema mounted at a mount point is fixed in a schema or
described at runtime only, no?

/js

PS: I am asking these maybe stupid questions just in an attempt to
    understand the designs on the table. I have no opinion about what
    the 'right' solution is yet.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Feb 2016 09:34:15 +0100

> On 25 Feb 2016, at 09:00, Martin Bjorklund <[email-masked]> wrote:
> 

The wording in 6020bis also allows a *server* to ignore extensions. So both the client and server could just guess what extensions the other party supports.

As you now, I have never been a friend of the excessive care of old clients (at this stage of YANG development, at least), but it is really funny to have sec. 11 in 6020bis and, at the same time, permit extensions that fundamentally change how YANG works.

Optional extensions are OK for a protocol but not so much for a schema language.

> I don't understand what you try to say here.

Imagine that ietf-interfaces mounts trees for different technologies instead of waiting for augments. Then every revision would support a fixed set of technologies, and every new technology would require ietf-interfaces to be updated.

> that uses the grouping.  I will clarify this in my draft.

Well, CLRs… But there are actually use cases where you might want to add stuff to multiple instances of a node defined in a grouping, for example:

grouping foo-common { ... }

container foo {
  uses foo-common;
  ...
}

container foo-state {
  config false;
  uses foo-common;
  ...
}

Then somebody may want to add (different) subtrees to both instances of a node that's defined inside foo-common. With YSDL it's trivial.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Feb 2016 09:43:34 +0100 (CET)

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

[Side note: we do have experience with something similar to alias
mount.  we called it "symlink", and it was a huge mistake; specifially
related to the non-chrooted behaviour, when references in the
symlink target model could point out of the symlinked subtree.]

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2016 10:05:46 +0100

> running for the last ~5 years.  (The same goes for ODL, I believe).

OK. I understand now that the whole set of modules on a mount point
form one chroot environment. This was not clear to me yet but of
course makes a lot of sense. So a static schema mount would have to
define a set of modules and not just a single module to lead to the
same chrooted behavior.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Feb 2016 10:07:58 +0100

> On 25 Feb 2016, at 10:05, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Yes, that's what called "(sub)schema" in YSDL. 

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Feb 2016 10:14:05 +0100 (CET)

> define a set of modules and not just a single module to lead to the

Yes, but then you can't use it to define your own beautiful
structure.  So then the question is if there is still a use case for
this?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2016 10:26:23 +0100

On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote:
> structure.

I am not sure yet why this is the case. I would have to derive from
the schemas the set of modules on a mount point. Yes, this would be
static and not very dynamic, to add a module I would have to modify
the schema.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Feb 2016 10:31:43 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> I am not sure yet why this is the case.

Each such mount point is chrooted.  This implies that if you want to
put module A in some place, and B has a reference to A, A and B must
be mounted together.  Thus I cannot put them anywhere to form a
beautiful hierarchy.

/martin

> I would have to derive from

---

From: Robert Wilton <[email-masked]>
Date: Thu, 25 Feb 2016 10:15:47 +0000

Hi Martin,

> be mounted together.  Thus I cannot put them anywhere to form a

As long as B is mounted in the same datastore as A then is it possible 
that B could moved to be mounted on some other path?

References to/from B would need to be fixed up, or are you saying that 
fixing the references is intractable?

Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Feb 2016 12:16:36 +0100 (CET)

> that B could moved to be mounted on some other path?

Yes, but then you'd need some special syntax to say that they are
related.

> fixing the references is intractable?

I think it would be extremely complicated, both on the server and on
the client side.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 25 Feb 2016 15:15:18 +0000

> Yes, but then you'd need some special syntax to say that they are
Wouldn't any path references be sufficient to indicate whether the 
modules are related?

> I think it would be extremely complicated, both on the server and on
This probably feels similar (but actually simpler) than mapping between 
different sets of modules.  E.g. mapping from OpenConfig modules to IETF 
modules, or from OpenConfig/IETF modules to a native device schema.

I doubt whether this idea will be particularly well received, but:

Would it be possible to programmatically generate a new set of YANG 
module definitions from the originals with updated paths/references.  
I.e. both sets of module definitions model exactly the same data, just 
the location of that data is in different places.  A client could then 
solely interact with the new set of YANG modules if they wished.  A 
function can be programmatically generated and used to map between the 
two equivalent models with different node paths.  I would imagine that 
this mapping could be done either on the client side or server side.

Even if this approach is valid, it would appear to only really solve the 
"can't use it to define your own beautiful structure.", and I'm not sure 
whether that's an actual requirement here.

Rob

> .

---

From: Robert Wilton <[email-masked]>
Date: Thu, 25 Feb 2016 16:35:43 +0000

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Feb 2016 08:25:05 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> 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.
> 
> 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:
> 
> 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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 26 Feb 2016 11:00:51 +0000

> specify "required-feature" and "required-revision"...
Yes, I don't know if you would have to require those, but I can see that 
it would be useful to at least allow them.

> explicit naming of modules to be mounted in the schema?
I might be mistaken, but an example use case of this may have been given 
in the Yokohama L3SM WG meeting.

That WG has a desire to build service level YANG models, and for such 
models I think that there are some scenarios where it may be desirable 
to build those service level models by reusing some of the device level 
YANG modules (e.g. perhaps QoS, ACLs, or BGP may have been mooted) 
rather than having to independently develop closely related copies of 
those YANG modules located at different schema paths which might 
potentially diverge over time.

However, if this was the scenario considered then it is unclear to me 
whether you would want to mount the entirety of a QoS device level 
model, or would just want parts of it.  Arguably groupings may be a 
better solution here, but their usefulness depends on whether the device 
level model has been constructed in a way to make reuse of parts of that 
model feasible.

Rob

---

From: Lou Berger <[email-masked]>
Date: Fri, 26 Feb 2016 06:13:39 -0500

Rob/Martin,

> potentially diverge over time.

L3SM and bgp was the case I referred to in the interim and commonly use as 
an example. (Although I wasn't part of the Yokohama discussion you mentioned.)

> level model has been constructed in a way to make reuse of parts of that

This probably would work if we had augmentable groupings or maybe "root 
less" containers -- need to think a bit more about the latter....
Lou

---

From: Robert Wilton <[email-masked]>
Date: Fri, 26 Feb 2016 14:40:41 +0000

Lou, Martin,

Is the network-instance schema-mount (from 
draft-rtgyangdt-rtgwg-device-model) an example of where it would be 
useful to indicate which modules would be expected to be mounted at that 
point?

Certainly it would seem that there are particular modules that you would 
expect to be mounted at that point (e.g. routing) and other modules that 
you would not (e.g. interfaces/hardware/etc).

Rob

On 26/02/2016 11:13, Lou Berger wrote:
> L3SM and bgp was the case I referred to in the interim and commonly 
> use as an example. (Although I wasn't part of the Yokohama discussion 
> you mentioned.)
>
> This probably would work if we had augmentable groupings or maybe 
> "root less" containers -- need to think a bit more about the latter....
> Lou
>> Rob
>>
>>
>>>
>>>
>>> /martin
>>>
>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 26 Feb 2016 10:42:55 -0500

Rob,
    I think chris spoke to this (indirectly) in an earlier mail -- that
the current approach of not specifying is most flexible from a future
proof stand point, i.e., we really don't want to specify based on what
exists in today's rapidly moving environment.

We have also discussed the possibilities of defining 'example profiles'
which would be what you'd expect to see from different classes of
devices, e.g., an wrt box vs a tier 1 PE - which could be informative.

Lou

PS Interfaces do need to show in NIs, check out the augmentations
defined as part of the model.  But I think your general point is still
valid.