It seems message quoting is all messed up here (both in mutt and thunderbird). I can't really follow anymore from this message who said what and who agrees with whom on what.
/js On Wed, Dec 23, 2015 at 10:24:08AM +0000, Gert Grammel wrote: > Rob, Kent, > > Adding to Rob’s comments: > > > > From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on > behalf of Robert Wilton > <robert.pub...@wilton.org.uk<mailto:robert.pub...@wilton.org.uk>> > Date: Wednesday 23 December 2015 09:28 > To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, > "netmod@ietf.org<mailto:netmod@ietf.org>" > <netmod@ietf.org<mailto:netmod@ietf.org>> > Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on > error) > > Hi Kent, > > Yes, I think that we are in agreement. > > I've one further comment inline below ... > > On 23/12/2015 02:41, Kent Watsen wrote: > [As a contributor] > > Hi Robert, I want to go back to Jason’s original questions. I think we’re > aligned on this, but please check my answers below. > > Quoting Jason’s original text now: > > > Is there some intention in the opstate requirements to add some sort > of all-or-nothing behavior to transition (C)? > Yes > +1 (if rollback-on-error has been requested) > > > > i.e. if some part of > an edit fails during the transition from intended->applied we should > "rollback" the other parts that may have already been applied ? > Yes > +1 (if rollback-on-error has been requested) > > > Would we then remove it all from intended as well ? > IMO, yes. This is more easily understood when thinking about Synchronous > Configuration Operations (defined in opstate-reqs), but I believe that it > equally applies to Asynchronous Configuration Operations, so long as the > client explicitly ops-in for the behavior. > IMO no. The intended config is imposed by the client to the server and other > than performing some syntax check, the server has no choice to accept it > as-is. If the server can’t apply the intended config, obviously the mismatch > between intended and applied config needs to be notified. As a result, it is > up to the client to decide what to do. Actions can vary according to the > situation naming a few: 1) retry intended config, 2) retry intended config > with continue-on-error, 3) re-apply the previous intended config, … > In other words: > > 1. the client shall not touch the applied config directly, > 2. the server shall not touch the intended config, > 3. it’s up to the server to align the intended with the applied config in > a way requested by the client (i.e. rollback-on-error, …) > 4. Once applied, the server notifies the client about success or failure > to do so > > > > I'm not sure how that would work for an async/hybrid (read "real”) > system. We've already done an "ack" back to the client before > transition (C) so the client may have already sent some additional > new config that depends on the previous edit. That would mean that > new config isn't valid. > I’m not a fan on the “hybrid” term, but in thinking about legacy or existing > NETCONF servers, I think that this is a non-issue as the server wouldn’t > advertise support for Rollback on Error in the first place. > I agree that "hybrid" probably isn't a good term. > +1 in fact it’s a "cheating synchronous” behaviour, probably not the best > term either. Let’s find a better term we can agree upon. > > It is probably worth noting that NETCONF already defines a > rollback-on-error optional capability, but that shouldn't be a problem > because I think that we only need to concern ourselves with servers that > express support for an explicit sync or async capability. > +1 > > Thanks, > Rob > > > > > Kent > > > > > > On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" > <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of > rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: > > Hi Jason, > > Picking up this slightly old thread. > > The "rollback on error" definition that I added I took directly from > RFC6241, so it's good that they look similar. The intention is that the > NETCONF "rollback-on-error" capability is a valid implementation of this > requirement :-) > > I think that the rollback-on-error capability defined in RFC6241 can > also be applied to the running datastore. Certainly, the example quoted > is in the context of the edit-config request on the running-config > datastore, and the RFC description of this feature doesn't appear to > limit it to the candidate datastore in any way. > > Thanks, > Rob > > > On 03/11/2015 07:23, Sterne, Jason (Jason) wrote: > Hi all, > > The term "rollback on error" (and other error options) has been used during > these discussions around the opstate requirements. > > That term already has some meaning in RFC6241 (or at least rollback-on-error > does and that is pretty close) and IMO it (today) has nothing to do with > "applied" config. It is an error option that has the scope of the contents > of a single edit-config request and how those contents get applied (all or > nothing) to the candidate DS (which is neither intended nor applied config) > or to the running DS (intended) if the <target> is <running/>. > > I think we need to clarify this "all or nothing" concept and how it is > related to "applied" config. We may also want to use slightly different > terminology so we don't get confused with today's meaning of > rollback-on-error. > > There are a few transitions to consider when editing a config and applying it > to a device (I'll give the example of using the candidate DS): > (A) config changes ---> candidate DS (<edit-config>) > (B) candidate DS ----> running (intended) (<commit>) > (C) intended ----> applied (internal processed in the device) > > Today rollback-on-error is only applicable to transition (A). > > Transition (B) does have all-or-nothing properties (as described in RFC6241) > but that isn't related to "rollback-on-error". > > Is there some intention in the opstate requirements to add some sort of > all-or-nothing behavior to transition (C) ? i.e. if some part of an edit > fails during the transition from intended->applied we should "rollback" the > other parts that may have already been applied ? > > Would we then remove it all from intended as well ? > > I'm not sure how that would work for an async/hybrid (read "real") system. > We've already done an "ack" back to the client before transition (C) so the > client may have already sent some additional new config that depends on the > previous edit. That would mean that new config isn't valid. > > Jason > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > . > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
