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 <lho...@nic.cz> 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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
