Andy Bierman <[email protected]> wrote: > 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.
Correct, but irrelevant to this question. > NETCONF uses sessions and edit operations can require multiple steps. > RESTCONF does not use sessions and operations are stateless. Yes; the session handling is the biggest difference IMO. Note that for edits, if the RESTCONF server doesn't implement yang-patch, edits in RESTCONF often require many more steps than in NETCONF. > IMO 1 should be mandatory for an I2RS agent to support, but not both. Agreed. > 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. Maybe, or maybe not. My point was that the original reasoning (i2rs needs to use restconf b/c of problems with the commit model in netconf) is not correct. This doesn't mean that there cannot be other reasons for using RESTCONF in i2rs. /martin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
