Hi Martin,


For below point:

“

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

This would not be correct.  I think you are assuming one use case;
where schema mount is used in a (primitive) orchestrator that actually
talks to multiple devices (w/o transaction control).

Note that this document just defines how the *schema* is built; not
how instance data is stored or accessed.

”

As per example shown in section 4:

     +--rw network-instances

        +--rw network-instance* [name]

           +--rw name

           +--rw root

              +--rw routing



Considering “root” as mount point :



When querying data from schema mounted models:



<get-config>

  <filter>

    <network-instances>

      <network-instance>

       <name>1</name>

        <root>

          <routing/>



And



<action>

    <network-instances>

      <network-instance>

       <name>1</name>

        <root>

          <get-config>  -- having ietf-netconf ns

            <filter>

             <routing/>



Will these two give the same result ?



With Regards,

Rohit R



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



________________________________
From: Martin Bjorklund <m...@tail-f.com>
Sent: Thursday, April 5, 2018 6:13:49 PM
To: rohitrran...@outlook.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Comments on schema mount draft

Hi,


Rohit Ranade <rohitrran...@outlook.com> wrote:
> 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.

If the client invokes an action, it is expected that it knows how to
interpret the result.  This does not change with the introduction of
schema mount.  The client obviously knows the name and input
parameters of the action, so it seems resonable to expect that it
knows the output parameters as well, w/o any additional meta data.

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

The examples are given in the appendix, and there is a forward
reference to the appendix from section 5.


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

This module is written using YANG 1.1.  Unless this module is updated,
it doesn't matter what YANG 2.0 or whatever does.

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

This would not be correct.  I think you are assuming one use case;
where schema mount is used in a (primitive) orchestrator that actually
talks to multiple devices (w/o transaction control).

Note that this document just defines how the *schema* is built; not
how instance data is stored or accessed.



/martin

>
>
>
>
>
>
>
> With Regards,
>
> Rohit R
>
>
>
> ________________________________
> From: Martin Bjorklund <m...@tail-f.com>
> Sent: Thursday, March 29, 2018 12:59:53 PM
> To: rohitrran...@outlook.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Comments on schema mount draft
>
> Hi,
>
> Rohit Ranade <rohitrran...@outlook.com> 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:m...@tail-f.com>
> > Sent: 26 मार्च 2018 13:41
> > To: rohitrran...@outlook.com<mailto:rohitrran...@outlook.com>
> > Cc: netmod@ietf.org<mailto:netmod@ietf.org>
> > Subject: Re: [netmod] Comments on schema mount draft
> >
> > Hi,
> >
> > Thank you for these comments, replies inline.
> >
> > Rohit Ranade <rohitrran...@outlook.com> 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
> >
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to