On Thu, Aug 3, 2017 at 9:53 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Thu, Aug 03, 2017 at 09:49:25AM -0700, Andy Bierman wrote: > > On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder < > > [email protected]> 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 < > > > > [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. > > > > > > 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. > > Seems you are changing topic. > > > 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. > > The protocols (with their various capabilities) expose different sets > of datastores. I agree, the protocol documents should state clearly > what is required to expose for the different protocols and what is > optional to expose. > > > 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. > > Yes, but it is not this WG but the other WG I think. > So you are saying there is no such thing as an NMDA-compliant server. There are protocols that may use specific datastores in various ways. Different protocols can have different behavior for the same datastore. Sounds very fun for client developers to figure out. > > /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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
