Hi Lou, Lou Berger <[email protected]> writes:
> I thought it would be worth summarizing what we're looking for in our > draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case > you missed it) with respect to the draft-lhotka-netmod-ysdl and > draft-bjorklund-netmod-structural-mount drafts. This is just my view, so > my co-authors may wish to chime in and correct me. > > I'd be interested in hearing from the authors of YSDL and > structural-mount, or anyone else for that matter, on how they see to > best meet these needs. > > Here's what I think our draft needs: > > 1. that there be a mechanism that allows the incorporation (or > 'mounting') of the data model defined by one top-level module > within another module. > > The implication here is that when information is instantiated > for the parent model it is also instantiated for the > incorporated/mounted model. In our case we expect to do this on > list element creation. Both solutions drafts cover the path > implications, so these are not repeated here. Both structural-mount and YSDL satisfy this. > > 2. that this mechanism allow identification of specific modules to > be incorporated/mounted at time of module definition, i.e. that > no additional module is needed to support 1. This doesn't > preclude definition of such a module. If I understand this correctly, then I believe that neither structural-mount nor YSDL support it. This would require new built-in statements in YANG, extensions aren't applicable here. > > 3. that this mechanism allow for a server to control (and > identify) which modules are incorporated/mounted. (see Section > 3 LNE in our draft for an envisioned usage.) Both structural-mount and YSDL satisfy this. > > 4. that all capabilities that exist with the mounted module are > available e.g. RPC operations and notifications. Currently only structural-mount addresses this, YSDL can be extended along the same lines. > > 5. while our primary requirement is for 'mounting' of top level > modules, mounting of submodules may also be useful. (DT not draft > driven.) I don't think this is possible as long as both structural-mount and YSDL take the information about available modules from yang-library. A solution to this could be to allow the "include" statement to appear anywhere in the schema tree, but this is again YANG 2 stuff. Lada > > We make use of the above in sections 3 and 4 of rtgwg-device-model. We > see having a solution as critical for the simplifications/flexibility > represented in the -02 version of our draft vs the -03 rev. We don't > see wither solution draft as significantly different and just hope for a > standard solution as soon as possible. (a draft-ietf-netmod solutions > draft on the topic by BA would be fantastic given the impact on routing > area -- even if it had to document two variations / alternative solutions.) > > Again, this is just my opinion and my coauthors or others on the rtg > area yang DT may choose to chime in. > > Lou > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
