Re: [netmod] js review of draft-ietf-netmod-schema-mount-09

[Martin Bjorklund <[e-mail]>]

Hi,

Juergen Schoenwaelder <[e-mail]> wrote:
> On Thu, Apr 05, 2018 at 02:33:40PM +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > Thank you for this review!  Comments inline.
> > 
> > Juergen Schoenwaelder <[e-mail]> wrote:
> > > Here is my review of draft-ietf-netmod-schema-mount-09.
> > > 
> > > * Abstract
> > > 
> > >    This document defines a mechanism to combine YANG modules into the
> > >    schema defined in other YANG modules.
> > > 
> > >   I do not know what this says - I think this text is confusing. What
> > >   does it mean to 'combine' YANG modules? What is the notion of
> > >   'schema' used here?
> > 
> > Howabout:
> > 
> >   This document defines a mechanism to add the schema trees defined by
> >   a set of YANG modules into the schema tree defined in another YANG
> >   module.
> >
> 
> This is better.
> 
> > (see more below on terminology)
> > 
> > >   Does the text help someone to decide whether
> > >   this mechanisms is something worth to study in order to solve a
> > >   given modeling problem?  (A good abstract would IMHO do that.)
> > > 
> > >   Note that the mount mechanisms has serious limitations as well that
> > >   perhaps need to spelled out right up-front, i.e., it only works with
> > >   pre-defined mount-points (augments are much more flexible in this
> > >   regard, the schema mount defined here is by its very design not
> > >   very flexible.
> > 
> > I don't agree that this is a "serious limitation", and I don't think
> > an abstract should list things that the document doesn't do.
> 
> OK. Remove 'serious' but clearly this schema mount mechanism is not as
> flexible as it could me. What about this:
> 
>    This document defines a mechanism to add the schema trees defined
>    by a set of YANG modules onto mount points defined in another YANG
>    module.
> 
> This at least hints at the fact that mount points are rather static
> citizens.

Ok.  I tweaked it to:

  This document defines a mechanism to add the schema trees defined
  by a set of YANG modules onto a mount point defined in the schema
  tree in some YANG module.

> > >   While I think I understand the difference made between
> > >   implementation-time and run-time, the description is somewhat
> > >   confusing since the run-time mount will also be exposed via YANG
> > >   library and hence defining implementation-time by 'defined by a
> > >   server implementor and is as stable as YANG library information of
> > >   the server' is somewhat fuzzy. I assume what you mean is that in the
> > >   case 2. the mounted schema is fixed at implementation time while in
> > >   the case 3. the mounted schema may vary and be discovered at
> > >   run-time. However, you do not define things this way but rather talk
> > >   about properties that do however not define things.
> > 
> > Howabout:
> > 
> > OLD:
> > 
> > + Run-time: the mounted schema is defined by instance data that is
> >   part of the mounted data model. 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.
> > 
> > NEW:
> > 
> > + Run-time: the mounted schema can vary at run time and is defined by
> >   instance data that is part of the mounted data model. 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.
> 
> Better.
>  
> > > * Glossary of New Terms
> > > 
> > >      o  top-level schema: a schema according to [RFC7950] in which schema
> > >       trees of each module (except augments) start at the root node.
> > > 
> > >   You do not import 'schema' from RFC 7950 since, well, it is not
> > >   defined in RFC 7950. I think you often mean a schema tree (as
> > >   defined in RFC 7950) when you use 'schema'. Well, even this is not
> > >   true since a 'schema tree' according to RFC 7950 is scoped to a
> > >   module. RFC 8342 defines a 'datastore schema' but then I am not sure
> > >   this corresponds to 'schema' as used in this draft. In fact, the
> > >   mounted schema may be considered part of the 'datastore schema'.  I
> > >   think we are handwaving with our terminology here but then perhaps I
> > >   am the only one who cares...
> > 
> > I have imported "schema tree" from 7950, and changed teh definition of
> > top-level schema to:
> > 
> > - top-level schema: a set of modules in which the schema
> >   trees of each module (except augments) start at the root node.
> 
> Still sounds complicated and not quite clear. Do you mean this:
> 
> - top-level schema: a set of schema trees of a set of modules starting
>   at the root node
> 
> > >   What we actually have are schema tree (of a module per RFC 7950) and
> > >   a collection of schema trees sharing a common root (this is likely
> > >   what is meant with "schema" in this document). And then schema mount
> > >   simply provides a mechanism to have additional (statically defined)
> > >   roots in a schema.
> 
> So what are you planning to do about the term 'schema' used throughout
> the module? We kind of define what a top-level schema is but leave
> schema undefined and perhaps we would also benefit from having a term
> like mounted schema. I am thinking along these lines:
> 
>   schema = collection of schema trees with a common root
>   top-level schema = schema rooted at the root node
>   mounted schema = schema rooted at a mount point
>   parent schema (of a mounted schema) = schema containing the mount point

These are good definitions, I have added them.  Thank you!

> > > * Multiple Levels of Schema Mount
> > > 
> > >   What is a 'subschema'? What is a 'schema level'? Is a subschema the
> > >   same as a schema, i.e. a collection of schema trees with a common
> > >   root? If we need terms such as 'subschema' or 'schema level', then
> > >   we should define them. But perhaps just some tweaking the text to
> > >   avoid new terms can solve the issue.
> > 
> > I have changed "subschema" to "schema", and removed "schema level":
> > 
> > NEW:
> > 
> >   YANG modules in a mounted schema MAY again contain mount points
> >   under which other schemas can be mounted.  Consequently, it is
> >   possible to construct data models with an arbitrary number of
> >   mounted schemas.  A schema for a mount point contained in a mounted
> >   module can be specified by implementing "ietf-yang-library" and
> >   "ietf-yang-schema-mount" modules in the mounted schema, and
> >   specifying the schemas exactly as it is done in the top-level
> >   schema.
> 
> OK 
> 
> > >   Why are parent-references only useful for the 'shared-schema' case?
> > >   An 'inline' mount can't refer to stuff outside the mount jail?
> > 
> > Correct.  We have debated if this makes sense for inline or not.  As
> > it is, the model is designed so that this can be added in the future,
> > if it turns out that this is needed.
> 
> OK
> 
> > >   Looking at the YANG definition of 'parent-reference', I am left
> > >   somewhat clueless in which situations these xpath expressions are
> > >   evaluations and when the nodesets are merged with other xpath
> > >   expression evaluation results.
> > 
> > The YANG module says:
> > 
> >              When XPath expressions in the mounted schema
> >              are evaluated, the 'parent-reference' leaf-list is taken
> >              into account.
> > 
> > and
> > 
> >                For the purposes of evaluating XPath
> >                expressions whose context nodes are defined in the
> >                mounted schema, the union of all these nodesets
> >                together with ancestor nodes are added to the
> >                accessible data tree.
> 
> OK. I probably did not read carefully enough. My understanding is now
> that the set of parent-reference xpath expressions yields a union of
> nodesets that are becoming part of the context for the evaluation of
> any xpath expression appearing in a mounted schema. And these parent
> references are specific to a mount point instance. May make sense.
> 
> > >   It seems that these parent references
> > >   are the only actual difference between 'inline' and 'shared-schema'
> > >   mounts.
> > > 
> > > * Data Model
> > > 
> > >   I have not really understood what the difference between 'inline'
> > >   and 'shared-schema' is. I understand that the later can have
> > >   'parent-references' but it is unclear why the other can't and if
> > >   there is not strong architectural reason why there have to be two
> > >   choices. It also seems that the 'namespace' list is only meaningful
> > >   if there are parent references, no? So why is this then global, i.e.
> > >   also provided for 'inline' mounts?
> > 
> > As you note, the 'namespace' list is global, so there is just one list
> > that covers all mount-points.  It's not really correct to state that
> > the 'namespace' list is "provided for 'inline' mounts".
> 
> OK. It seems that for a client capable to support a 'shared schema',
> the 'inline' schema really is just a special case without parent
> references. (I wonder whether anything should be said to YANG library
> version numbers, whether they are always scoped by the mount point
> or have meaning across mount points; if two YANG library instances
> in mounted schemas have the same version number, does this imply
> that these YANG library instances are identical or is this just a
> version number clash? But then this probably goes across the spirit
> of not talking about YANG library too much.)

When you say "version number" do you mean the YANG library checksum?
I don't think the YL document guarantees that there can never be
clashes.

> > >   I guess I do not really
> > >   understand the distinction. If there are no parent-references, what
> > >   is the difference between 'shared-schema' and 'inline'?
> > 
> > The difference is that shared-schema can have parent-references, and
> > that all instances of such a mount point have exactly the same
> > schema.
> 
> See comment above about YANG library version numbers. I am trying to
> understand which assumption a client can make to be efficient in both
> cases (and whether it is possible to be efficient while essentially
> handling inline and shared-schema using a common approach).
> 
> > > * Security Considerations
> > > 
> > >   I agree with others that something needs to be said how NACM applies
> > >   to mounted schemas.
> > 
> > I have added the following (short) section:
> > 
> > 7.  Interaction with the Network Configuration Access Control Model
> >     (NACM)
> > 
> >    If NACM [RFC8341] is implemented on a server, it can be used to
> >    control access to nodes defined by the mounted schema in the same way
> >    as for nodes defined by the top-level schema.
> > 
> >    For example, suppose the module "ietf-interfaces" is mounted in the
> >    "root" container in the "logical-network-element" list defined in
> >    [I-D.ietf-rtgwg-lne-model].  Then the following NACM path can be used
> >    to control access to the "interfaces" container (where the character
> >    '\' is used where a line break has been inserted for formatting
> >    reasons):
> > 
> >      <path xmlns:lne=
> >              "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"
> >            xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
> >        /lne:logical-network-elements\
> >          /lne:logical-network-element/lne:root/if:interfaces
> >      </path>
> 
> This helps. Can I also mount NACM into a mount point? If yes, what if
> both are present?

Yes you can mount NACM.  To keep things simple, I think the inner NACM
should not affect the access control done in the parent.  Consider the
use cases for this.  In a NI situation, it doesn't make much sense to
mount NACM.  In an LNE (or in a "peer mount") situation, it may make
sense to mount NACM if the LNE (or device) supports it.  In this case,
if I try to access any mounted data in the parent, access is
controlled by the parent.  If I have access, the parent may send a
request over to the mounted device to read/write the data.  That
device will use its local copy of NACM to control access, or some
other mechanism.


/martin