On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote: > Hi Juergen, > > Thanks for your review, comments inline. > > Juergen Schoenwaelder <[email protected]> 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
