Re: [netmod] Comments on schema mount draft

Martin Bjorklund <mbj@tail-f.com> Mon, 26 March 2018 08:11 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 DEDAF1252BA for <netmod@ietfa.amsl.com>; Mon, 26 Mar 2018 01:11:31 -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 VaJS3pURRtZd for <netmod@ietfa.amsl.com>; Mon, 26 Mar 2018 01:11:30 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4041205F0 for <netmod@ietf.org>; Mon, 26 Mar 2018 01:11:30 -0700 (PDT)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id BEF821AE0187; Mon, 26 Mar 2018 10:11:29 +0200 (CEST)
Date: Mon, 26 Mar 2018 10:11:29 +0200
Message-Id: <20180326.101129.936165036878075905.mbj@tail-f.com>
To: rohitrranade@outlook.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <HK2PR0401MB12659DDADA1E5DAE6EE5AFA3DBAE0@HK2PR0401MB1265.apcprd04.prod.outlook.com>
References: <HK2PR0401MB12659DDADA1E5DAE6EE5AFA3DBAE0@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="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nlVzdU6EyXK_Tr8I0Bm6XeJ_-2s>
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: Mon, 26 Mar 2018 08:11:32 -0000

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