Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

Hi Lada,

On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>> 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.
> Please do, this has to be discussed in the WG mailing list.
Agreed - that's why I asked to start this thread!

Here's the original proposal:

  How about at the end of the section [3.2] adding a new
  paragraph along the lines of:

  It is important to note that both YANG Library and Schema
  Mount Modules contain only operational state data. As such,
  the information in these modules should be retrieved by
  clients from operational data stores using the appropriate
  protocol operations.

Given this discussion, we can generalize it further to:

  The use of mount points does not impact the nature of the
  mounted data or in which data store information is made
  available. For example, mounted YANG Library modules contain
  only operational state data and, as such, the information in
  these modules is available from operational data stores using
  the appropriate protocol operations.

Lou

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