Re: [netmod] schema-mount pre09 branch

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote:
> Hi Juergen,
> 
> Thanks for your review, comments inline.
> 
> Juergen Schoenwaelder <[e-mail]> wrote:
> > 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.
> 
> 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...

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.
 
> > * 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;
> 
> 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".

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

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

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.
 
> > * 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.
> 
> I agree.  We can write:
> 
>   A client is expected to retrieve this data from the instance
>   tree in <operational>,
> 
> 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.

> > * 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.
> 
> Yes, but you can define a sinlge module-set and refer to it from both
> schemas.

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>