[netmod] Clarifications re RFC 8342 NMDA

Jonathan <jonathan@hansfords.net> Thu, 02 January 2020 17:12 UTC

Return-Path: <jonathan@hansfords.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CF431120806 for <netmod@ietfa.amsl.com>; Thu, 2 Jan 2020 09:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MS_3xpYHPasJ for <netmod@ietfa.amsl.com>; Thu, 2 Jan 2020 09:12:40 -0800 (PST)
Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net []) (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 D6D10120804 for <netmod@ietf.org>; Thu, 2 Jan 2020 09:12:39 -0800 (PST)
X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net
Received: from relay.mailchannels.net (localhost []) by relay.mailchannels.net (Postfix) with ESMTP id ED3B78C1D1C for <netmod@ietf.org>; Thu, 2 Jan 2020 17:12:38 +0000 (UTC)
Received: from mail.myfast.site (100-96-86-164.trex.outbound.svc.cluster.local []) (Authenticated sender: dxszz3qpvg) by relay.mailchannels.net (Postfix) with ESMTPA id C27E48C1761 for <netmod@ietf.org>; Thu, 2 Jan 2020 17:12:37 +0000 (UTC)
X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net
Received: from mail.myfast.site ([TEMPUNAVAIL]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.5); Thu, 02 Jan 2020 17:12:38 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dxszz3qpvg|x-authuser|jonathan@hansfords.net
X-MailChannels-Auth-Id: dxszz3qpvg
X-Stop-Harmony: 1aace054364eb7c1_1577985158643_2792404361
X-MC-Loop-Signature: 1577985158643:551386612
X-MC-Ingress-Time: 1577985158643
Received: from hansfords.plus.com ([]:56086 helo=[]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jonathan@hansfords.net>) id 1in41O-0004ug-Nk for netmod@ietf.org; Thu, 02 Jan 2020 17:12:30 +0000
From: Jonathan <jonathan@hansfords.net>
To: netmod@ietf.org
Date: Thu, 02 Jan 2020 17:12:30 +0000
Message-Id: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard>
Reply-To: Jonathan <jonathan@hansfords.net>
User-Agent: eM_Client/7.2.36908.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBE0AFCB30-76BB-4E27-86D0-BA1C23B9894F"
X-Antivirus: Avast (VPS 200102-0, 02/01/2020), Outbound message
X-Antivirus-Status: Clean
X-AuthUser: jonathan@hansfords.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WdTcHEHiRpTYrnGxLXiFodDCwUA>
Subject: [netmod] Clarifications re RFC 8342 NMDA
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, 02 Jan 2020 17:12:42 -0000


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>?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?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?Can an MMDA-supporting client be backwards-compatible with a 
non-NMDA-supporting server?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