Re: [netmod] Comments on schema mount draft

Martin Bjorklund <mbj@tail-f.com> Fri, 06 April 2018 13:33 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1C1270A3 for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 06:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLObmdioW78m for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 06:33:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1B12702E for <netmod@ietf.org>; Fri, 6 Apr 2018 06:33:01 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C67F21AE034E; Fri, 6 Apr 2018 15:33:00 +0200 (CEST)
Date: Fri, 06 Apr 2018 15:33:00 +0200 (CEST)
Message-Id: <20180406.153300.2264288445901236761.mbj@tail-f.com>
To: rohitrranade@outlook.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <HK2PR0401MB12652B45BACC5902890EADA4DBBA0@HK2PR0401MB1265.apcprd04.prod.outlook.com>
References: <KL1PR0401MB12720644E171A6A8AC738545DBA50@KL1PR0401MB1272.apcprd04.prod.outlook.com> <20180405.144349.1531327560930954458.mbj@tail-f.com> <HK2PR0401MB12652B45BACC5902890EADA4DBBA0@HK2PR0401MB1265.apcprd04.prod.outlook.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/elmDE_tR-MbpsEMhMlJmksMKUdA>
Subject: Re: [netmod] Comments on schema mount draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 13:33:07 -0000

Hi,

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

Yes, provided that the ietf-netconf module is mounted.


/martin



> 
> 
> 
> With Regards,
> 
> Rohit R
> 
> 
> 
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
> 
> 
> ________________________________
> From: Martin Bjorklund <mbj@tail-f.com>;
> Sent: Thursday, April 5, 2018 6:13:49 PM
> To: rohitrranade@outlook.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Comments on schema mount draft
> 
> Hi,
> 
> 
> Rohit Ranade <rohitrranade@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 <mbj@tail-f.com>;
> > Sent: Thursday, March 29, 2018 12:59:53 PM
> > To: rohitrranade@outlook.com
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Comments on schema mount draft
> >
> > Hi,
> >
> > Rohit Ranade <rohitrranade@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:mbj@tail-f.com>
> > > Sent: 26 मार्च 2018 13:41
> > > To: rohitrranade@outlook.com<mailto:rohitrranade@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 <rohitrranade@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
> > >