Subject: Re: [netmod] compact versus iterative representation of the overall schema

From: Lou Berger <[email-masked]>
Date: Mon, 23 May 2016 08:30:51 -0400

Hi Lada,
    I looks like no one really jumped on this one -- so better late than
never ...

When looking at the question below, we should consider the uses cases. 
I'm particularity interested (as a contributor) in the use case of
nested mounts (NIs mounted within LNEs), as well as the case if  models
that will only permit mounting of specific other models vs generically
mounting any model.

On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
> Hi,
>
> with a schema mount mechanism in place, there are two different options
> for constructing the overall schema (their combinations are possible,
> too):
>
> 1. Define schema mount as an extension of YANG library so that it
> defines YANG modules, revisions, features and deviations as before but
> also the way how they are combined into a hierarchical structure of
> schemas.

I think this only makes sense if this is scoped in some way.  For
example, with LNEs, the parent/host server may not have visibility into
the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even if
does, you have to consider the cases of mounted models contained within
mounted models.

>
> 2. Apart from YANG Library data, the server just specifies the mount
> points. A client of an NM protocol is expected to fetch a new instance
> of YANG library and/or subordinate mount points as state data from a
> well-known location under each mount point.

I think this depends on the use case.  For LNEs, I think this is right. 
For some of the other possible use cases being discussed only a specific
model can be mounted.

> I think that #1 should be available (alone or along with #2) because
> there are cases when YANG is used as a data modelling language outside
> the context of a NM protocol – Eliot Lear's MUD presentation is one
> example.

I think we (the rtg yang arch dt) had envisioned  something closer to
2.  And as you say, an approach that also includes a properly scoped 1
is possible.

Lou

> Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 May 2016 15:43:37 +0200

> On 23 May 2016, at 14:30, Lou Berger <[email-masked]> wrote:
> 
> Hi Lada,

As I understand it, schema-mount is about accessing the LNE models from the parent/host management interface. I believe the real question is whether we want to allow the schema to dynamically change at run time and possibly throw in new modules that the client never heard of. #2 can do it while #1 can't. I am not sure though whether the LNE model really requires something like this.

> does, you have to consider the cases of mounted models contained within

This is possible either way, provided that the complete schema is known upfront.

> For some of the other possible use cases being discussed only a specific

I guess I need some example scenarios demonstrating that #1 cannot be used for LNE.

Lada 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 May 2016 09:58:49 -0400

Lada

See below

> As I understand it, schema-mount is about accessing the LNE models from the parent/host management interface. I believe the real question is whether we want to allow the schema to dynamically chang…

Again there are different use cases.  In the fixed-mount case (where a
module containing the mount specifies what model is being mounted) a
client will always know what to expect.  In the LNE and probably even NI
cases, a single client may talk to multiple servers, each of which may
have different mounted models.  I'm less sure about a single server with
different models mounted under different NIs, but this is certainly
possible in the LNE case.

> This is possible either way, provided that the complete schema is known upfront.

I think the complete schema is likely to be known by there server
upfront in all cases, but not the client.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 May 2016 16:21:33 +0200

> On 23 May 2016, at 15:58, Lou Berger <[email-masked]> wrote:
> 
> Lada
> 
> See below
> 

OK, so it seems to be related to the use cases for peer mount, which IMO has a lot of other issues to solve.

> upfront in all cases, but not the client.

Well, if the server knows everything upfront, it can also publish the schema in the compact form. A client may not support everything but at least it is able to tell whether it is the case or not.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 May 2016 12:24:51 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> As I understand it, schema-mount is about accessing the LNE models
> from the parent/host management interface. I believe the real question
> is whether we want to allow the schema to dynamically change at run
> time and possibly throw in new modules that the client never heard
> of. #2 can do it while #1 can't. I am not sure though whether the LNE
> model really requires something like this.
> 

I don't think I have seen a concrete proposal for such a compact
format that can handle the case where different instances of a list
with a mount point have different modules mounted, and some of them
have mounted models within the mounted models.

As a concrete example, suppose we have the model
example-network-manager from Appendix B in
draft-ietf-netmod-schema-mount-01:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw transport
         +--rw root      yangmnt:mount-point managed-device

