Subject: [netmod] schema mount open issue #1

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Aug 2017 12:20:22 +0200 (CEST)

Hi,

Lada presented an open issue in schema mount in Prague.  (See slide 6
in
https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)

The original problem comes from the NI use case
(https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
use case, interfaces are assigned to NIs by:

   augment /if:interfaces/if:interface:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name

Modules that are mounted within the NI might have references to
interfaces.  The idea is that a specific NI can only reference the
interfaces that has been assigned to it.

In schema mount, we have the "parent-reference" XPath expression that
in this case will be "/if:interfaces/if:interface".  The problem is
that this XPath expression will evaluate to a node set that contains
*all* interfaces in the system.  We would like this to contain just
the interfaces assigned to the NI.

It turns out that this can be done with a simple change to the
"parent-reference" node.  If we state that this XPath expression is
evaluated in an XPath context where the context node is the node in
the data tree where the mount point is defined (instead of "/"), we
can use as parent-reference:

  /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]

Putting this together we'd have:

  augment "/if:interfaces/if:interface" {
    leaf bind-ni-name {
      type leafref {
        path "/network-instances/network-instance/name";
      }
    }
  }

  container network-instances {
    list network-instance {
      key name;
      leaf name { ... }
      ...
      container root {
        // this would be the XPath context root for parent-reference
        yangmnt:mount-point ni-root;
      }
    }
  }

And in state data:

