Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

Lada,


On December 19, 2017 1:12:35 AM Ladislav Lhotka <[e-mail]> wrote:

> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>> 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?
>
> Well, the issue is described in my initial mail of this thread: the current 
> text
> requires that every instance of an inline mount point contains the embedded 
> YANG library. Tha latter is state data, so the above requirement cannot be 
> satisfied if the mount point instance is in a configuration datastore.
>

That's not how I read the intent of the current text.  I don't see SM 
impacting which data stores information is presented.  Just like use of 
scheme mount doesn't transform RO configuration information into 
operational information.  I sent you a couple of sentences clarifying this 
at one point, I'll dig up the proposed text and resend.

Lou
>>
>> > 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.
>
> I don't understand, IMO it is not restrictive at all. What kind of restrictions
> do you see?
>
> Lada
>
>>
>> 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
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>