Re: [netmod] Clarifications re RFC 8342 NMDA

[Jonathan <[e-mail]>]

------ Original Message ------
From: "Schönwälder, Jürgen" <[e-mail]>
To: "Jonathan" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   [phone]         <https://www.jacobs-university.de/>