Re: [netmod] schema mount and YANG library

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> 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 agree.

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

This is a clever idea!  I assume this would be used instead of
requiring the mounting of ietf-yang-library and ietf-schema-mount?

For "peer mount", it might be the case that this doesn't work as well
as the current solution for inline, but I think it is ok.

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


/martin


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