|
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: 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: BALAZS: No you don't need to modify module A. You can use a separate fileHi, [replying to the first post in this (old) thread; the thread got a bit off-topic]Balazs Lengyel <[email protected]> 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. 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 ;
}
}
BALAZS: actually it is made available in our case, also describing support for featuresIn 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: That would be an INTERESTING idea for multiple reasons (and I know some implementations who already do this).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. 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 -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: [email protected] |
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
