Subject: Re: [netmod] schema-mount pre09 branch

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Feb 2018 09:33:44 +0100

On Wed, Jan 31, 2018 at 09:36:07PM +0000, Kent Watsen wrote:
> 
> The authors created a "pre09" branch on GitHub a few weeks back.  On this branch, they completed a full update of the draft.  While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed.  With this in mind, can folks please have a quick look and post any technical comments they have?  
>

I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched
today from GitHub. Here are my comments:

* Perhaps the abstract can be improved. The single sentence that we
  have is not even quite correct.

   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.

  According to YL bis, a datastore has a schema, which consists of a
  set of YANG modules. The terminology used in RFC 7950 is 'schema
  node' and 'schema tree'. Perhaps this sentence can be rewritten to
  better explain the purpose of this document.

* The following text is not consistent with what YLbis says:

   2.  Implementation-time: the mounted schema is defined by a server
       implementor and is as stable as YANG library information, i.e.,
       it may change after an upgrade of server software but not after
       rebooting the server.  Also, a client can learn the entire schema
       together with YANG library data.

  YLbis does allow YANG library to change. I think this text should
  change as follows:

   2.  Implementation-time: the mounted schema is defined by a server
       implementor and is as stable as YANG library information of the
       server. A client can learn the entire schema by reading the
       server's YANG library data.

   I think 3. should also be changed. The phrase 'is part of the
   mounted data model' may not be exactly true with NMDA - well
   depending what the 'mounted data model' really means. Perhaps
   something like this:

   3.  Run-time: the mounted schema is defined by instance data that
       is associated with the mount point and reported outside the
       server's YANG library information. If there are multiple
       instances of the same mount point (e.g., in multiple entries of
       a list), the mounted data model may be different for each
       instance.

* Terminology - should this document import the terms client, server,
  notification from the NMDA document instead of the NETCONF document?
  I assume the terms are understood more broadly than just NETCONF
  client and server.

* Definition of inline schema:

   o  inline schema: a mounted schema whose definition is provided as
      part of the mounted data, using YANG library
      [I-D.ietf-netconf-rfc7895bis].

   I am not sure 'as part of the mounted data, using YANG library' is
   a good definition. Which YANG library? I think what this term means
   is a mount point specific YANG library, not the master server's
   YANG library.

   This is also why I was largely confused about the inline case; the
   schema used by the mountpoint is not defined inline from the master
   server's point of view, from which the document is written. From
   the master server's point of view, the 'inline schema' is actually
   the opposite, it is an 'external schema' since I have to pull the
   schema information from an external source; the schema is not
   reported with the server's schema information - this is what I
   would consider inline.

   It may be too late to change this term but at least for me 'inline'
   has been very confusing since we describe everything from the
   perspective of the master server.

  Later on, the phrase "use-schema" case is used as well. Perhaps this
  should also be a defined term and a better term should be used. The
  terms should describe the concepts and the YANG model should follow;
  what we have is kind of backwards, there is a YANG model and then
  model names are used a conceptual terms.

* YANG library stability

  I reported this already. The statement 'In particular, it SHOULD NOT
  change during the same management session.' is not consistent with
  what YL and YLbis say.

* YANG library has a drawing of the underlying conceptual model. It
  may help to agree on how schema mount is extending the model. Here
  is a drawing that I created for myself:

        +-----------+
        | datastore |
        +-----------+
             |
             | has a
             V
        +-----------+            +--------+                +------------+
        | datastore |  union of  | module |  consists of   | modules +  |
 .----->|  schema   |----------->|  set   |--------------->| submodules |
 |      +-----------+            +--------+                +------------+
 |           |
 |           | has
 |           v
 |      +-----------+
 '------|   mount   |------>  external YANG library
   uses |   points  | uses	schema reference
        +-----------+

  Note that this makes drawing makes my struggle with the term
  'inline' even more obvious. If you look at this figure, then inline
  would mean the exact opposite of what 'inline' means today.

* Where is the schema defined in the external aka 'inline' case?
  The current text says:

   In case 1, 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 [I-D.ietf-netconf-rfc7895bis]
   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.

  I think this does not work for datastores except the operational
  datastore. In fact, I think the model must be that if /foo is an
  external 'inline' mountpoint, then the /foo instance in the
  operational state datastore must include a YANG library
  instantiation in which a client can find the schema definition for
  /foo in any datastore where /foo is supported. In other words, if
  /foo is config true and a client wants to know how the /foo schema
  in <running>, then the client has to fetch the YANG library residing
  under /foo in <operational> in order to obtain the schema
  information for the <running> datastore. The text does not say any
  of this.

