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

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Apr 2018 14:33:40 +0200 (CEST)

Hi,

Thank you for this review!  Comments inline.

Juergen Schoenwaelder <[email-masked]> 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.

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

> * Introduction
>   s/Furthermore,//

Fixed.

>   'In some cases' ... 'often' - hm is this something that is required
>   occasionally or often? There are more uses of fill words like
>   'often' that do not really seem to be needed.

Fixed.

>   s/new generic mechanism/new mechanism/

Fixed.

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

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

>   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.
> 
> * Specification of the Mounted Schema
> 
>   I still struggle with the term 'inline' (and to a lesser extend with
>   'shared'). I am likely in the minority.

These terms are not perfect, but hopefully well-defined.

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

> * Referring to Data Nodes in the Parent Schema
> 
>   I stumbled across this here but in general is 'data model' the same
>   as 'schema'? Note that the text in section 4 talks about 'mounted
>   data model' and 'top-level data model' and 'mounted data model' but
>   elsewhere you talk about * schemas. Perhaps using just one term is
>   better and more consistent?

Yes, done.  Now using "schema" only.

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

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

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

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

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

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2018 14:24:06 +0200

>   a set of YANG modules into the schema tree defined in another YANG

This is better.

> 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.
 
>   entries of a list), the mounted data model may be different for each

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

> >   simply provides a mechanism to have additional (statically defined)

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

>   specifying the schemas exactly as it is done in the top-level

OK 

> if it turns out that this is needed.

OK

>                together with ancestor nodes are added to the

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.

> 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.)
 
> that all instances of such a mount point have exactly the same

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

>          /lne:logical-network-element/lne:root/if:interfaces

This helps. Can I also mount NACM into a mount point? If yes, what if
both are present?

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Apr 2018 15:27:10 +0200 (CEST)

Hi,

> This at least hints at the fact that mount points are rather static

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.

>   parent schema (of a mounted schema) = schema containing the mount point

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

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

> This helps. Can I also mount NACM into a mount point? If yes, what if

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Apr 2018 14:46:43 +0200

>   tree in some YANG module.

Works for me.

> I don't think the YL document guarantees that there can never be

Yes, the checksum (which I think is actually a version identifier).
Anyway, the question is whether a client can draw any conclusions from
seeing YANG library instances with the same checksum and whether a
client must simpy treat this as a clash. If multiple mounted schemas
have the same YANG library, then reading one of them would be
sufficient. The question is whether the checksum is a tool for
deciding whether a YANG library is similar to an already known one or
whether a client must not make this assumption, i.e., a checksum is
always scoped to the YANG library instance and you have to read them
all.

> device will use its local copy of NACM to control access, or some

In this scenarios, if the parent NACM grants access but the inner NACM
does not grant access, I assume I will not have access, right? So how
does this line up with "the inner NACM should not affect the access
control done in the parent"? Frankly, this is all a bit hypothetical
since we have no standards for doing peer mounts - and clearly not for
writable peer mounts. So probably the truth is that it is undefined
whether the inner NACM applies or not. Hm.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Apr 2018 16:15:46 +0200 (CEST)

> always scoped to the YANG library instance and you have to read them

Options:

1.  Be silent about the YL checksum in this document.

2.  State that the server MUST ensure that if two mounted YL
    instances have the same checksum, then the YL contents MUST be
    the same.

3.  State that just b/c the YL checksum is the same in two mounted
    instances, it does not mean that the YL contents is the same.

4.  State that for use-schema, the YL contents and YL checksum MUST be
    the samem but for inline, equal YL checksum is no guarantee for
    equal YL contents.

>From a client perspective, 2 is preferrable.  It is probably not
difficult to implement on a server either; except in the peer mount
case where the data is just read from some device.

> whether the inner NACM applies or not. Hm.

But maybe this is something that needs to be handled when we define
peer mount?  The question is if we need to add any text to this
document?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Apr 2018 16:34:16 +0200

> case where the data is just read from some device.

The more I think about it, it seems option 4. is the right thing to
do.
 
> peer mount?  The question is if we need to add any text to this

I think it is sufficient to say that the server's NACM rules apply to
mounted data. (In the peer mount case, it should not matter whether
the peer's NACM is mounted or not, the peer's NACM applies anyway when
the peer is accessed - but it may be accessed a username identity that
is different from the username identity used to access the mounted
data.)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Apr 2018 22:58:00 +0200 (CEST)

> The more I think about it, it seems option 4. is the right thing to

Ok.  How about adding two sentences at the end of the last paragraph
in section 3.3, giving: 

  The mounted schema is determined at run time: every instance of the
  mount point that exists in the operational state MUST contain a copy
  of YANG library data that defines the mounted schema exactly as for
  a top-level schema. A client is expected to retrieve this data from
  the instance tree, possibly after creating the mount point.  In the
  "inline" case, instances of the same mount point MAY use different
  mounted schemas, whereas in the "shared-schema" case, all instances
  MUST use the same mounted schema.  In the "inline" case, if two
  instances have the same YANG library checksum it is not guaranteed
  that the YANG library contents are equal for these instances.

> mounted data.

Ok.

> (In the peer mount case, it should not matter whether

Yes, this is a good point.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Apr 2018 08:20:21 +0200

>   that the YANG library contents are equal for these instances.

This text says "A client is expected to retrieve this data from the
instance tree, possibly after creating the mount point.", which seems
a bit odd. How does a client create a mount point? First, a mount
point is created by defining it in a YANG module, so this is
specification time not runtime. Perhaps you mean 'instantiated' rather
than 'created' but even then it is somewhat unclear how a client does
that in general. Perhaps simple drop ', possibly after creating the
mount point'.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Apr 2018 08:46:42 +0200 (CEST)

> that in general. Perhaps simple drop ', possibly after creating the

Ok, I will do that.

/martin

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 Apr 2018 10:45:10 -0400

Hi,
	I have a suggested minor clarification below.

----------

>> > > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote:
...
>> that in general. Perhaps simple drop ', possibly after creating the

I suggest adding to text to make it unambiguous that the MUST applies to 
the same mount point nodes in a schema, perhaps:
OLD
    all instances MUST
NEW
    all instances of the same mount point MUST

Lou

>
> /martin
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>