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.
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