Now, let's assume that two devices exist, A and B:

  A  implements:  ietf-interfaces, example-netowrk-manager
  B  implements:  ietf-system

In A, there is a managed-device C which implements ietf-interfaces and
ietf-ip.

What would this look like in the compact form?

BTW, in this case, it is not obvious that the top-level server knows
anything about the data models mounted by C...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 May 2016 14:43:46 +0200

> I don't think I have seen a concrete proposal for such a compact

YSDL was such a proposal.

> What would this look like in the compact form?

The module "example-network-manager" would be modified as follows:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw transport
         +--rw (root)
            +--:(A)
            +--:(B)
            +--:(C)

And then:

   {
     "ietf-ysdl:schemas": {
       "top-schema": "host",
       "schema": [
         {
           "name": "host",
           "yang-modules": [ "example-logical-devices" ],
           "subschema": [
             {
               "root":
                 "/example-network-manager:managed-devices/device/root/A",
               "schemas": [ "schema-A" ]
             }
             {
               "root":
                 "/example-network-manager:managed-devices/device/root/B",
               "schemas": [ "schema-B" ]
             }
           ]
         },
         {
           "name": "schema-A",
           "yang-modules": [
             "ietf-interfaces",
             "example-network-manager"
           ],
           "subschema": [
             {
               "root":
                 "/example-network-manager:managed-devices/device/root/C",
               "schemas": [ "schema-C" ]
             }
           ]
         },
         {
           "name": "schema-B",
           "yang-modules": [ "ietf-system" ]
         },
         {
           "name": "schema-C",
           "yang-modules": [
             "ietf-interfaces",
             "ietf-ip"
           ]
         }
       ]
     }
   }
         
As long as all modules comprising the schema and their possible
arrangement is known in advance, it should flexible enough. And as I
said, I'd prefer to address this case in schema-mount because the model
of trust between the server and client isn't changed in any way.

> anything about the data models mounted by C...

But then the top-level server cannot possibly serve data for C.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 May 2016 14:52:25 +0200 (CEST)

> The module "example-network-manager" would be modified as follows:

But A, B and C are device names (instances).

Also, C would be:

  /managed-devices/device[name="A"]/root/managed-devices/device[name="C"]

>                  "/example-network-manager:managed-devices/device/root/A",

Can the root contain instance information?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 May 2016 15:14:22 +0200

> On 24 May 2016, at 14:52, Martin Bjorklund <[email-masked]> wrote:
> 

So what? A, B and C can be the values of the "name" key, too.

>  /managed-devices/device[name="A"]/root/managed-devices/device[name="C"]

Yes.

> Can the root contain instance information?

No, it is a schema-node-path, that's why it can contain "choice" and "case" nodes. It should be possible to construct the complete schema without looking into any instances.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 May 2016 15:20:39 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> No, it is a schema-node-path, that's why it can contain "choice" and
> "case" nodes. It should be possible to construct the complete schema
> without looking into any instances.

So this approach doesn't work when the instances have different
mounted models?

It is not realistic to change the data model as you did above, since
we'd have to invent a separate container per combination of modules
that possibly could be mounted!

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 May 2016 15:57:45 +0200

> On 24 May 2016, at 15:20, Martin Bjorklund <[email-masked]> wrote:
> 

It works in the same way as for interfaces in ietf-interfaces, or routing-protocols in ietf-routing, where different entries arguably have different models. 

> that possibly could be mounted!

As a server implementor, I could augment the example-network-manager with as many case nodes as needed. Alternatively, we could introduce some kind of "dynamic choice" similar to "when". Then the "example-network-manager" could be:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw type?        type-enums
         +--rw transport

and the subschema specification would become, e.g.:

"subschema": [
  {
    "root": "/example-network-manager:managed-devices/device",
    "when": "type = 'device-type-A'",
    "schemas": [ "schema-A" ]
  },
  {
    "root": "/example-network-manager:managed-devices/device/",
    "when": "type = 'device-type-B'",
    "schemas": [ "schema-B" ]
  }
]

Lada