------ Original Message ------
From: "Schönwälder, Jürgen" <j.schoenwael...@jacobs-university.de>
To: "Jonathan" <jonat...@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/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
