> -----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.
Cheers, Don _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
