> Not quite. > > E.g. I think that for compatibility a system could still advertise > support for "applied" configuration even through its configuration > processing is "synchronous" and hence applied config would always > match intended config.
OK, I can see this perspective. For now I've updated #3 with a proposal to remove A & B, with a remaining open issue is top-level requirement #3 is still needed. > Hence I still question whether there is a need for the system to > advertise that it performs "asynchronous" configuration processing, > which is different from the requirement to support applied > configuration above. I.e. does the client need to know that config > edit operations will return before the configuration is applied to > running config. It may be that we need to get to the bottom of the > definition of "intended vs applied vs currently active" cfg before this > can be sensibly answered. Yes, and this is exactly what issue #6 is about: #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Let me start a thread on that now. Thanks, Kent
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