* Where is the schema defined in the inline aka 'not inline' case?
  The current text says:

   In case 2, the mounted schema is defined by the combination of all
   "schema" entries referred to in the "use-schema" list.

  I think the YANG model refers to a single schema. I think this text
  needs to be revised and aligned with the new data model. This like
  applies to other places in the document where "use-schema" is
  discussed.

  I do not understand the following statement:

   [...] Note, that in this case a mount point may include a mounted
   YANG library module and the data contained in the mounted module MUST
   exactly match the data contained in the "schema" entries associated
   with the mount point.

  There is text about a "schema" list in 3.2 that I think is not
  needed anymore.

* RPC operations and notifications

  "clients can invoke this operation by representing it as an action
  defined for the corresponding mount point"

  The wording 'invoke ... by representing" seems wrong. I think this
  should be "clients can invoke this operation as if it were defined
  as an action for the corresponding mount point" or something like
  this.

  Should there be additional text discussing how parameters of
  operations and notification content is interpreted? I assume
  everything is scoped to the mount point but perhaps this needs to be
  stated explicitly.

* Data model

  The model is augmenting /yanglib:yang-library/yanglib:schema. In
  the case where I had two different schemas defined for say the
  operational state datastore and conventional datastores, this
  implies that I have to duplicate the schema-mounts specific
  definitions even in the likely case where the schema mounts are
  identical in both datastores. (For the extern 'inline' case they
  actually have to be the same or at least the operational state
  datastore schema-mounts have to be a superset of the conventional
  datastore schema-mounts since otherwise I can't get the schema
  information. So the question is whether schema-mount should be a
  list directly under /yanglib:yang-library and then
  /yanglib:yang-library/yanglib:schema would be augmented by a leaf
  (or a leaf-list) referring to schema-mount entries.

* YANG definitions

  I think the description of the leaf 'inline' [yeah, this should be
  'external'] needs to be updated to explain where in an NMDA system
  the YANG library information can be found.

  And yes, 'use-schema' is really what I call 'inline' - the schema
  information is provided as part of the YANG library defining the
  mount point.

* Security considerations

  I was expecting text that explains how NACM works on a server that
  has schema mounts, discussing both cases, the inline and external
  schema mount cases.

* Examples

  I have not reviewed the examples.

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Feb 2018 10:19:49 +0100 (CET)

Hi Juergen,

Thanks for your review, comments inline.

>   better explain the purpose of this document.

Maybe something along the lines of:

  This document defines a mechanism to extend a datastore schema with
  other schemas.

It is still a bit terse...

>        server's YANG library data.

Yes this is better.

>        a list), the mounted data model may be different for each

Ok.

>   notification from the NMDA document instead of the NETCONF document?

Ok + "datastore schema".

>    schema information from an external source;

No this is not quite correct.  It is "inline" from the master's point
of view, in the sense of "inline in the data tree", as opposed to
"part of the (augmented) yang-library schema definition".

And it is *not* external.  The client still fetches this data from the
"master" server; and how the master server handles this is an
implementation detail (or possibly standardized in the future - *one*
use case is peer mount in which case the data is fetched from another
system, but again, this is just one example).

>    the schema is not
>   should also be a defined term

Ok, this makes sense.

>   and a better term should be used. The

I agree.

>   'inline' even more obvious.

I like the drawing, but I don't see the problem with the terms.  Maybe
just b/c I'm used to them.  I think we can include this figure but
s/external/inline/

>   If you look at this figure, then inline

I agree.  We can write:

  A client is expected to retrieve this data from the instance
  tree in <operational>,

and possibly add your example.

>   needs to be revised and aligned with the new data model.

Yes.  There is just one schema, and we should write "yanglib:schema"
to clarify that the "schema" node is defined in YL(bis).

>   This like

Yes, will remove.

>   as an action for the corresponding mount point" or something like

Ok.

>   everything is scoped to the mount point but perhaps this needs to be

I think this handling follows from "as if it was defined as an
action...".

>   identical in both datastores.

Yes, but you can define a sinlge module-set and refer to it from both
schemas.

