On Thu, Dec 19, 2024 at 11:41:26AM +0000, maqiufang (A) wrote: > > Another example would be a license that expires, such that a subset of the > configuration is no longer valid. Choices could be: > - Configuration is left as it is, but the configuration is no longer > valid, and the configuration becomes unapplied. Attempts to configure the > feature without a valid license would be rejected with an error during > validation. > - Configuration is automatically removed from running by the device > (but I don't like this option). I prefer if the client *always* controls the > contents of running. > - Always allow the configuration, even if there is no valid license > present) but just don't apply it if there isn't a valid license (this seems > like generally less helpful behaviour to me).
I believe the proper model is that the configuration remains valid but it is not applied. Like we can have interface configuration that is valid but not applied (e.g. the interface does not exist or is of the wrong type). > So, in summary, perhaps not as clean as a MUST, but maybe more > pragmatic/realistic? I believe a lot of this has to do with designing data models such that validity of configuration is not directly tied to the presence of certain resources. The difference between config being valid and config being valid and applied matters. > My concern is related to the statement in RFC 8342: <intended> MUST always be > a valid configuration data tree. > If a client references an interface eth0 in <running> which is afterwards > physically removed and thus disappears from <system>, we end up with dangling > reference in <intended>. Similarly, If the upgrade/downgrade happens before > keeping the configuration consistent, the invalidity of configuration between > t1 (the upgrade/downgrade) and t2 (the first operation to make configuration > consistent) seems also a violation of that statement. > > I kind of agree that we should say less rather than more, especially when > this is beyond the scope of the document. The examples here are used only to > enlighten some possible solutions, we can remove these, but I am really > unsure we should relax MUST to SHOULD here. If config is bound to resources by name, then name binding failures lead to configuration not being applied. This is acceptable and part of our NMDA. Having name binding failures cause invalid intended is IMHO not acceptable and hence also something NMDA did not allow. This is not about clever wording, this is about agreeing on a proper architectural model. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
