On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote:
> On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote: > > 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. > > So your implementation allows a client to write something to <running> > that transforms into something different at the time it is written (or > committed I assume)? Anyway, my statement was: > > If your server does not support templates or inactive configuration or > the like, then intended is just an alias for running. > > So it does not apply to your implementation. > > IMO the concept of NMDA conformance is still very under-specified. There should be a clear statement in RFC 2119 terms for the exact datastores that are considered standard datastores. This needs to be 100% backward compatible with RFC 7950 and RFC 6241 requirements for the 3 traditional datastores. I don't care if new datastore usage is unbounded, as long as the client developer knows what to expect from an NMDA-compliant server. The WG needs to deliberately (not haphazardly) determine the interoperability boundaries. /js > Andy > > -- > 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