>   (For the extern 'inline' case they

Ok, we should add that it is available in <operational>.

>   has schema mounts, discussing both cases, the inline and external

We had a discussion about this on the ML, I have to get back and
re-read it.

/martin

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Feb 2018 13:43:23 +0000

> just b/c I'm used to them.  I think we can include this figure but
I think that Juergen's diagram is helpful.

I also think that there needs to be some text to help explain how mount 
points interact with datastores.  I.e. each datastore can have separate 
mount points so data could be mounted in <running> but not <operational> 
or vice-versa.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Feb 2018 13:45:36 +0000

Hi,

Some comments on the pre-09 version, particularly the data model.

1) I still don't get why this draft is called "YANG Schema Mount" rather 
than "YANG Mount", since to me this implies that it *only* the schema 
that is being made available, and by implication not the instance data.  
I.e. I can see what schema a VM is using, but I cannot access the 
instance data of that VM.

I understand the scope of the draft (and I'm not trying to change that 
at all), and agree that it doesn't specify any protocol for how to 
remotely mount data (e.g. peer mount).  But my understanding of the 
solution here is that it doesn't just mount the schema.  I think that it 
also always makes the mounted instance data available using the regular 
NETCONF/RESTCONF operations right?  Which sounds like it is doing more 
than just mounting the schema!

2) Regarding the YANG Data Model:

(i) Should "schema-mounts" just be "mounts", since it is already under 
the "schema" container.

(ii) Should "parent-references" be part of the "use-schema" container, 
or should then be part of a schema directly.  E.g. should schema-mount 
augment yanglib:schema with both a "mounts" container and a 
"parent-reference" leaflist.

(iii) Do we definitely need the namespace list?  Shouldn't the 
prefixes/namespaces be resolved against the implemented modules in the 
referenced schema, or is this not sufficient?  If this is not 
sufficient, I wonder if it would be helpful for the draft to describe this.

(iv) I agree with Juergen that "inline" is a confusing term because it 
is meaning that the mounted schema is available inline in the instance 
data tree, not that it is inline in the schema tree.

Thanks,
Rob

On 31/01/2018 21:36, Kent Watsen wrote:
> All,
> The "txt" version of the draft:  https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
>
>
> rfcdiff against the current -08 draft:  https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
>
>
> Since rfc7895bis obsoletes RFC 7895, the server-must-implement-rfc7895bis requirement is no surprise, right?
>
> Thanks,
> Kent // shepherd
>
>
> .

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Feb 2018 15:00:49 +0100 (CET)

Hi,

Thanks for your comments, see inline.

Robert Wilton <[email-masked]> wrote:
> 1) I still don't get why this draft is called "YANG Schema Mount"
> rather than "YANG Mount", since to me this implies that it *only* the
> schema that is being made available, and by implication not the
> instance data.  I.e. I can see what schema a VM is using, but I cannot
> access the instance data of that VM.
> 
> solution here is that it doesn't just mount the schema.  I think that
> it also always makes the mounted instance data available using the
> regular NETCONF/RESTCONF operations right?  Which sounds like it is
> doing more than just mounting the schema!

Once you have a mounted schema, even in the inline case, a server
might be just a single normal server with no extra VMs or anything;
you just have a nested schema.  Such a server would allow you to use
normal edit-config to add mounted data, and it would just affect that
single server's database and instrumentation.

The point is that schema mount says nothing about *how* things are
instantiated.

Peer mount, OTOH, attaches instance-specific meaning to its mount
points - if you try to write to peer mounted data the server will act
as a "proxy" and write to the remote server.  (ok, current peer mount
is defined to be read-only, but you get my point).

> (i) Should "schema-mounts" just be "mounts", since it is already under

I don't have a strong opinion on this.

> "parent-reference" leaflist.

This would mean the same parent-references for all mount points in a
schema, as opposed to per-mount-point parent-references as we have
today.  Lada, what's your opinion on this?

> sufficient, I wonder if it would be helpful for the draft to describe

It is not sufficient b/c the only prefixes available from the
implemented modules are the prefixes in the modules themselves, and
they aren't necessarily unique.

/martin

> > The authors created a "pre09" branch on GitHub a few weeks back.  On
> > this branch, they completed a full update of the draft.  While waiting
> > for details on how to proceed with regards to a SM-bis, we thought it
> > would be helpful to make this text available now so that the technical
> > parts can be discussed.  With this in mind, can folks please have a
> > quick look and post any technical comments they have?
> >
> >
> > The "txt" version of the draft:
> > https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
> >
> >
> > rfcdiff against the current -08 draft:
> > https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
> >
> >
> > Since rfc7895bis obsoletes RFC 7895, the
> > server-must-implement-rfc7895bis requirement is no surprise, right?
> >
> > Thanks,
> > Kent // shepherd
> >
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Feb 2018 15:16:55 +0100

