Re: [netmod] Design-Time schema mount

[Balazs Lengyel <[e-mail]>]

Hello Martin,
As I see in your answer, you do not question that the design time mount is an important and possibly frequent use-case, and I certainly think it is.
I also found this on the Juniper website: https://forums.juniper.net/t5/Automation/FAQ-YANG-Labs/ta-p/294330" rel="nofollow">What are the benefits of a Juniper devices publishing Junos YANG module off box?
See other comments below.
regards Balazs

On 2016-08-26 10:21, Martin Bjorklund wrote:

Hi,

[replying to the first post in this (old) thread; the thread got a bit
off-topic]

Balazs Lengyel <[e-mail]> wrote:

Hello,

As I understand it, Schema-mount today does not support an important
use-case which we definitely need, but others also indicated they
want.

I want to specify off-line in design time which models will be mounted
where. Many of my nodes know in design-time what their model structure
will be, so I want a way to be able to document this in YANG.

I'd like to understand this use case in more detail.  You say that
that a "node knows in design-time" that YANG models it will use.  Thus
it seems natural to be able to specify which other modules to mount in
the YANG module itself.

The problem I see with this is that it is very limited to the use case
where each implementation defines its own YANG modules.  Suppose you
have such a model, for example:

   module A {
     ...
     mount ... {
       mount-module B;
       mount-module C;
     }
  }
      
[pseudo-code for module A that specifies that it mounts B and C]

Now, suppose you take this module A to another implementation, and it
needs to augment something into module C; essentially this means that
it would like to mount B, C and new module D.   This will not be
possible unless it modifies module A.

BALAZS: No you don't need to modify module A.   You can use a separate file 
to define mounting modD into modA.  Even my proposed solution allows this.

module mount-list {
   import moduleA { prefix moda; }
   import moduleD {}

   // indicate that moduleD is mounted somewhere
   schema-mount moduleD {  
      // indicate where it is mounted
      schema-mount-target /moda:baseContainer ;
   }
}

In
today's proposal the only way to find the Yang-Mounts is to read it
from the live node.

* OAM integrators or operators want to be able to write CLI scripts
  and Netconf messages without accessing (expensive) real nodes. For
  this they need to know the mounts
* We want to generate some fancy documentation from YANG automatically
  in design-time.

In a way this is no different from the situation today - in order to
learn what YANG modules a device supports you need to connect and
parse the <hello> message (or ietf-yang-library data in the near
future).  This info could also be made available off-line in a file.

BALAZS: actually it is made available in our case, also describing support for features

It should certainly be possible to define a file format that a device
somehow could "publish" off-line that contained all the info that is
available at run-time.  This file format could be exactly the same as
you would get if you did a NETCONF <get/> operation with some filter
to only retreive the ietf-yang-library data at the mount points.

BALAZS: That would be an INTERESTING idea for multiple reasons (and I know some implementations who already do this).
Some potential use-cases:
- Mount descriptors
- defining default security rules for Netconf-acm
- listing available notification streams
- listing supported modules & features from yang-library

/martin

* Many use cases need the possibility to mount schemas, but do not
  need the added complexity of schema changes in run-time.
  Notwithstanding the case of "YANG Features", for me the model schema
  is a mostly static description of a nodes capabilities. Most of the
  time I do not want to worry about the node changing its schema on
  the fly.


For this I propose 2 YANG extensions

extension schema-mount {
description "Indicates that a YANG Module is to be mounted into
another module.
The argument specifies the name of the module to be mounted.";
argument mounted-module;
}

extension schema-mount-target {
description "Specifies the target node under which a YANG module is to
be mounted.
The statement can only be used inside a schema-mount statement.
The argument follows the same rules as an augment statement's target.
argument target-node;
}

The two extension statements can be placed in a separate module or the
mounted module.

I don't insist on the solution, but I need the off-line/design-time
specification of yang-mount to be possible. IMHO the design-time mount
use-case is more important than the dynamic-mount.

regards Balazs
--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]