Re: [netmod] [netconf] RE: pls clarify get operation

Rohit R Ranade <rohitrranade@huawei.com> Thu, 18 July 2019 04:34 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 60F58120088; Wed, 17 Jul 2019 21:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 iv40XZOj48bA; Wed, 17 Jul 2019 21:34:30 -0700 (PDT)
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 8805D120025; Wed, 17 Jul 2019 21:34:30 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DCDF28FF8D2B282A9ED9; Thu, 18 Jul 2019 05:34:27 +0100 (IST)
Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 18 Jul 2019 05:34:27 +0100
Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 18 Jul 2019 05:34:27 +0100
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 18 Jul 2019 05:34:26 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.102]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Thu, 18 Jul 2019 12:34:16 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: Qin Wu <bill.wu@huawei.com>, Kent Watsen <kent@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netconf] [netmod] RE: pls clarify get operation
Thread-Index: AdU9ETq4sTpTMz3bTxurvnfGNPR27gAEGcDw
Date: Thu, 18 Jul 2019 04:34:15 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BD9F7A1@dggeml510-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAA4A03B74@nkgeml513-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA4A03B74@nkgeml513-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_991B70D8B4112A4699D5C00DDBBF878A6BD9F7A1dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BMOuxrSUnoHYI74WzU7k68Bhdq8>
Subject: Re: [netmod] [netconf] RE: pls clarify get operation
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: Thu, 18 Jul 2019 04:34:34 -0000

If IETF modules do not define a ‘-state’ subtree, for example the “ietf-module-tags”, each vendor who wants to support Non-NMDA clients may have to augment such modules with a “-state” subtree of their own.


From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Qin Wu
Sent: 18 July 2019 08:13
To: Kent Watsen <kent@watsen.net>
Cc: netconf@ietf.org; netmod@ietf.org
Subject: Re: [netconf] [netmod] RE: pls clarify get operation

发件人: Kent Watsen [mailto:kent@watsen.net]
发送时间: 2019年7月10日 2:31
收件人: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
抄送: netconf@ietf.org<mailto:netconf@ietf.org>; netmod@ietf.org<mailto:netmod@ietf.org>
主题: Re: [netconf] [netmod] RE: pls clarify get operation

[Just back from a 4th of July thing]

Hi Qin,
It provides guideline how to create temporary non-NMDA module from NMDA module, but temporary non-NMDA module is not standard module. So everybody will create the same temporary non-NMDA module?
I also feel this second paragraph is not very clear, especially the last sentence,  is nested config false data nodes part of NMDA module or temporary non-NMDA
Module? Looks like  nested config false data node part of NMDA module?
True, but as I wrote Frank on the 28th:

"Some drafts already publish a "state" module in their Appendix and, when they do, there is a completely standard non-NMDA IETF solution.  I don't know if this strategy is being followed universally but, if not, then I don't believe the IETF would object at all to the publication of drafts for missing state models in drafts that only assumed NMDA."

Are you facing this situation currently?   If so, with which modules?  Have you considered submitting an I-D to define the missing state tree module?

[Qin]: Yes, we are looking for completely standard non-NMDA IETF solution in this NMDA transition time period, since we assume many NETCONF clients in the existing deployment don’t support NMDA. We are not sure state module in the appendix is standard non-NMDA model or not? How many operators and implementer will use them as standard model.
Yeah, for some of other model may not define such state module in the appendix.
Can non-NMDA client consume NMDA module?

Sort of.  The config-true nodes will appear in the <running> as usual, and the config-false nodes can be accessed via the standard operations.  But there will be issues as, for instance, the config-false nodes will only appear for configured items and the operational value for config-true nodes will be missing, the latter of which may be important as an NMDA-optimized data model is unlikely to define config-false nodes for any config-true nodes, and hence the config-false that are defined may be far and few between, leading to an unacceptably incomplete upstate view.

[Qin]:That is exactly the issue we are facing. How do we as Non-NMDA client use NDMA module to get system generated configuration. I assume config false nodes for config-true nodes are referred to system generated configuration. These system generated configuration can not be obtained through get operation.