Re: [netmod] Comments on schema mount draft

Rohit Ranade <rohitrranade@outlook.com> Tue, 27 March 2018 15:06 UTC

Return-Path: <rohitrranade@outlook.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 94A8B12DA41 for <netmod@ietfa.amsl.com>; Tue, 27 Mar 2018 08:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 7Bs9UIj5uh4Y for <netmod@ietfa.amsl.com>; Tue, 27 Mar 2018 08:06:42 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254108.outbound.protection.outlook.com [40.92.254.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3D212D964 for <netmod@ietf.org>; Tue, 27 Mar 2018 08:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C9afTCKy7bi3boytFE9o3IAgWK+pNOusK/EDoRTcuf0=; b=q9JZMWEEl50unkI6acfNEmfvlPWlbZGdf+tfFAf7J2GFBI4NCjTs4ZGdP+uhNS1UwYhh6e7e5g5BiPgUzlU+4H96ABLf1lKPcjuiwPwWPWEmYwCPHQmPbMvPnyu+gCaqsU6wKzfdWtiMf7auGopD59wQutsCQpaoUg30N+vpY/uHllfTZapTg/hnFyJajrbQP6wreHMRGit8oxsmIJPhONNhgcGqHDDdMV66jpWOt8iecu23i9/kae9S5/X5fZkDvlU6vxPCPRHSr4TIy5K4ejKg6SRqCG4JhEf61nchKuBpUga2sEljpusJ3+fSvES5tnZ8oUZYUHXg3eBM6QGVoA==
Received: from PU1APC01FT064.eop-APC01.prod.protection.outlook.com (10.152.252.55) by PU1APC01HT240.eop-APC01.prod.protection.outlook.com (10.152.252.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.631.7; Tue, 27 Mar 2018 15:06:39 +0000
Received: from KL1PR0401MB1272.apcprd04.prod.outlook.com (10.152.252.51) by PU1APC01FT064.mail.protection.outlook.com (10.152.253.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.567.16 via Frontend Transport; Tue, 27 Mar 2018 15:06:38 +0000
Received: from KL1PR0401MB1272.apcprd04.prod.outlook.com ([fe80::d9b7:e319:1828:812d]) by KL1PR0401MB1272.apcprd04.prod.outlook.com ([fe80::d9b7:e319:1828:812d%13]) with mapi id 15.20.0609.012; Tue, 27 Mar 2018 15:06:38 +0000
From: Rohit Ranade <rohitrranade@outlook.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Comments on schema mount draft
Thread-Index: AQHTxDbT1I3AIjMZP0GUUq533JigqqPiK6iAgAIEP90=
Date: Tue, 27 Mar 2018 15:06:38 +0000
Message-ID: <KL1PR0401MB1272858515A76DF861B73D21DBAC0@KL1PR0401MB1272.apcprd04.prod.outlook.com>
References: <HK2PR0401MB12659DDADA1E5DAE6EE5AFA3DBAE0@HK2PR0401MB1265.apcprd04.prod.outlook.com>, <20180326.101129.936165036878075905.mbj@tail-f.com>
In-Reply-To: <20180326.101129.936165036878075905.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:5EC1D123AD80C502CCE515F17FA9336544A3460E56931D1FA959D4BEA6C9B35D; UpperCasedChecksum:812E8C68D51D7140E98C0A293E11D0FFA9A09B4D72543796FE9EAA09F40D6844; SizeAsReceived:7105; Count:46
x-tmn: [6EabwOp3h0L0ixnm7MNo5J0A5S1oaJu6N6U7mscV9t0=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT240; 7:eaHjAKwPtb4zgVnRazGME6n1RpwQEaTxGkTLGjKQmvI7QLCq+J7+5RNiFQSFQ5E6WHG6cLrvVkPUHi1RfOcOqclgbrLTC9Bb/kQMbEFrwer8oNfj+rOjLoJP0VeWirWcXmj6F2pv3FopChe0jWcC/W69lySOPsmu0606NPH1aXE+1Fr+6ZVZ4FxG0lKG9exQzzwyH7coLk8CrNq0VBw1/x4JIhXKWztqynwKRRB5DxlCX/9dDwL24P1zP/8vQKgj
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:PU1APC01HT240;
x-ms-traffictypediagnostic: PU1APC01HT240:
x-ms-office365-filtering-correlation-id: 71a1a996-22b7-46d8-74c6-08d593f456d7
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT240; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT240;
x-forefront-prvs: 0624A2429E
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT240; H:KL1PR0401MB1272.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:;
x-microsoft-antispam-message-info: P1vJMEqVD65Pm7dJqDiR3pWRBuLQTSIccMj1mOuQLEz2EPeV6T7u6WbJ5NEqEsSB8Aoz3IQZd4UDP+a3vS/Gy09/0lQq4bUgbWtrfJzqcPO5O+S4GpMMZrmhcD2lVj6wzcZqj8O43mjDKv1Grb6z9aN9G16SsnFGeEkXxhGtYe16uAqscz0FHYC4+fQHjBr8
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_KL1PR0401MB1272858515A76DF861B73D21DBAC0KL1PR0401MB1272_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 71a1a996-22b7-46d8-74c6-08d593f456d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 15:06:38.0275 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT240
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/s79VPMi683xtlx8pbLxD98v2yHc>
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: Tue, 27 Mar 2018 15:06:49 -0000

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




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