[netmod] NACM interaction for Schema Mount

Rohit R Ranade <rohitrranade@huawei.com> Wed, 16 January 2019 10:17 UTC

Return-Path: <rohitrranade@huawei.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 5C47E130DEC for <netmod@ietfa.amsl.com>; Wed, 16 Jan 2019 02:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 fEmgWfgZkrhP for <netmod@ietfa.amsl.com>; Wed, 16 Jan 2019 02:17:09 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E5E01130FBA for <netmod@ietf.org>; Wed, 16 Jan 2019 02:17:08 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CB97BB94A2EA2A96CDE9 for <netmod@ietf.org>; Wed, 16 Jan 2019 10:17:05 +0000 (GMT)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 16 Jan 2019 10:17:05 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 18:16:55 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: NACM interaction for Schema Mount
Thread-Index: AdStfcvILhOTH9zzQSO8JfdYi2weUA==
Date: Wed, 16 Jan 2019 10:16:55 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCC89D5@dggeml530-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCC89D5dggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RVIk58qRhUx56frS0zyqGp5nq1w>
Subject: [netmod] NACM interaction for Schema Mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 16 Jan 2019 10:17:16 -0000

Hi All,

Consider that we have a physical device, where a LNE (say "lne1" ) has been created. This LNE will be mounting some modules.

Note: For brevity sake, I have not included the prefix for each node in the xpaths mentioned below.
Consider the following scenario :

1.       NACM module exists in the same level as the LNE Module, and it has a rule to 'permit' create operation on /logical-network-elements/logical-network-element/root/interfaces path on group 'g1'.

2.       NACM module also exists 'mounted' under the LNE "lne1" instance, and it has a rule to 'deny' create operation on /interfaces path on group 'g1'.

The question arises, when an <edit-config> create operation is sent on the /logical-network-elements/logical-network-element/root/interfaces path, which rule is matched first ?  (consider that user belongs to group 'g1' )
My thought is as below:

1.       As per NACM rules, when the physical device rules are checked , we arrive at a result to permit/deny.

2.       So there is no chance to check the rules under the mount-point at all. Hence there is no point in mounting a NACM module at all.

Any other thoughts ?

With Regards,
Rohit