Re: [netmod] schema-mount pre09 branch

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 06 February 2018 14:17 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB3C12E042 for <netmod@ietfa.amsl.com>; Tue, 6 Feb 2018 06:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWzaizAhZeSB for <netmod@ietfa.amsl.com>; Tue, 6 Feb 2018 06:17:00 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6F0126B72 for <netmod@ietf.org>; Tue, 6 Feb 2018 06:17:00 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 30283F91; Tue, 6 Feb 2018 15:16:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Vb9QAUdYYCgW; Tue, 6 Feb 2018 15:16:56 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Feb 2018 15:16:59 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15F4620149; Tue, 6 Feb 2018 15:16:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VOTy1vIdYJj8; Tue, 6 Feb 2018 15:16:58 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D708320147; Tue, 6 Feb 2018 15:16:57 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 08827423A4AD; Tue, 6 Feb 2018 15:16:55 +0100 (CET)
Date: Tue, 6 Feb 2018 15:16:55 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: kwatsen@juniper.net, netmod@ietf.org
Message-ID: <20180206141655.6iast3lbhubk6rk5@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, kwatsen@juniper.net, netmod@ietf.org
References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> <20180206.101949.156510094898094470.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180206.101949.156510094898094470.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/r_Z692LgUxLi6Ud-tIp9UKODJjI>
Subject: Re: [netmod] schema-mount pre09 branch
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 14:17:03 -0000

On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote:
> Hi Juergen,
> 
> Thanks for your review, comments inline.
> 
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>