On Fri, Nov 28, 2014 at 02:39:21PM -0500, Jeffrey Haas wrote: > Joel, > > On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote: > > I don't recall seeing that form of commit in any protocol that has > > been proposed. I think it would be rather hard to do. > > One of the prior complicating details had been I2RS saying we'd use "netconf > and restconf" when we selected our protocol earlier this year. > > As we've since seen, netconf commit and datastore semantics (protocol > components) significantly complicate our needs. This has been a detail that > I believe is pushing netconf off the table and moving us more firmly into > restconf.
I like to understand this better. My understanding is that there are several implementations underway that use the same backend infrastructure for both NETCONF and RESTCONF. So I wonder how RESTCONF exposes datastore semantics that are simpler to deal with than NETCONF datastore semantics. I personally find the 'unified' datastore defined in RESTCONF somewhat handwaving. Each RESTCONF edit of a datastore resource is saved to non-volatile storage in an implementation-specific matter by the server. There is no guarantee that configuration changes are saved immediately, or that the saved configuration is always a mirror of the running configuration. This leaves it completely up to the implementation what is made persistent and when. While this may be great for implementors, I am not sure how this gives you predictable semantics needed to build implementations that work with different protocol implementations. Yes, I this is an issue I should raise on the NETCONF list. But for me, a protocol with unclear semantics is even harder to deal with than a protocol where it is actually clear in which situations which content is made persistent. /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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
