> On 04 Feb 2016, at 13:46, Lou Berger <[email protected]> wrote: > > Lada, > Thank you for the response. See below. > > > On February 4, 2016 6:39:11 AM Ladislav Lhotka <[email protected]> wrote: > >> 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. >> > > Agree on the 1st paragraph but not the second. I think that like 2, neither > support the second paragraph.
It depends on what you mean by instantiating. In YSDL, the schema is known in advance and doesn't depend on any instances (except for "when" statements, but this is no different from the current situation). Lada > >>> >>> 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. >> > > Agreed. > >>> >>> 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. >> > > Great. > >>> >>> 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. >> > > Makes sense. > >>> >>> 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. > > Fair enough. This a longer term item and not critical for our draft. > > Thanks again, > Lou > >> >> 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 >> > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