"ietf-yang-schema-mount:schema-mounts": {
  "namespace": [
    {
      "prefix": "ni",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
    },
    {
      "prefix": "if",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
    }
  ]
  "mount-point": [
    {
      "target": "/ni:network-instances/ni:network-instance/ni:root",
      "parent-reference": [
            "/if:interfaces/if:interface
             [ni:bind-network-instance-name = ../ni:name]"
                          ],
      "use-schema": [
        {
          "name": "ni-schema"
        }
      ]
    }
  ]

Note that this does NOT affect the schema that is mounted; it only
affects the result of the parent-reference XPath expressions.

I think that we should make this change, since it allows for more
precise parent-references.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Aug 2017 11:16:27 +0000

Hi Martin, 

>        path "/network-instances/network-instance/name";

Would this work if network-instances is mounted somewhere other than the
root? For example, what if network-instances is mounted in within an LNE
(Logical Network Element)?

Thanks,
Acee 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Aug 2017 13:52:10 +0200 (CEST)

> (Logical Network Element)?

Yes it will work, since the /if:interfaces will refer to the
interfaces within the LNE.  (Note that this does not change with my
proposal)

/martin

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Aug 2017 14:33:25 -0400

Hi Martin,

See below.

>         yangmnt:mount-point ni-root;

note that the current NI definition is:

   module: ietf-network-instance
     +--rw network-instances
        +--rw network-instance* [name]
           +--rw name           string
           +--rw enabled?       boolean
           +--rw description?   string
           +--rw (ni-type)?
           +--rw (root-type)?
              +--:(vrf-root)
              |  +--mp vrf-root?
              +--:(vsi-root)
              |  +--mp vsi-root?
              +--:(vv-root)
                 +--mp vv-root?
   augment /if:interfaces/if:interface:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name
   augment /if:interfaces/if:interface/ip:ipv4:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name
   augment /if:interfaces/if:interface/ip:ipv6:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name

>       "target": "/ni:network-instances/ni:network-instance/ni:root",
Can you confirm that with the current definition the target is:

      "target": "/ni:network-instances/ni:network-instance",

correct?

>              [ni:bind-network-instance-name = ../ni:name]"
Also, can you confirm that if we wanted to cover v4, v6 (for example
purposes) interfaces-state, the full parent reference list would be:

      "parent-reference": [
            "/if:interfaces/if:interface
             [ni:bind-ni-name = ./ni:name]",
            "/if:interfaces/if:interface/ip:ipv4
             [ni:bind-ni-name = ./ni:name]",
            "/if:interfaces/if:interface/ip:ipv6
             [ni:bind-ni-name = ./ni:name]",
             "/if:interfaces-state/if:interface"

 correct?

Note that interfaces-state isn't filtered as the bind-ni-name isn't
present in -state.

> precise parent-references.
I'm okay with the change (just want to see the draft moved forward ;-)

Lou
(As contributor)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Aug 2017 08:29:06 +0200 (CEST)

> note that the current NI definition is:

Yes I saw that.

>            +--rw description?   string

Note that the extension yangmnt:mount-point can only be present in a
container or list, not in a choice/case.

But what is the point of a choice with three different mount points?

>       "target": "/ni:network-instances/ni:network-instance",

See above; the current definition is invalid.

> >              [ni:bind-network-instance-name = ../ni:name]"

Correction.  This should be:

            "/if:interfaces/if:interface
             [ni:bind-network-instance-name = current()/../ni:name]"

>              "/if:interfaces-state/if:interface"

No it would be:

  /if:interfaces-state/if:interface[
    if:name = /if:interfaces/if:interface[
      ni:bind-ni-name = current()/../ni:name]/if:name]

etc.

I.e., the interfaces in -state that that has the same names as the
interfaces in config that has the correct bind-ni-name.

/martin

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Aug 2017 08:50:15 -0400

Martin,
See below

> container or list, not in a choice/case.

Okay, I missed that restriction in your draft.  What's the reason for
not allowing mounts under choices/cases?  Isn't the resulting path to
data nodes indistinguishable when the parent is a list or container?

> See above; the current definition is invalid.

this is going to get really verbose if schema mount's restrictions
remain as we'll need a container and target per case mount point case.

Looking at this issue leads me to ask the question: why are parent
references tied to the mount point vs the schema?  Are the parent
references always going to the same in order for the schema to make
sense.  I think this question is separable from the restriction
discussion above, but it does help if we stick with the current
restrictions.

To be clear I'm suggesting:
Drop parent-reference from:

          |  +--ro (schema-ref)?
          |     +--:(inline)
          |     |  +--ro inline?       empty
          |     +--:(use-schema)
          |        +--ro use-schema* [name]
          |           +--ro name
          |           |       -> /schema-mounts/schema/name
          |           +--ro parent-reference*   yang:xpath1.0

and add it to

          +--ro schema* [name]
             +--ro name           string
             +--ro parent-reference*   yang:xpath1.0

> interfaces in config that has the correct bind-ni-name.

okay, nice xpath foo

Thanks,
Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Aug 2017 12:28:45 +0200 (CEST)

> data nodes indistinguishable when the parent is a list or container?

Suppose a server lists a couple of modules for "vrf-root" and some
other for "vsi-root" in the /schema-mounts/mount-point list.  How can
a client tell if a certain NI instance is has the "vrf" modules or
"vsi" modules?

In general, when you have a choice with cases, all nodes from all
cases are disjoint, and the client can tell which case is active by
checking which nodes are present.

Wouldn't it be possible to restructure as bit so you have:

   choice ni-type {
     container vrf {
       ymt:mount-point vrf-root;
       // additional vrf-specific config params goes here
     }
     container vsi {
       ymt:mount-point vsi-root;
       // additional vsi-specific config params goes here
     }
     ...
   }

> references tied to the mount point vs the schema?

This gives more flexibility, since several mount points can share a
single schema.  Also, if we had parent-reference per schema, we cannot
solve the original issue that started this thread.

> Are the parent

/martin

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Aug 2017 07:27:37 -0400

Martin,
	See below.

> a client tell if a certain NI instance is has the "vrf" modules or

umm, my understanding is that only one of the cases under a choice can
be present in the data (tree) at a time so the client *can* only see one
 mount point {vrf-root, vsi-root or vv-root} node and all the mounted
schemas will be under that '-root' node.  What have I missed?

>        // additional vsi-specific config params goes here

Yes, but there will *never* be any additional type specific parameters
in the container (by definition), so the container serves no purpose and
just adds to the path unnecessarily.

> single schema.

from my (user) perspective, the parent references are an equally
intrinsic part of the schema and the flexibility adds unneeded complexity.

>  Also, if we had parent-reference per schema, we cannot

We/I can live with the current solution (and its overhead), so this
isn't a critical discussion.  Let's focus on the open point covered above.

Thanks,
Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Aug 2017 13:35:07 +0200 (CEST)

> schemas will be under that '-root' node.  What have I missed?

The mount point itself is not a node.  So the client will just see
some mounted top-level nodes.  If you require that all mount points
have disjoint sets of modules, then this could work.  But I assume
that this is not the case.

> in the container (by definition)

Why is that?  Why not have them in the same container?

Hmm, maybe in general it is better to not mix mounted data with normal
data in the same container.

> so the container serves no purpose and

Well, its presence would inform the client about which mount point is
used, so I don't think it is unnecessary.

/martin

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Aug 2017 08:54:24 -0400

On 8/28/2017 7:35 AM, Martin Bjorklund wrote:
> The mount point itself is not a node.  
okay, I think we're getting to the crux of this issue!  I certainly
didn't see this (that a schema-mount root node is *not* represented in
the data, but only in the schema) stated in
draft-ietf-netmod-schema-mount.  In fact, I read the text as saying just
the opposite:

   The basic idea of schema mount is to label a data node in the parent
   schema as the mount point, and then define a complete data model to
   be attached to the mount point so that the labeled data node
   effectively becomes the root node of the mounted data model.

Why don't you think an MP should be represented in the data (tree)?

In our example usage
(https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B) we
include the mount point as a node in the data.  You're saying that this
doesn't line up with your expectation, right?

Can you please take a look at it and see if we have any other disconnects?

> So the client will just see

<rest trimmed>

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Aug 2017 15:30:29 +0200

> draft-ietf-netmod-schema-mount.  In fact, I read the text as saying just

I don't think so, it just says that an (existing) node in the parent schema gets
the mount-point label. The mount-point extension itself generates no extra node.

If we used schema node identifiers denoting the mount points instead of the
extension (as I proposed earlier), there would be no additions to the schema
proper, so this confusion couldn't arise.

> Can you please take a look at it and see if we have any other disconnects?

This is really scary. How can we expect poor data modellers to understand the
concept if we have such fundamental disconnects, after so many hours of
discussing it?

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Aug 2017 09:40:15 -0400

Lada,

On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
> This is really scary. 
I agree!

> How can we expect poor data modellers to understand the

This highlights why getting the text in (any) document is so important,
and why discussions shouldn't be viewed as being closed until the impact
on the text is agreed to!

Lou

PS is your view aligned with martin or our example?

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Aug 2017 16:16:19 +0200

> on the text is agreed to!

I think many people still don't make much distinction between schema mount
(manipulation of the schema) and data mount. I still believe we need to clearly
separate these two concepts, preferably using two different mechanisms.

Moreover, draft-clemm-netmod-mount-06 adds heavily to this confusion. I myself
feel dizzy when reading e.g. this:

     extension mountpoint {
       argument name;
       description
         "This YANG extension is used to mount data from another
          subtree in place of the node under which this YANG extension
          statement is used.
          ..."

See? The data has to be placed to a *data tree*, and the extension is used in
the *schema tree*, but the description talks about just one node.

> PS is your view aligned with martin or our example?

If you mean shifting the XPath context node to the mount point instance, then
yes.

Lada

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Aug 2017 15:13:25 -0400

Lada,

> separate these two concepts, preferably using two different mechanisms.

Frankly, I'm focused on removing blocking issues on the current WG
deliverable, i.e., schema mount.
...
> If you mean shifting the XPath context node to the mount point instance, then

funny, you answered yes to a choice!  I was asking if you think the
mount point shows up as a node in the data tree, i.e., as shown in the
example in
https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?

from my perspective and my co-authors in the RTG area using schema
mount, we've never heard of a (filesystem) mount point that doesn't show
in the (directory) structure and this is the mental analogue we've been
assuming. Since there never was an explicit example/discussion or text
to dissuade us of this, this disconnect was never noticed.  Certainly
this needs to be explicit in the document (either way). The following
change could be made to the schema mount draft (at a minimum):

OLD
          A mount point defines a place in the node hierarchy where
          other data models may be attached. A server that implements a
NEW
          A mount point defines a node in a data tree under which
instances of
          other data models may be attached. A server that implements a

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Aug 2017 09:37:43 +0200 (CEST)

Lou Berger <[email-masked]> wrote:
> to dissuade us of this

The current text says:

  A "container" or "list" node becomes a mount point if the
  "mount-point" extension (defined in the "ietf-yang-schema-mount"
  module) is used in its definition.

But of course we should clarify this.

>, this disconnect was never noticed.  Certainly

I strongly object to letting the extension define a new data node.
This would be a new type of data node that presumably look a lot like
a container, and you'd have to define all sorts of rules for this new
node (how it is encoded in XML, JSON, CBOR; how it is handled in
edit-config, how it is mapped to RESTCONF resources etc etc).

If you thought that the extension implicitly creates a node, adding an
explicit container won't do any harm; it will not change the schema
tree from what you thought it was.

But I think we should also restrict the mount-point extension so that
there cannot be more than one mount-point in a given container.

/martin

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Aug 2017 08:34:45 -0400

>   module) is used in its definition.

interesting, read that a few times to (now) get the gist of your intent.

> a container, 

agreed, just like a mount point looks a lot like a directory in a unix
file system.

> and you'd have to define all sorts of rules for this new

I'm don't see this, the rules would be the same as a container, as in
"mount points in data trees are encoded identically as containers".

> tree from what you thought it was.

Well we could make this work, but it feels like every model that uses
schema has added complexity to its definition and use to perhaps avoid
making some minor tooling changes.  Keep in mind that any use of the
mount point extension will required changes in tooling.

> there cannot be more than one mount-point in a given container.
In this case, I'd go further and say that the only thing in the
container (of the module schema) is the mount point and a mount point
extension is only valid within a container. (Then the semantics are the
same as we expected, just the syntax is different.)

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Aug 2017 14:44:09 +0200 (CEST)

> same as we expected, just the syntax is different.)

