Re: [netmod] Clarifications re RFC 8342 NMDA

Jonathan <jonathan@hansfords.net> Fri, 03 January 2020 11:39 UTC

Return-Path: <jonathan@hansfords.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC801200D7 for <netmod@ietfa.amsl.com>; Fri, 3 Jan 2020 03:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpFBTYuKYcxX for <netmod@ietfa.amsl.com>; Fri, 3 Jan 2020 03:39:41 -0800 (PST)
Received: from brown.birch.relay.mailchannels.net (brown.birch.relay.mailchannels.net [23.83.209.23]) (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 1166F12001E for <netmod@ietf.org>; Fri, 3 Jan 2020 03:39:40 -0800 (PST)
X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2943B6A138C; Fri, 3 Jan 2020 11:39:40 +0000 (UTC)
Received: from mail.myfast.site (100-96-83-39.trex.outbound.svc.cluster.local [100.96.83.39]) (Authenticated sender: dxszz3qpvg) by relay.mailchannels.net (Postfix) with ESMTPA id DC9886A1FBF; Fri, 3 Jan 2020 11:39:38 +0000 (UTC)
X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net
Received: from mail.myfast.site ([TEMPUNAVAIL]. [81.19.215.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Fri, 03 Jan 2020 11:39:40 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dxszz3qpvg|x-authuser|jonathan@hansfords.net
X-MailChannels-Auth-Id: dxszz3qpvg
X-Snatch-Company: 34de0e9d37ad22e3_1578051579879_3257780994
X-MC-Loop-Signature: 1578051579879:968903129
X-MC-Ingress-Time: 1578051579879
Received: from hansfords.plus.com ([84.92.116.209]:62587 helo=[192.168.54.20]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jonathan@hansfords.net>) id 1inLIh-0002Ul-Oz; Fri, 03 Jan 2020 11:39:31 +0000
From: Jonathan <jonathan@hansfords.net>
To: =?utf-8?q?Sch=c3=b6nw=c3=a4lder=2c=20J=c3=bcrgen?= <J.Schoenwaelder@jacobs-university.de>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Date: Fri, 03 Jan 2020 11:39:31 +0000
Message-Id: <eme5cd3fe4-f085-44ef-8fd9-233423d9c0a5@vanguard>
In-Reply-To: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de>
References: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard> <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de>
Reply-To: Jonathan <jonathan@hansfords.net>
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
X-AuthUser: jonathan@hansfords.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VlfFcpcQ2oNI38FPc9lbQDgQPtw>
Subject: Re: [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: Fri, 03 Jan 2020 11:39:43 -0000

------ Original Message ------
From: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
To: "Jonathan" <jonathan@hansfords.net>
Cc: "netmod@ietf.org" <netmod@ietf.org>
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 
rejected?

>
>
>>  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.
>
>/js
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>