> 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
