Re: [netmod] Comments on schema mount draft

Martin Bjorklund <mbj@tail-f.com> Thu, 29 March 2018 07:29 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 94BEC12D870 for <netmod@ietfa.amsl.com>; Thu, 29 Mar 2018 00:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 9KnBa__eBMsy for <netmod@ietfa.amsl.com>; Thu, 29 Mar 2018 00:29:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 278A412D86E for <netmod@ietf.org>; Thu, 29 Mar 2018 00:29:54 -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 6BEF21AE0187; Thu, 29 Mar 2018 09:29:53 +0200 (CEST)
Date: Thu, 29 Mar 2018 09:29:53 +0200
Message-Id: <20180329.092953.1063547768163198657.mbj@tail-f.com>
To: rohitrranade@outlook.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <KL1PR0401MB1272858515A76DF861B73D21DBAC0@KL1PR0401MB1272.apcprd04.prod.outlook.com>
References: <HK2PR0401MB12659DDADA1E5DAE6EE5AFA3DBAE0@HK2PR0401MB1265.apcprd04.prod.outlook.com> <20180326.101129.936165036878075905.mbj@tail-f.com> <KL1PR0401MB1272858515A76DF861B73D21DBAC0@KL1PR0401MB1272.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/mXioat6WzlNhIDS1XwnExQFKbYs>
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: Thu, 29 Mar 2018 07:29:56 -0000

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
>