On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> 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. 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