I was thinking about this as well, but I thought that maybe rejecting
any other data node is a CLR.  Maybe there is a good use case for
e.g. an action in a mount point.

/martin

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Aug 2017 08:54:10 -0400

For me usage standpoint it really would be much simpler in the model 
definition and use for the mount point to behave like a container. What are 
your technical objections to this change? Note that the encoding from a 
protocol standpoint would be the same as a container.

Thanks
Lou

---

From: Per Hedeland <[email-masked]>
Date: Tue, 29 Aug 2017 15:02:43 +0200

On 2017-08-29 14:34, Lou Berger wrote:
>>>> Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400:
>>>>> Lada,
>>>>>

It seems to me that the schema mount concept is 100% equivalent to the
Unix file system analogy in this particular respect. You need a
pre-existing directory to mount a remote file system (or for that matter
a disk device). The directory gains the property of being a mount point
by the process of mounting, and loses it by the process of unmounting:

# mount earth:/home /foo
mount: /foo: No such file or directory
# mkdir /foo
# mount earth:/home /foo
# ls /foo
(... lots of user directories ...)
# umount /foo
# ls /foo
#

--Per

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Aug 2017 09:40:51 -0400

> by the process of mounting, and loses it by the process of unmounting:

This point was at the root of the discussion of whether or not we even 
needed the mount Point extension at all and whether just having the scheme 
amount module identify mounts with in a container was sufficient.

