[As a contributor] Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that.
a) a previous intended config is in the process of being applied b) a previous configuration failed due to an error [KENT] or due to missing hardware, right? Regardless, I don’t think this thread has bearing of the requirements draft. Note that I removed the *-on-error terms from the Terminology section in -02 by instead rewording requirement 2-C, which was the only place they were being referenced before and the reference was merely suggestive (not normative). Can we leave it to the solution drafts to sort out?
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
