Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

lada,

    See below.


On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> Hi,
>
> unfortunately, using an action for querying embedded YANG library data
> (needed for the "inline" case of schema mount) doesn't work either
> because now under NMDA actions can be used only on instances in the
> <operational> datastore.

but the inline/embedded library would (only) be present in the in the
operational datastore, so what's the issue?

> However, a good alternative seems to be a metadata annotation along the
> lines of RFC 7952, for example with the alternative B of the newly
> proposed YANG library schema:
>
>      md:annotation schema-ref {
>        type leafref {
>          path "/yanglib:yang-library/yanglib:schema/yanglib:name";
>        }
>      }
>
> In other words, all inline mounted schemas would be included in the
> top-level YANG library, and mount point instances in all datastores
> would be annotated with leafref pointing to the actual schema.
>
> Unlike regular state data, it is IMO no problem to permit such
> annotations in configuration datastores.
>
> Opinions?
I'm not sure this will work for all architectures of LNEs as well as
other possible future use cases.  In short, this seems *very* restrictive.

Lou

>
> Thanks, Lada
>
> Ladislav Lhotka <[e-mail]> writes:
>
>> Hi,
>>
>> the following text in sec. 3.2 of schema-mount-08 is wrong for traditional
>> datastores, and even more so for NDMA:
>>
>>    In case 1 ["inline"], the mounted schema is determined at run time: every
>>    instance of the mount point that exists in the parent tree MUST
>>    contain a copy of YANG library data [RFC7895] that defines the
>>    mounted schema exactly as for a top-level data model.  A client is
>>    expected to retrieve this data from the instance tree, possibly after
>>    creating the mount point.  Instances of the same mount point MAY use
>>    different mounted schemas.
>>
>> An instance of the mount point in any *configuration* datastores cannot contain
>> YANG library (being state data), and so the MUST cannot hold.
>>
>> It is not clear to me how to repair this without considerable complications
>> and/or a lot of handwaving. There is actually one good solution but it has
>> impact on YANG library: the server could provide it in a reply to an operation,
>> say "get-yang-library" rather than as state data. Then everything would be fine
>> - this operation would turn into an action for the mount point, and it can be
>> used equally well for config true and false mount points.
>>
>> So my proposal is to move from YANG library as state data to an operation. It
>> could be done along with changing the YANG library structure, so there will be
>> little extra impact on implementations. 
>>
>> Lada 
>>
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod