Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

Lada,

It sounds like you are proposing in (1) a fairly significant change in the 
direction of the draft and in (2) a basic approach that has been 
rejectected by the WG multiple times.  FWIW there are drafts already with 
the iesg that will need to be returned to their WGs if either change is made.

Martin,

Do share Lada's view?

Lou


On January 16, 2018 2:14:42 AM 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.
>
> 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
>> > > > > > > >
>>
>>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>