[netmod] Re: 3rd WGLC on system-config-10 (was "2nd")

[Jürgen Schönwälder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany