Subject: [netmod] schema mount and YANG library

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 08 Dec 2017 16:32:17 +0100

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Dec 2017 14:59:16 +0100

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.

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?

Thanks, Lada

Ladislav Lhotka <[email-masked]> writes:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Dec 2017 15:30:08 -0500

lada,

    See below.

> because now under NMDA actions can be used only on instances in the

but the inline/embedded library would (only) be present in the in the
operational datastore, so what's the issue?

> annotations in configuration datastores.
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.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Dec 2017 07:11:59 +0100

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Dec 2017 10:05:43 +0100

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

Lada,

probably a stupid question (since I am not really familiar with the
details of the mount work): What speaks against augmenting the yang
library with a list of mount points and then mount point list elements
can refer to the schema used at the mount point?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Dec 2017 11:25:38 +0100

On Tue, 2017-12-19 at 10:05 +0100, Juergen Schoenwaelder wrote:
> > 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.
> > 
> 
> Lada,
> 

Absolutely, that's exactly what IMO needs to be done. All schemas, both top-
level and mounted, would then be contained in the YANG library's schema list.

I think the most sensible approach is to first agree on the new schema of YANG
library, and then define additional schema mount data as an augment.

Lada

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Dec 2017 06:20:38 -0500

Lada,

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

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Dec 2017 12:23:11 +0100

> at one point, I'll dig up the proposed text and resend.

Please do, this has to be discussed in the WG mailing list.

Lada

> > > > > An instance of the mount point in any *configuration* datastores
> > > > > cannot
> > > > > contain
> > > > > 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
> > > > > So my proposal is to move from YANG library as state data to an
> > > > > operation.
> > > > > It

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Dec 2017 06:23:52 -0500

Woops that should be rw...

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Dec 2017 06:43:59 -0500

Hi Lada,

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Dec 2017 13:36:35 +0100

On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> > > > Well, the issue is described in my initial mail of this thread: the
> > > > current 
> > > > text

s/contain/define/

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

>   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

> > > > > > >    In case 1 ["inline"], the mounted schema is determined at run
> > > > > > > time:
> > > > > > > every
> > > > > > >    creating the mount point.  Instances of the same mount point
> > > > > > > MAY
> > > > > > > use
> > > > > > > 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,
> > > > > > > could be done along with changing the YANG library structure, so
> > > > > > > there
> > > > > > > will be

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Dec 2017 07:49:08 -0500

> 1. For every configuration datastore there is a corresponding operational

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

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

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

> inline mount point in any configuration datastore.
Why is a mounted YL different than a top level YL?  What works for and
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?

Thanks,
Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Dec 2017 14:26:48 +0100

On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
> > > > > > > > unfortunately, using an action for querying embedded YANG
> > > > > > > > library
> > > > > > > > data
> > > > > > YANG library. Tha latter is state data, so the above requirement
> > > > > > cannot
> > > > > > be 

The thing is that we have the top-level YANG library in <operational>, and then
embedded YANG libraries scattered inside inline mount point instances.

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

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

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

> 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
> > > > > > > > >    mounted schema exactly as for a top-level data model.  A
> > > > > > > > > client
> > > > > > > > > is
> > > > > > > > >    expected to retrieve this data from the instance tree,
> > > > > > > > > possibly
> > > > > > > > > after
> > > > > > > > > - this operation would turn into an action for the mount
> > > > > > > > > point,
> > > > > > > > > and it
> > > > > > > > > can
> > > > > > > > > be