I believe the perspective from Lada and Martin was that it didn't really 
add value. Those of us in the routing area working on models using scheme 
mount uniformly agreed that it was important to keep the extension to 
enable module designers to indicate to implementers where Mount points were 
intended to be used in the modules they were defining and for client users/ 
implementers to reliably identify where modules would be mounted. We also 
thought that the use of the mount Point extension in modules would have 
certain tooling benefits over just putting a comment in the description of 
a container that it was to be used as a mount point.

Yes, we can make the current node-less Mount Point extension work, but it 
certainly seems like a clumsier and more complex solution

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Aug 2017 16:07:52 +0200

> deliverable, i.e., schema mount.

Sure, and one serious issue is the complexity of the spec that makes it
difficult to understand. I have always insisted that the two mechanisms
- inline and use-schema - are fundamentally different concepts. The
former is basically data mount while the latter is an additional
mechanism for schema modularity comparable to augment.

Presenting them together is IMO confusing and wrong. For the use-schema
case, I would even suggest to avoid the term "mount".

> funny, you answered yes to a choice!  I was asking if you think the

Not at all, I wasn't sure what you meant by "our example". What I wanted
to say is that I am aligned with Martin on his exposition of open issue
#1 that started this thread.

The mount point directly under choice is of course broken, and because
of it I couldn't use the schema from the most recent NI draft
revision in my presentation in Prague. I just forgot to discuss this
issue with you.

> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?

I was pretty clear in my previous reply: "The mount-point extension
itself generates no extra node." The mount point does show up in the data
tree if it is instantiated, because it it defined by a "container" or
"list" statement. But the "mount-point" extension just tags this already
existing data node as a mount point.

> to dissuade us of this, this disconnect was never noticed.  Certainly

I agree it would be useful to extend some of the examples so as to
include a tree view of the resulting schema.

>           other data models may be attached. A server that implements

You nicely illustrate the confusion between data mount and schema
mount. Schema mount (or the "use-schema" approach at least) is a method
of schema construction analogical to an augment. This really means
nothing in terms of instance data - similarly, we don't expect instance
data modelled with an augment to be augmented somehow into the data
tree. The schema is constructed first and it describes constraints for a
data tree.

Note that this is different for the "inline" case because it relies on
instance data (YANG library) appearing somehow under the mount point.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Tue, 29 Aug 2017 16:27:00 +0200

On 2017-08-29 15:40, Lou Berger wrote:
> This point was at the root of the discussion of whether or not we even needed the mount Point extension at all and whether just having the scheme amount module identify mounts with in a container was
> sufficient.
> 
> I believe the perspective from Lada and Martin was that it didn't really add value. Those of us in the routing area working on models using scheme mount uniformly agreed that it was important to keep
> the extension to enable module designers to indicate to implementers where Mount points were intended to be used in the modules they were defining and for client users/ implementers to reliably
> identify where modules would be mounted. We also thought that the use of the mount Point extension in modules would have certain tooling benefits over just putting a comment in the description of a
> container that it was to be used as a mount point.
> 
> Yes, we can make the current node-less Mount Point extension work, but it certainly seems like a clumsier and more complex solution

Well, my comment *only* addressed your repeated claim that it was
different from file system semantics - I can't see that it is. The
mount-point extension does not define a data node. Mounting a file
system does not create a directory node. Whether this is a strong
argument for the non-data-node-defining semantics of mount-point is
perhaps a subjective matter.

--Per

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Aug 2017 09:40:28 +0200 (CEST)

> >> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:

[...]

> >> If you mean shifting the XPath context node to the mount point instance, then

So, going back to the original issue; does anyone have any objection
to changing the XPath context for parent-reference as describied in my
original post?

/martin

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Aug 2017 05:29:12 -0400

FYI I've asked folks in the routing area, i.e., the ietf users of schema 
mount, if they have an opinion on the node discussion. I will also do so on 
the point I raised on parent reference location. (Which is independent from 
your format change.) Clearly, if I'm the only one to be raising objections, 
I'll be the one in the rough on these points.

Thanks,

Lou
- as contributor

---