> It is still a bit terse...

One question here is: Does the datastore schema include the mounted
schema tree or not? We can side step this question by writing:

  This document defines a mechanism to extend a YANG schema tree with
  other schema trees.

This is still terse but I think in terms of terminology this is
clear and correct.
 
> "part of the (augmented) yang-library schema definition".

This means its inline from the viewpoint of the mounted data, it is
external from the viewpoint of the master. You are swapping the
viewpoint here.
 
> system, but again, this is just one example).

It is external from the viewpoint of the master servers YANG library. The
schema sits in a different YANG library instantiation. I have to fetch
this separately. This makes it kind of external for me.
 
> just b/c I'm used to them.  I think we can include this figure but

Inline suggests to me that the schema details are reported inline of
this YANG library instantiation, i.e. the opposite of today's "inline"
case. In today's "inline" case, I have to fetch a different YANG
library instance and look things up there. I find it very confusing to
call this "inline" and the inline case "use-schema". I understand the
resistance to change terms at this point in time but then the figure
makes it somewhat obvious why "inline" confused me a lot since I look
at things from the master server's perspective, i.e., from the master
server's yang library perspective.
 
> and possibly add your example.

Better but I would prefer to have a very clear description how the
client resolves "inline" schemas by consulting other instantiations of
the YANG library - and how this works with NMDA datastores. An example
likely helps.

> Yes, but you can define a sinlge module-set and refer to it from both

Well, the modules supported by the two datastore schemas can be
different so I have to have two schema definitions...

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Feb 2018 14:39:27 +0000

Hi Martin,

> single server's database and instrumentation.
OK.  So, it is not just the schema that is available, but also the 
instance data associated with that schema.

I agree.

But I think that is also consistent with how the term "mount" is used 
from its Unix heritage.

I.e. just because some data is mounted doesn't imply that it is remote.  
E.g. if I look at my Linux VM's /etc/mtab I see a dozen mount points, 
only one of which I would class as being remote (from the perspective of 
the VM).

Whereas, to me the term "schema mount" implies that it is only the 
schema that are being mounted.  Why would there be instance data 
available if the only thing that is being mounted is the schema?

> is defined to be read-only, but you get my point).
Yes, OK.  But I don't think that the term "YANG Mount" implies "Peer mount".

Extending the filesystem analogy further, I think that YANG mount tell 
you the mounted path, whether it is read/write, and where to find the 
schema.  It doesn't specify what protocol is being used to access that 
data.  E.g. in future I could imagine that peer mount might want to 
augment the mount-point/inline to indicate further properties about the 
mount point.  But this would seem to be somewhat odd if what it is 
augmenting is a "YANG schema mount" rather than just a "YANG mount".

> they aren't necessarily unique.
OK.  So would another choice could be to rather than having the 
namespace map from  prefix to namespace, instead have it as a map from 
prefix to module name (which is resolved against the implemented modules 
in the parent schema(s))?

The URI would still be available form the module entry in the parent 
schema (if required).  I'm just wondering whether this would make the 
binding feel a bit less XML encoding specific.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Feb 2018 15:25:52 +0000

> this separately. This makes it kind of external for me.
I think that the term "external" could also be confusing, since I think 
that sort of implies peer mount like semantics.

I would suggest the term "dynamic" instead of "inline " but that could 
easily be confused with dynamic datastores.

Perhaps rather than "inline" another choice could be "discoverable", 
i.e. the schema is not known, and is dynamically discoverable inline at 
the mount point.
Equally, rather than "use-schema", perhaps a better choice would be 
"known", i.e. the schema is already known, and made available as part of 
YANG library.

Whether it would be right to change these at this time, I've no idea ...

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Feb 2018 10:48:45 +0100

On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote:
> 
> I think that the term "external" could also be confusing, since I think that
> sort of implies peer mount like semantics.

The "inline" mount concept seems to subsume peer mounts. From the
model perspective, is there a difference whether the mounted data is
local or remote (and what does local/remove mean for a VM)?
 
> easily be confused with dynamic datastores.

Yes, I think this is not a good word either.

