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 https://www.ietf.org/mailman/listinfo/netmod
