Subject: [netmod] Comments on schema mount draft

From: Rohit Ranade <[email-masked]>
Date: Sun, 25 Mar 2018 12:46:25 +0000

Hi All,

Please find some comments for the schema mount draft. If I find any other will send in another mail.

Editorial:
============
1. Section 3.1
   "The "mount-point" statement MUST NOT be used in a YANG version 1
   module."
   ==> It is unclear why such a restriction is placed.

2. Section 3.2
   "state data in the "yangmnt:schema-mounts""
   ==> Here the yang tree diagram is not yet introduced. I feel better to introduce
   this diagram as it makes it easier to understand the data-nodes

3. Section 3.2
   "Data in this container is intended to be as stable as data in the
   top-level YANG library"
   ==> What is the meaning of "as stable" as ? As a developer , I am unclear what needs
   to be done here. Please clarify.

4. Section 3.2
   "i.e., instances of that mount point MUST NOT contain any data above
   those that are defined in the parent schema."
   ==> Here "any data above", means "above" in the hieararchy ? Not clear, this is similar
   to having a USB slot, but no device mounted on it as yet in UNIX terms. Right ?
   The query output on parent-schema should give empty data.

5. Section 3.2
   "If multiple mount points with the same name are defined in the same
   module - either directly or because the mount point is defined in a
   grouping and the grouping is used multiple times - then the
   corresponding "mount-point" entry applies equally to all such mount
   points."
  ==> As per tree diagram, "mount-point" has two keys. So each module can have multiple
  mount points. So how to apply it "equally" ? Not clear.

6. Section 3.2
   Instead of "inline" and "shared-schema", I suggest to use "variable-schema" and
   "same-schema"
   Reason: The key difference between the two is that in one case, the schema MAY be different
   while in the other the schema is same. The name can be similar to the reason.

Logical Point:
1. Consider the topology where 1 main device is present with N logical devices behind it.
   When the mounting is done, it is quite possible that some of N devices are having different
   versions of modules.
   This can lead to each instance of mount point, having different schema.
   How can the client understand the schema of each mount-point instance ? Preferably get-schema of these devices and then know the model ?

With Regards,

Rohit R

---

From: Rohit Ranade <[email-masked]>
Date: Sun, 25 Mar 2018 12:58:02 +0000

One more point.

How to configure access control rules for the mounted models ?
   I think in the "Security Considerations" section, we should highlight the need for
   configuring NACM rules before mounting the nodes. Else all information can be queried.
   1 example for rule configuration for notification and data-node will be helpful.

With Regards,

Rohit R

________________________________
From: netmod <[email-masked]> on behalf of Rohit Ranade <[email-masked]>
Sent: Sunday, March 25, 2018 12:46:25 PM
To: [email-masked]
Subject: [netmod] Comments on schema mount draft

Hi All,

Editorial:
============
1. Section 3.1
   "The "mount-point" statement MUST NOT be used in a YANG version 1
   module."
   ==> It is unclear why such a restriction is placed..

2. Section 3.2

3. Section 3.2

4. Section 3.2

5. Section 3.2

6. Section 3.2

Logical Point:

With Regards,

Rohit R

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 26 Mar 2018 10:11:29 +0200 (CEST)

Hi,

Thank you for these comments, replies inline.

> other will send in another mail.

The reason is that YANG 1 doesn't support inline actions and
notification, which means that top-level rpcs and notifs in the
mounted module cannot be invoked using the mechanism described in
section 5.  I will try to clarify this.

>    this diagram as it makes it easier to understand the data-nodes

Ok.  I moved section 8 to a new section 3.2.

>    to be done here. Please clarify.

Kent also had a comment around this, and the text about stable is now
removed.

>    ==> Here "any data above", means "above" in the hieararchy ?

No, this was just wrong; it should be "except".

>    Not
>    clear, this is similar

Note that the sentence starts with "If multiple mount points with the
same name are defined in the same module" -- so this clearly doesn't
apply to mount points with different names, right?

For example, you can have:

  container foo {
    yangmnt:mount-point my-mnt-point;
  }
  container bar {
    yangmnt:mount-point my-mnt-point;
  }

There is just one entry in the "mount-point" list, so that entry
applies to both these mount points.  Both are either "inline" or
"shared-schema".

>    while in the other the schema is same. The name can be similar to the

At this point, we have to live with these terms.  This was part of the
compromise leading to this solution; there are other documents in the
RFC editor's queue that depend on these terms.

>    How can the client understand the schema of each mount-point instance
>    ? Preferably get-schema of these devices and then know the model ?

This draft says that each instance will have its own YANG library
instance.  So there the client can detect which versions of the
different modules each instance supports.  Then <get-schema> can be
invoked to get the modules, if it is supported.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Mar 2018 16:30:44 +0200

> How to configure access control rules for the mounted models ?

If you mean NACM from the viewpoint of the the parent tree, then I think
the consensus was that it has to be specified in the parent tree,
including rules for mounted data. This should probably be mentioned in the
text.

NACM data can also be present in the mounted tree, but it should be used
only for the "internal" session in the case of split management, and
ignored in the outer session.

Lada

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

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

---

From: Rohit Ranade <[email-masked]>
Date: Tue, 27 Mar 2018 14:56:51 +0000

Hi,

Since the session management with Mounted devices, is not known to the client, how will the client know how to configure NACM rules for the inner devices ? Please provide an example use-case.
From the client perspective, all rules for a particular mounted device, will the have the  xpath of the corresponding mount-point as prefix.

With Regards,
Rohit R

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Ladislav Lhotka<mailto:[email-masked]>
Sent: 26 मार्च 2018 20:00
To: Rohit Ranade<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Comments on schema mount draft

Lada

---

From: Rohit Ranade <[email-masked]>
Date: Tue, 27 Mar 2018 15:06:38 +0000

Hi Martin,

W.r.t <get-schema> on the main device, it will mean that for successful <get-schema> for all the schema of mounted devices, the main device must be upgraded to higher version first and must contain ALL the schema of all the devices behind the main device.
This point may prove to be tricky as the whole topology upgrade has to be considered always. I feel we can add some text regarding this.

Also how to “mount” an instance of a mount-point ? Because once this draft is out, each implementer may define private RPCs for mount and un-mount if this module does not define it. Whether any plan about it ?

With Regards,
Rohit R

From: Martin Bjorklund<mailto:[email-masked]>
Sent: 26 मार्च 2018 13:41
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Comments on schema mount draft

Hi,

  container foo {

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2018 09:20:36 +0200 (CEST)

Hi,

Rohit Ranade <[email-masked]> wrote:
> Hi,
> 
> Since the session management with Mounted devices, is not known to the
> client, how will the client know how to configure NACM rules for the
> inner devices ? Please provide an example use-case.
> From the client perspective, all rules for a particular mounted
> device, will the have the xpath of the corresponding mount-point as
> prefix.

Note that schema mount does not have any concept of "mounted devices"
or anything.  Schema mount is not involved in how data is instantiated
or how/where it is stored or produced.

I agree that we need to state that NACM rules cover mounted data
though.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2018 09:29:53 +0200 (CEST)

Hi,

Rohit Ranade <[email-masked]> wrote:
> Hi Martin,
> 
> W.r.t <get-schema> on the main device, it will mean that for
> successful <get-schema> for all the schema of mounted devices, the
> main device must be upgraded to higher version first and must contain
> ALL the schema of all the devices behind the main device.

This is not the intention, and as you note, in many cases this is just
not possible.

The client can look at the "location" leaf in the mounted YANG library
(in YLbis; in old YL it was called "schema") and get the module from
there.

If the mounted schema also mounts "ietf-netconf-monitoring", the
client can invoke the mounted <get-schema> as an action, and retrieve
the specific version of the module that is mounted there.

> This point may prove to be tricky as the whole topology upgrade has to
> be considered always. I feel we can add some text regarding this.
> 
> Also how to “mount” an instance of a mount-point ? Because once this
> draft is out, each implementer may define private RPCs for mount and
> un-mount if this module does not define it. Whether any plan about it
> ?

Note that schema mount is not about mounting devices; that would be a
future specialization of this mechanism.

In the LNE and NI drafts, entities are "mounted" by creating entries
in the corresponding lists.  There is no need for a "mount" rpc in
these cases.

/martin