Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

On 1/16/2018 8:40 AM, Robert Wilton wrote:
>
> On 16/01/2018 13:23, Lou Berger wrote:
>> On 1/16/2018 7:41 AM, Robert Wilton wrote:
>>> On 16/01/2018 07:14, Ladislav Lhotka wrote:
>>>> Hi Lou,
>>>>
>>>> in my view, we should do the following two (significant) changes:
>>>>
>>>> 1. Instead of borrowing a grouping from ietf-yang-library and having
>>>> a parallel
>>>> list of mounted schemas, we should keep *all* mounted schemas
>>>> directly in the
>>>> YANG library and refer to them from schema-mounts structures.
>>>> Juergen suggested
>>>> this change and it is IMO the right thing to do.
>>> I also support this approach.  I think that it easier for everyone if
>>> schema are defined in one place.
>> I think we have a question of what is workable vs what is optimal,
>> i.e., this proposal is arguably better for those supporting YL bis,
>> but the other isn't broken.   -- I have also raised this privately
>> with the chairs and ADs of the impacted groups (keep in mind that
>> RTGWG and BESS are already using the current definitions) to see if
>> they have opinions.
> The NMDA solution to this problem is to publish both ...
>
> E.g. either (i) publish SM now (so that folks can use)
This would permit the current dependent work to continue, uninterrupted 
so I think has a lot of benefit.
> it but then
> immediately bis the draft, to cover YL-bis (probably keeping the
> existing library in the appendix).
Lots of variations on how to immediately address YL-bis and SM.  -- I 
think you know my preferred solution, but other are certainly workable.


> Or (ii) put the current SM YANG library into the appendix (marked as
> deprecated) and include a new YL-bis compatible version in the body of
> the document.

>
>>> This was also the suggested approach that I presented at IETF 100 for
>>> the YANG library bis draft, which seemed to have reasonable support in
>>> the room, and I don't recall anyone objecting to this approach.
>> In the email discussion on the results of the December NetConf
>> interim, the sentiment was that YL bis shouldn't consider schema
>> mount.  As stated on the list, I personally (with all hats) think this
>> is a mistake and would likely feel differently if YL bis
>> covered/obsoleted schema mount.
> I think that the conclusion was more nuanced that that:
>
> YL-bis should not cover SM directly.  I.e. YL-bis should not contain SM
> specific nodes (even under a feature keyword).
>
> However, there seems to good support for YL-bis being designed in an SM
> sympathetic way, such that SM can cleanly augment YL-bis and provide the
> required functionality without needing to a separate schema mount
> specific YANG library tree.

I'm certainly glad to hear that the topic of schema mount and server 
metadata will be / is being considered as part of YL-bis.  This is more 
than I thought was evidenced by the on-list discussion in December.

Lou