From: "Xufeng Liu" <[email-masked]>
Date: Wed, 30 Aug 2017 09:36:22 -0400

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Tuesday, August 29, 2017 8:35 AM
> To: Martin Bjorklund <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] schema mount open issue #1
> 
> >>>>> How can we expect poor data modellers to understand the concept if
> >>>>> we have such fundamental disconnects, after so many hours of
> >>>>> discussing it?
> >>>> This highlights why getting the text in (any) document is so
> >>>> important, and why discussions shouldn't be viewed as being closed
> >>>> until the impact on the text is agreed to!
> >>> I think many people still don't make much distinction between schema
> >>> mount (manipulation of the schema) and data mount. I still believe
> >>> we need to clearly separate these two concepts, preferably using two
> different mechanisms.
> >>
> >>> If you mean shifting the XPath context node to the mount point
> >>> instance, then yes.
> >>
> >> mount point shows up as a node in the data tree, i.e., as shown in
> >> the example in
> >> mount, we've never heard of a (filesystem) mount point that doesn't
> >> show in the (directory) structure and this is the mental analogue
> >> we've been assuming. Since there never was an explicit
> >> example/discussion or text to dissuade us of this
> >
> > The current text says:
> >
> >> , this disconnect was never noticed.  Certainly this needs to be
> >> explicit in the document (either way). The following change could be
> >> made to the schema mount draft (at a minimum):
> >>
> >> OLD
> >>           other data models may be attached. A server that implements
> >> a NEW
file system.
> 
> > and you'd have to define all sorts of rules for this new node (how it
> > is encoded in XML, JSON, CBOR; how it is handled in edit-config, how
> > it is mapped to RESTCONF resources etc etc).
> 
"mount
> points in data trees are encoded identically as containers".
> 
> >
schema has
> added complexity to its definition and use to perhaps avoid making some
minor
> tooling changes.  Keep in mind that any use of the mount point extension
will
> required changes in tooling.
> 
> >
> In this case, I'd go further and say that the only thing in the container
(of the
> module schema) is the mount point and a mount point extension is only
valid
> within a container. (Then the semantics are the same as we expected, just
the
> syntax is different.)
[Xufeng] To me, the statement "mount-point" is confusing, because it
indicates more like an object such as "leaf", "leaf-list", or "list", rather
than a property such as "presence" or "must". It would be better to make the
name sound more towards "making the container a mount point". The following
current description on the mount-point statement does not make this better:

       description
         "The argument 'name' is a YANG identifier, i.e., it is of the
          type 'yang:yang-identifier'.
          ...
          A mount point defines a place in the node hierarchy where
          other data models may be attached.
          ...";

Added to the confusion is the history of LNE and NI models, which initially
used "leaf root", then "anydata root", and then changed to "mount-point
root". Since the beginning, the "root" has always been shown in the tree
view, just like a "leaf" (not like the "presence"). In the Sec 4 of the
current draft-ietf-netmod-schema-mount-06, there still the following tree:

     +--rw interfaces
     |  +--rw interface* [name]
     |     ...
     +--rw network-instances
        +--rw network-instance* [name]
           +--rw name
           +--rw root
              +--rw routing
                 ...

   Here, the "root" node is the mount point for the NI schema.

In a container, it is confusing syntax to use the similar substatement
syntax for both property and contained objects, but this is beyond the
point.

Thanks,
- Xufeng

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Aug 2017 13:48:29 +0200

> amount module identify mounts with in a container was sufficient.

I don't like this analogy very much (and, for that matter, the term
"mount" itself) because Unix mount deals with data.

> add value. Those of us in the routing area working on models using scheme

In fact, I think Martin was never in favour of getting rid of the extension.

> implementers to reliably identify where modules would be mounted. We

Without the extra data specifying what is going to be added here, the
extension itself doesn't tell you much.

YANG already has an analogy: each container and list is basically an
implicit "augment point" where external modules can place stuff. Yet we
apparently don't need any explicit indication of the augment point in
the recipient module.

So I wonder why we need it for schema mount.

> certainly seems like a clumsier and more complex solution

I don't agree. The current "node-less" solution is more flexible in that
it allows you to have a container or list as the mount point.

It would be a completely different story though (and IMO the cleanest
solution) to implement the schema mount concept directly in YANG with a
specification of the mounted schema (i.e. as a design-time thing),
perhaps something like embedded grammars in RELAX NG:

http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-1.html#relax-CHP-10-SECT-1.3

This would however need a fairly massive redesign. We tried to avoid
changes to YANG but ended up with something that is, I am afraid, too
complex and non-intuitive.

Lada