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

Qin Wu <bill.wu@huawei.com> Thu, 04 July 2019 12:58 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9511120655; Thu, 4 Jul 2019 05:58:21 -0700 (PDT)
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 XhTPHd_X0aSk; Thu, 4 Jul 2019 05:58:19 -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 39616120180; Thu, 4 Jul 2019 05:58:19 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 07426D55811135DB8F22; Thu, 4 Jul 2019 13:58:17 +0100 (IST)
Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Jul 2019 13:58:16 +0100
Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 4 Jul 2019 13:58:16 +0100
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 4 Jul 2019 13:58:16 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.66]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Thu, 4 Jul 2019 20:58:11 +0800
From: Qin Wu <bill.wu@huawei.com>
To: 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: AdUyY7FGeaBuaUx/SiGx95LI+su/qA==
Date: Thu, 4 Jul 2019 12:58:10 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA49C603F@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.31.203]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA49C603Fnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/83ZqCwfsjBbJ3dNcuGKzb9ta34o>
Subject: Re: [netconf] [netmod] RE: pls clarify get operation
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 12:58:22 -0000

suggestions or guidelines defined in NMDA architecture and NMDA guideline(/rfc8407#section-4.23.3) seem to only assume NMDA client only talks with NMDA server, non-NMDA client only talks with non-NMDA server.

True, but there’s no statement that a client or server cannot be both.  Note also that the NC/RC-NMDA RFCs explain how clients can discover if a server supports NMDA.  The intention is that the client would first try to use NMDA and, if not supported, fallback to non-NMDA.

[Qin]:You are right, but it not specified in RFC8407. revisiting the section 4.23.3.1 of RFC8407
“
   A server that needs to support both NMDA and non-NMDA clients can
   advertise both the new NMDA module and the temporary non-NMDA module.
   A non-NMDA client can use separate "foo" and "foo-state" subtrees,
   except the "foo-state" subtree is located in a different (temporary)
   module.  The NMDA module can be used by a non-NMDA client to access
   the conventional configuration datastores and the deprecated <get>
   operation to access nested "config false" data nodes.

”
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?
Can non-NMDA client consume NMDA module? If the answer is Yes, why the server need to advertise both NMDA and temporary non-NMDA module?
Why <get> operation is deprecated when non-NMDA client uses NMDA module?
How does the non-NMDA client deal with temporary non-NMDA module? Use <get> operation to get access to it?
How does the non-NMDA client distinguish NMDA module from temporary Non-NMDA module?

Kent // contributor