Re: [netmod] Clarifications re RFC 8342 NMDA

Jonathan <> Fri, 03 January 2020 11:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FC801200D7 for <>; Fri, 3 Jan 2020 03:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tpFBTYuKYcxX for <>; Fri, 3 Jan 2020 03:39:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1166F12001E for <>; Fri, 3 Jan 2020 03:39:40 -0800 (PST)
X-Sender-Id: dxszz3qpvg|x-authuser|
Received: from (localhost []) by (Postfix) with ESMTP id 2943B6A138C; Fri, 3 Jan 2020 11:39:40 +0000 (UTC)
Received: from (100-96-83-39.trex.outbound.svc.cluster.local []) (Authenticated sender: dxszz3qpvg) by (Postfix) with ESMTPA id DC9886A1FBF; Fri, 3 Jan 2020 11:39:38 +0000 (UTC)
X-Sender-Id: dxszz3qpvg|x-authuser|
Received: from ([TEMPUNAVAIL]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.5); Fri, 03 Jan 2020 11:39:40 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dxszz3qpvg|x-authuser|
X-MailChannels-Auth-Id: dxszz3qpvg
X-Snatch-Company: 34de0e9d37ad22e3_1578051579879_3257780994
X-MC-Loop-Signature: 1578051579879:968903129
X-MC-Ingress-Time: 1578051579879
Received: from ([]:62587 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1inLIh-0002Ul-Oz; Fri, 03 Jan 2020 11:39:31 +0000
From: Jonathan <>
To: =?utf-8?q?Sch=c3=b6nw=c3=a4lder=2c=20J=c3=bcrgen?= <>
Cc: "" <>
Date: Fri, 03 Jan 2020 11:39:31 +0000
Message-Id: <eme5cd3fe4-f085-44ef-8fd9-233423d9c0a5@vanguard>
In-Reply-To: <>
References: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard> <>
Reply-To: Jonathan <>
User-Agent: eM_Client/7.2.36908.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBAC69995C-EC25-4881-A6B6-0C22599248EA"
X-Antivirus: Avast (VPS 200102-0, 02/01/2020), Outbound message
X-Antivirus-Status: Clean
Archived-At: <>
Subject: Re: [netmod] Clarifications re RFC 8342 NMDA
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: Fri, 03 Jan 2020 11:39:43 -0000

------ Original Message ------
From: "Schönwälder, Jürgen" <>
To: "Jonathan" <>
Cc: "" <>
Sent: 02/01/2020 18:37:06
Subject: Re: [netmod] Clarifications re RFC 8342 NMDA

>On Thu, Jan 02, 2020 at 05:12:30PM +0000, Jonathan wrote:
>>  Hi,
>>  I have been reading through RFC 8342 and have a number of questions I
>>  couldn't resolve after a couple of passes through. Can anyone advise?
>>  The RFC states "The startup configuration datastore may not be supported by
>>  all protocols or implementations", "the candidate configuration datastore
>>  may not be supported by all protocols or implementations" and "<running>
>>  MUST be supported if the device can be configured via conventional
>>  configuration datastores". I can find no explicit guidance on:The intended
>>  configuration datastore: The RFC does state, "Whenever data is written to
>>  <running>, the server MUST also immediately update and validate <intended>."
>>  Is <intended> mandatory for NMDA-supporting servers that support
>>  <running>?
>It is not mandatory to expose <intended>. On simple implementations,
><intended> may be identical with <running>.
>>  The operational state datastore: The RFC does state it is "a
>>  read-only datastore that consists of all "config true" and "config false"
>>  nodes defined in the datastore's schema" and that "the datastore schema for
>>  <operational> MUST be a superset of the combined datastore schema used in
>>  all configuration datastores ...". Is <operational> mandatory for
>>  NMDA-supporting servers?
>Since <operational> is the only way to expose config false nodes for
>an NMDA server, it is kind of mandatory as soon as you have config
>false nodes to expose.
RFC 6241 describes <get> as retrieving "running configuration and device 
state information" and <get-config> as retrieving "all or part of a 
specified configuration datastore". RFC 8526 introduces <get-data> which 
it describes as "similar to NETCONF's <get-config> operation". As far as 
I can tell, neither RFC 8342 not RFC 8526 actually identify which 
operation to use to retrieve operational state data. Am I right in 
assuming it would be <get-config>? In that case, it is similar to <get> 
when performed on <operational> as it will also return state data.

And what should be the result of performing <get> on an NMDA-supporting 
server? Should it still return config true nodes from <running> plus 
config false nodes from <operational>? Or should the operation be 

>>  RFC 8525, section 1 states, "For backwards
>>  compatibility, an NMDA-supporting server SHOULD populate the deprecated
>>  "/modules-state" tree in a backwards-compatible manner."That suggests an
>>  NMDA-supporting server SHOULD be backwards-compatible with a
>>  non-NMDA-supporting client. Is that correct?
>This might be a misuse of 'SHOULD' since backwards-compatibility is
>important for a transition phase but not in pure NMDA environments.
>The idea here was to encourage support for a transition phase where
>NMDA and non-NMDA implementations may need to co-exist.
>>  Can an MMDA-supporting client be
>>  backwards-compatible with a non-NMDA-supporting server?
>An NMDA client should talk NMDA with an NMDA server. Whether an NMDA
>client also talks to non-NMDA servers is up to the implementor. I
>personally would distinguish between the protocol interaction and the
>data model of the management application. To me, it makes a lot of
>sense to make the data model of the management application NMDA aware
>even if the application is used with non-NMDA servers.
>>  I can't find any
>>  mention of YANG version 1 in RFC 8342. Is it safe to assume NMDA is
>>  compatible with YANG version 1 modules?
>It should not matter whether the model is written in YANG 1 or 1.1.
>However, core data models are moving towards YANG 1.1.
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <>