On Wed, Oct 01, 2014 at 08:40:35AM -0700, Thomas D. Nadeau wrote: > Im going from a netconf/yang model perspective with the assumption that > %100 of a configuration is modeled in yang and operationally available via > netconf (or restconf). If you then think of this configuration as a > configuration set of objects, I like to think about i2rs as a proper > subset of this. Operational reality also shows this to be the case. There > seems to be no good reason to have something you can configure/read from > this set of objects that differs if you use the i2rs "protocol" versus > netconf/restconf.
I've intentionally not been prodding at a second half of the "option 4" conversation: What is the impact on netconf protocol operations. Per the interim, a significant portion of the semantics we want simply are addressed by having an ephemeral data store using existing "source" or "target" semantics in netconf. GET operations have some ambiguity and may require extension to allow one to get a given view - merged or not. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
