> On 03 Sep 2015, at 08:46, Martin Bjorklund <m...@tail-f.com> wrote: > > Lou Berger <lber...@labn.net> wrote: >> Martin, >> >> On 9/2/2015 3:03 PM, Martin Bjorklund wrote: >>> If it was done with >>> 'mount' instead of the proposed model in >>> draft-rtgyangdt-rtgwg-device-model-00, it doesn't cost anything for >>> the 99% (more?) of all systems that do not have this kind of logical >>> systems, and data models would not have to augment the >>> /device/logical-network-elements/logical-network-element path. >> >> This is a compelling point (at least to me). Of course there's lots of >> details to flush out to make this work, but seems like it's worth >> exploring this approach in more detail. >> >> The initial set of issues I see were in an earlier e-mail: >> >> On 9/1/2015 9:45 AM, Lou Berger wrote: >>> That said, there are some specifics that will need to be addressed to > use >>> this approach: e.g. to quote: > Mounted data is "read-only" data. >>> YANG-Mount does not extend towards RPCs that are defined as > part of >> YANG modules whose contents is being mounted. > YANG-Mount does not >> extend towards notifications. > Perhaps most of these limitations can be >> relaxed for local mounts. > > Also handling when a device/server doesn't >> support local mounts (or is > invalid) Lou > > If this is viewed as a way to incorporate the schema defined in > another module, rather than tie it to run-time behavior, there is no > need to make it read-only.
Right, this discussion is about an alternative method for assembling a schema from modular parts whereas the mount draft deals with mediating access to remote datastores, which is something very different. Lada > > Further, with the addition of 'action' and inline notifications in > YANG 1.1, we can make this handle RPCs and notifications at the > top-level as well. For example: > > module system { > ... > rpc shutdown { ... } > } > > module controller { > ... > list device { > key name; > leaf name { ... } > leaf addres { ... } > > mount system; > } > } > > would behave similar (forgetting namespaces etc) to as if it was > defined as: > > module controller { > ... > list device { > key name; > leaf name { ... } > leaf addres { ... } > > action shutdown { ... } > } > } > > > Maybe we should try to find another term than 'mount', > since it seems people think about the specific solution in > draft-clemm-netmod-mount. It might also be necessary to 'mount' parts > of a module. > > > /martin > > > _______________________________________________ > 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