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

Qin Wu <> Thu, 04 July 2019 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9511120655; Thu, 4 Jul 2019 05:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XhTPHd_X0aSk; Thu, 4 Jul 2019 05:58:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39616120180; Thu, 4 Jul 2019 05:58:19 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 07426D55811135DB8F22; Thu, 4 Jul 2019 13:58:17 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Jul 2019 13:58:16 +0100
Received: from ( by ( 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 ( by ( 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 ([]) by ([]) with mapi id 14.03.0415.000; Thu, 4 Jul 2019 20:58:11 +0800
From: Qin Wu <>
To: Kent Watsen <>
CC: "" <>, "" <>
Thread-Topic: [netconf] [netmod] RE: pls clarify get operation
Thread-Index: AdUyY7FGeaBuaUx/SiGx95LI+su/qA==
Date: Thu, 04 Jul 2019 12:58:10 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA49C603Fnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] [netconf] RE: pls clarify get operation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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