>
> Thanks,
> Rob
>
>
>> Lou
>>> I also provided the same comment in November during the WG LC on schema
>>> mount ...
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>> 2. Define a metadata annotation (e.g. @schema-ref) that would be
>>>> required for
>>>> inline mount point instances and specify the inline-mounted schema
>>>> also by
>>>> referring to a schema specified in YANG library.
>>>>
>>>> The advantage of #2 is that an annotation can be attached equally
>>>> well to both
>>>> state an configuration data. So, instead of papering over the issue
>>>> that YANG
>>>> library (state data) cannot appear in configuration datastores, we
>>>> can use this
>>>> general and straightforward approach. This also allows for defining
>>>> different
>>>> mounted schemas for instances of the same mount point in different
>>>> datastores.
>>>>
>>>> I strongly believe that these changes (along with the new YANG
>>>> library schema
>>>> and NMDA) make for a simple and elegant datastore architecture in
>>>> which schema
>>>> mount would be an optional feature.
>>>>
>>>> Lada
>>>>
>>>>
>>>> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>>>>> Lada/Martin,
>>>>>
>>>>> I don't believe we reached closure on this discussion.  The open
>>>>> issues
>>>>> relate to proposed new text (slightly modified):
>>>>>
>>>>> at the end of the section [3.2] adding a new paragraph along the
>>>>> lines of:
>>>>>
>>>>>       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 define
>>>>>       only operational state data and, as such, the information in
>>>>>       these modules is available from operational data stores using
>>>>>       the appropriate protocol operations.  It is also worth
>>>>>       noting that the Schema Mount module itself parallels the
>>>>>       YANG Library module and only defines operational state data.
>>>>>
>>>>> Is this change acceptable?
>>>>>
>>>>> What other issues related to SM are outstanding?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Lou
>>>>>
>>>>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>>>>>> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>>>>>>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>>>>>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>>>>>>> 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,
>>>>>>>> s/contain/define/
>>>>>>>>
>>>>>>>>>       the information in these modules should be retrieved by
>>>>>>>>>       clients from operational data stores using the appropriate
>>>>>>>> This is based on two assumptions:
>>>>>>>>
>>>>>>>> 1. For every configuration datastore there is a corresponding
>>>>>>>> operational
>>>>>>>> datastore.
>>>>>>> well the text is revised below.  In any case, "these modules"
>>>>>>> refers to
>>>>>>> yang library, and yes, I'm assuming YL is always and only in
>>>>>>> operational.  If the revised text below isn't clear s/these/YANG
>>>>>>> Library/
>>>>>>> -
>>>>>> The thing is that we have the top-level YANG library in
>>>>>> <operational>, and
>>>>>> then
>>>>>> embedded YANG libraries scattered inside inline mount point
>>>>>> instances.
>>>>>>
>>>>>>>> 2. For every mount point instance in any configuration datastore
>>>>>>>> there
>>>>>>>> is a
>>>>>>>> corresponding mount point instance (with the same path) in an
>>>>>>>> operational
>>>>>>>> datastore.
>>>>>>>>
>>>>>>>> I think that neither of these has to be true in general.
>>>>>>> agreed in general, but for inline, where YL is required, it must
>>>>>>> be true.
>>>>>> How do you know? I provided an example in Singapore where a mount
>>>>>> point
>>>>>> instance
>>>>>> in <intended> is a part of pre-provisioned data (for non-existent
>>>>>> hardware).
>>>>>> Then, according to the NMDA rules there is no corresponding
>>>>>> instance in
>>>>>> <operational>, hence no place where the embedded YANG library can
>>>>>> be placed.
>>>>>> (I can easily provide a concrete example if needed).
>>>>>>
>>>>>>
>>>>>> Dean replied that this cannot happen, so it seems there are some
>>>>>> assumptions
>>>>>> how
>>>>>> the inline method of schema mount may be applied. If so, these
>>>>>> assumptions
>>>>>> have
>>>>>> to be explicitly stated.
>>>>>>
>>>>>>>>>       protocol operations.
>>>>>>>> In contrast, the substance of my proposal with metadata
>>>>>>>> annotations is
>>>>>>>> to be
>>>>>>>> able to retrieve all schemas from a well-known location in *the*
>>>>>>>> <operational>
>>>>>>>> datastore, namely from the top-level YANG library.
>>>>>>> What about a schema that is based on dll that contains modules that
>>>>>>> isn't loaded until a mount point is instantiated -- this is
>>>>>>> certainly a
>>>>>>> valid approach for supporting LNEs, but would be precluded in this
>>>>>>> approach.  I really don't think a top level approach works for all
>>>>>>> inline (managed) types of mounts.
>>>>>> It isn't precluded: when the mount point is instantiated (no
>>>>>> matter which
>>>>>> datastore it is in), the server adds the schema as a new entry to the
>>>>>> "schema"
>>>>>> list in the top level YANG library (with a unique key), and
>>>>>> annotates the
>>>>>> mount
>>>>>> point instance with a leafref pointing to that key. So different
>>>>>> instances
>>>>>> of
>>>>>> the same mount point can have different schemas.
>>>>>>
>>>>>>>>> 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.
>>>>>>>> The whole question here is whether and how we can locate the
>>>>>>>> schema for
>>>>>>>> an
>>>>>>>> inline mount point in any configuration datastore.
>>>>>>> Why is a mounted YL different than a top level YL?  What works
>>>>>>> for and
>>>>>> It is not different, but it can be only in an operational
>>>>>> datastores, and so
>>>>>> for
>>>>>> mount point instances inside configuration datastores we need a
>>>>>> way how to
>>>>>> locate the schema for that mount point, because it cannot be found
>>>>>> directly
>>>>>> under the mount point instance (as the current text assumes).
>>>>>>
>>>>>>> is sufficient for the normal case of YL shouldn't be impacted or
>>>>>>> modified by SM -- at least that's how I thought we've been
>>>>>>> talking about
>>>>>>> since SM was started.  Again, we never made any special
>>>>>>> provisions for
>>>>>>> any other rw/ro/state data, assuming top level YL is not handled as
>>>>>>> metadata, why start now?
>>>>>>>
>>>>>>> I'm getting the impression that your argument may be more about
>>>>>>> if YL
>>>>>>> should be treated as something other than operational data, is
>>>>>>> this wrong?
>>>>>> This is wrong. My argument is that there should be only one
>>>>>> top-level YANG
>>>>>> library (state data) and each inline mount point instance just
>>>>>> points to a
>>>>>> schema inside it by means of a metadata annotation attached to the
>>>>>> mount
>>>>>> point
>>>>>> (in any datastore).
>>>>>>
>>>>>> Lada
>>>>>>
>>>>>>> Thanks,
>>>>>>> Lou
>>>>>>>
>>>>>>>> Lada
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>>
>> .
>>
>