Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

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.

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.

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

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

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
> > > > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67