Hi, [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. 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. > 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. 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. /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: +36-70-330-7909 email: [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
