On Mon, Dec 1, 2014 at 9:15 AM, Fedyk, Don <[email protected]> wrote: >> -----Original Message----- >> From: Martin Bjorklund [mailto:[email protected]] >> Sent: Sunday, November 30, 2014 4:26 AM >> To: [email protected] >> Cc: [email protected]; [email protected]; [email protected]; Fedyk, Don >> Subject: Re: [i2rs] Point about writable running >> > <Snip> >> Just to be clear; the semantics you are talking about are not inherent to the >> *protocol*, they are tied to the *datastore*. This means that NETCONF and >> RESTCONF will show similar behavior (somewhat dependant on which >> capabilities NETCONF advertises; as has been pointed out the client has more >> control over the NETCONF datastores, leading to more predictable behavior). >> >> So the reasoning should not be: "NETCONF commit has unwanted semantics >> and/or performace, therefore we should use RESTCONF". Rather it should be >> "Writes to the configuration datastore has unwanted semantics and/or >> performace, therefore we need to carefully define the semantics for the new >> ephemeral datastore" - and once that is done it is trivial to define the >> necessary >> protocol extensions for both NETCONF and RESTCONF. >> >> Another way of stating this is that NETCONF commit semantics don't matter if >> I2RS defines a new ephemeral datastore. (Modulo interactions with the config >> datastore). >> >> >> /martin > [Don] I agree. We need to define semantics for the datastore and predictable > results for the writable running state or active configuration. It seems to > me if there is priorities and overlap with various datastores there should be > blocking or overriding of ephemeral data too. >
NETCONF has global and partial locks. It also has a <copy-config> operation to/from any datastore. Also a shared candidate datastore and confirmed-commit that do not work well unless clients use locking. NETCONF uses sessions and edit operations can require multiple steps. RESTCONF does not use sessions and operations are stateless. IMO 1 should be mandatory for an I2RS agent to support, but not both. The ephemeral datastore could have new rules, such as no locking and copy-config optional. NETCONF text could be written explaining how the new datastore interacts will all possible NETCONF operations. It would be less work to define the interactions in RESTCONF simply because there are relatively so few bells and whistles. > Cheers, > Don > Andy > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
