Ladislav Lhotka <lho...@nic.cz> wrote: > Martin Bjorklund <m...@tail-f.com> writes: > > > Hi, > > > > [replying to the first post in this (old) thread; the thread got a bit > > off-topic] > > > > Balazs Lengyel <balazs.leng...@ericsson.com> 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. > > Did you have a chance to look into my slides from Berlin? I sketched some > solutions there.
Well, that's a *solution*. I'd like to understand the *problem* first ;) > > 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. > > Not necessarily, D could contain an augment with a target specified by a > schema node identifier that uses nodes from both A and C. Not if B and D are defined as standalone modules, e.g. if B is ietf-interfaces and D is ietf-ip. > Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would > be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the > augment in ietf-ipv6-router-advertisements > > augment "/if:interfaces-state/if:interface/ip:ipv6" { ... } > > needn't be changed. This would be an entirely different kind of mount! The current mount doesn't work like that; it doesn't give you visibility into the combined models - by design. > The major problem with this IMO is that it needs a new YANG statement. > > > > >> 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. > > Yup. So we just need some machine-readable description of the structure > of mounted schemas. > > > > > 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. > > Well, if you have multiple levels of mounts, it will get messy: you > wouldn't know which yang-library data belongs to which mount point. Why not - imagine that you do a full <get/> on such a device, it will return the nested yang library data just fine. /martin > I believe some variation on YSDL could work, and as I wrote in another > thread, we could also incorporate datastores: after defining the > (multilevel) schemas, each datastore will get one assigned - and they > can also share them where needed. > > Lada > > > > > > > > > /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: balazs.leng...@ericsson.com > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod