Re: [netmod] Comments on schema mount draft

[Rohit Ranade <[e-mail]>]

Hi Martin,



Thank you for your responses.

I have gone through the LNE draft and YANG 1.1 and found some more suggestions.



1. Section 5

   "If a mounted YANG module defines an RPC operation, clients can invoke

   this operation as if it were defined as an action for the

   corresponding mount point"

   ==> Below is the example from Yang 1.1 Section 7.15



    <rpc message-id="101"

          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

       <action xmlns="urn:ietf:params:xml:ns:yang:1">

         <server xmlns="urn:example:server-farm">

           <name>apache-1</name>

           <reset>

             <reset-at>2014-07-29T13:42:00Z</reset-at>

           </reset>

         </server>

       </action>

     </rpc>



     <rpc-reply message-id="101"

                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

       <reset-finished-at xmlns="urn:example:server-farm">

         2014-07-29T13:42:12Z

       </reset-finished-at>

     </rpc-reply>

              ==> Here rpc-reply only has the namespace and action name defined in the mount-instance's module.

              The client needs to store information of the mount-instance for which the RPC request was sent and only then it can validate the rpc-reply against the data-model.

              To avoid this work of client, whether we can think of adding meta-data to rpc-reply to provide this information to client.



2. Section 5

   I would prefer the approach taken by Yang 1.1 where statements followed by XML examples   to help in clarity.

   Especially for the RPC and notification section, it is better to add clear examples

   in a "Usage Example" sub-section for this section.



3. Yang RPC and ACTION statements:

  If we need to view the RPC defined in a module as an ACTION after schema mount, then

  Whenever there is update to RPC in say YANG 1.2, then the corresponding changes must be present in ACTION also, introducing a coupling between RPC and ACTION statements.



4. NETCONF has some "rpc" which work on multiple mount-instances.

   ==> For example <edit-config> , <get-config> or <lock>. Whether we need to give a

   guideline for how to handle such "rpc", so that other protocols which implement schema mount   also adapt accordingly ?

   Eg: Something like, for transaction management, better to operate on one mount-instance.







With Regards,

Rohit R



________________________________
From: Martin Bjorklund <[e-mail]>
Sent: Thursday, March 29, 2018 12:59:53 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [netmod] Comments on schema mount draft

Hi,

Rohit Ranade <[e-mail]> 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




>
>
>
>
> With Regards,
> Rohit R
>
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> From: Martin Bjorklund<mailto:[e-mail]>
> Sent: 26 मार्च 2018 13:41
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [netmod] Comments on schema mount draft
>
> Hi,
>
> Thank you for these comments, replies inline.
>
> Rohit Ranade <[e-mail]> wrote:
> > 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.
>
> 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.
>
> > 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
>
> Ok.  I moved section 8 to a new section 3.2.
>
> > 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.
>
> Kent also had a comment around this, and the text about stable is now
> removed.
>
> > 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 ?
>
> No, this was just wrong; it should be "except".
>
> >    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.
>
> 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".
>
>
> > 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.
>
> 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.
>
> > 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 ?
>
> 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
>