Lada,
Thank you for the response. See below.
On February 4, 2016 6:39:11 AM Ladislav Lhotka <lho...@nic.cz> wrote:
Hi Lou,
Lou Berger <lber...@labn.net> 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.
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
