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 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
