On Dec 1, 2014, at 12:59 PM, Andy Bierman <a...@yumaworks.com> wrote:
> On Mon, Dec 1, 2014 at 9:15 AM, Fedyk, Don <don.fe...@hp.com> wrote: >>> -----Original Message----- >>> From: Martin Bjorklund [mailto:m...@tail-f.com] >>> Sent: Sunday, November 30, 2014 4:26 AM >>> To: jh...@pfrc.org >>> Cc: j...@joelhalpern.com; i2rs@ietf.org; jcla...@cisco.com; 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. I agree that only one should be mandatory and not both. And I would put RESTCONF forward as sole candidate for i2rs (for reasons Andy described earlier in this thread). > > 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. and that would create a very complex scenarios, which I would prefer to avoid > It would be less work to define the interactions in RESTCONF > simply because there are relatively so few bells and whistles. and that is exactly the reason why RESTCONF is right to do the job > > >> Cheers, >> Don >> > > > Andy > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