> Perhaps rather than "inline" another choice could be "discoverable", i.e.
> the schema is not known, and is dynamically discoverable inline at the mount
> point.
> Equally, rather than "use-schema", perhaps a better choice would be "known",
> i.e. the schema is already known, and made available as part of YANG
> library.

Perhaps integrated schema vs. mounted schema.

> Whether it would be right to change these at this time, I've no idea ...

Yep.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Feb 2018 11:14:41 +0100 (CET)

> Perhaps integrated schema vs. mounted schema.

I like the term "integrated" better than "use-schema".  But both cases
are mounted, so we need another term than "mounted" for "inline".
"segregated" doesn't sound quite right ;-)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Feb 2018 11:21:33 +0100

> "segregated" doesn't sound quite right ;-)

integrated schema vs. separated schema

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 07 Feb 2018 11:29:21 +0100

On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote:
> > > that
> > > "known",

I would prefer to use the term "mount" only for the inline case and find
something else for the use-schema case. The term "mount" evokes that some
*instance* data being added, which is what happens in the "inline" case but not
for "use-schema".

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Robert Wilton <[email-masked]>
Date: Wed, 7 Feb 2018 11:41:42 +0000

> *instance* data being added, which is what happens in the "inline" case but not

Perhaps the "use-schema" case really is a type of "schema mount", where 
as the "inline" case is a type of "mount".

Perhaps they could/should have entirely separate YANG models to describe 
them.  Possibly in the "use-schema" case could refer to grafting a 
schema into a parent schema rather than mounting it.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 07 Feb 2018 13:18:26 +0100

On Wed, 2018-02-07 at 11:41 +0000, Robert Wilton wrote:
> > > > > i.e.

This may be quite confusing. My suggestion for "use-schema" is "external
augment" - the mount point as a *schema node* plays a very similar role to the
target node of an augment.

> schema into a parent schema rather than mounting it.

I proposed this previously. The inline case could in fact be considerably
simplified because the extension statement is all that's needed - no state data.
In other words, the "mount-point" extension would immediately indicate the
inline mount.  

In order to distinguish the use-schema case (or whatever we call it) we have
then two options:

1. use a different YANG extension for labelling mount points of this type

2. use schema node identifiers as in augments (i.e. no extension at all).

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Feb 2018 13:27:16 +0100 (CET)

Hi,

It seems we're now just reiterating what has previously been discussed
*a lot*.  IMO, highest prio is to resolve any issues related to YLbis.
If we also need other clarifications to make the document easier to
understand, that's fine.  But I don't think we should fundamentally
change the solution that the WG agreed upon.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 07 Feb 2018 13:49:00 +0100

> *a lot*.  IMO, highest prio is to resolve any issues related to YLbis.

I've always missed a technical merit in those discussions. It has always been
like "I prefer that solution", "This is not how our implementation works", "It
is good enough for LNE/NI" etc. But maybe I missed something so please point me
to discussions that demonstrate why the adopted solution is better than what I
am proposing. I am arguing that it is exactly the other way around. The inline
and use-schema cases are different concepts and mixing them together makes the
whole thing needlessly complex to describe and understand.

> change the solution that the WG agreed upon.

I don't agree that we are *strongly* changing the solution. Simplifications and
clarifications are IMO badly needed.

Lada  

> > > > > > > I would suggest the term "dynamic" instead of "inline " but that
> 
> could
> > > > > > > Perhaps rather than "inline" another choice could be
> 
> "discoverable",
> > > > > > > i.e.
> > > > > > > the schema is not known, and is dynamically discoverable inline at
> 
> the
> > > > > > > mount
> > > > > > > point.
> > > > > > > Equally, rather than "use-schema", perhaps a better choice would
> 
> be
> > > > > > > "known",
> > > > > > > i.e. the schema is already known, and made available as part of
> 
> YANG
> > > > > > > library.
> > > > > > 
> > > > something else for the use-schema case. The term "mount" evokes that
> 
> some
> > > > *instance* data being added, which is what happens in the "inline" case
> 
> but
> > > > not
> > > > for "use-schema".
> > > 
> > augment" - the mount point as a *schema node* plays a very similar role to
> 
> the
> > simplified because the extension statement is all that's needed - no state
> 
> data.
> > > > > > > Whether it would be right to change these at this time, I've no
> 
> idea
> > > > > > > ...
> > > > > > 
> > > > > > Yep.
> > > > > > 
> > > > > > /js
> > > > > > 
> > > > > > -- 
> > > > > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> 
> Germany