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

Kent Watsen <> Tue, 09 July 2019 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE8E512006B; Tue, 9 Jul 2019 11:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cUdz-GsXO--Y; Tue, 9 Jul 2019 11:30:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AC4812000F; Tue, 9 Jul 2019 11:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1562697051; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=aO7g9h/V32cXtg5d/8lXt7YUgDLfzS1axpV5iKBdeAE=; b=KgLVgeLAWX6LhS6HJyW3GxLy7QQMMQEQecLWVTj+cYLnEeefWqDG9AiJLSL2Bn4h 6uvJrNqgdXsxenXEK2YU41e8X9B+nNMLEIeV2vQ9PZKepTp1VXA8x/mN7Oq6ikMtzOu DZ/EHx7aqXutFVEIFqjVrWsl00VV6V9WkAd+7P68=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF4FB185-41B8-4110-AF78-CC0A27A78B85"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 9 Jul 2019 18:30:51 +0000
In-Reply-To: <>
Cc: "" <>, "" <>
To: Qin Wu <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.07.09-
Archived-At: <>
Subject: Re: [netconf] [netmod] RE: pls clarify get operation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2019 18:30:57 -0000

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

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

> If the answer is Yes, why the server need to advertise both NMDA and temporary non-NMDA module?

Not "yes", see above.

> Why <get> operation is deprecated when non-NMDA client uses NMDA module?

It's not deprecated (yet).

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

There is nothing in a module's definition that a client can key off to determine that at the moment.  A client could use deductive reasoning (e.g., if there's a foo-state tree, then most likely non-NMDA), but this is pretty limited.   Per RFC 8407, the RFC's Introduction section should indicate when a module is NMDA-optimized, so non-generic clients should know.

Kent // contributor