On 06/02/2018 14:16, Juergen Schoenwaelder wrote:
On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote:
Hi Juergen,

Thanks for your review, comments inline.

Juergen Schoenwaelder <j.schoenwael...@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.
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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to