On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <[email protected] <mailto:[email protected]> > wrote:
On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > Just to get confirmation on my assumptions: > > In section 4.7.3 the origin metadata does not include 'running' as origin > but only 'intended'. So it seems to be mandatory for a NC server to support > the intended datastore? If your server does not support templates or inactive configuration or the like, then intended is just an alias for running. IMO this is not correct. There are no standards at all to define these things. Our server supports an implementation of config templates that expands the template when it is first created. A different proprietary implementation MAY choose to expand templates in some other way. Since there are no standards for this purpose, any proprietary implementation decision is valid. The contents of the "intended" datastore are purely proprietary. The opaque nature of this datastore is by design and the WG accepts that servers are free to choose to implement whatever datastores they want. The origin metadata should just reflect what the server does, not mandate any sort of datastore conformance. [Bart Bogaert] In that case I would expect that the running is also included as an origin of the data in the operational datastore? Regards, Bart Andy I do not think you need to expose intended in this case. Still, the value of the origin attribute is 'intended' since in the general case, the configuration is coming from <intended>. > With the introduction of the operational datastore I assume it also means > that when someone wants to know what the client has configured on the device > a get-config on the running datastore is required while to know the 'in-use' > configuration a get(-config) on the operational datastore is required? Yes. The operation, however, is likely called get-data in NETCONF, at least this is what draft-dsdt-nmda-netconf-00 suggested. > The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines > mentions that a derived module can be generated from the YANG models where > state and config are merged in a single branch. In the simple example this > results in another YANG model with its own namespace. I assume that this > state YANG model will then also show up in the hello message? The general idea is that we produce YANG modules that have config and state merged into a single branch. Out of this YANG module, people may generate a separate module that consists of the config false nodes plus any additional key nodes needed to make it work. Such a YANG module will be treated as any other YANG module. Note that YANG 1.1 started to move module announcements to the ietf-yang-library to avoid very long module announcements during session startup. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
