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. 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. 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.) 4. that all capabilities that exist with the mounted module are available e.g. RPC operations and notifications. 5. while our primary requirement is for 'mounting' of top level modules, mounting of submodules may also be useful. (DT not draft driven.) 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
