I agree that content from <running> must be or:intended. I am not a fan of system messing around with <running>. RFC 8342 merges system config configuration in after <intended> and I think this was by design.
The motiviation of this I-D appears to provide config true nodes that can be referenced by other explicit configuration. This certainly leads to issues if the system config can change dynamically, e.g., by removing or replacing line cards, and you end up with dangling references. It is best if config in <running> references resources by name, like we configure an interface foo and if an interface named foo appears, the config is applied to this interface. This is a robust model, other solutions like having the system messing around with <running> or merging config from <system> into intended are much less robust, leading to "implementation specific" solutions if such things happen. But even if people want to have something populated in <running> or <system>, it would be great if the actual binding to resources would still be a name binding that resolves to nothing if the corresponding resource is not present. /js On Thu, Nov 21, 2024 at 05:19:08PM +0000, Jason Sterne (Nokia) wrote: > I’m not sure. The discussion has caused some doubt in my mind. > > If <system> is merged with <running> to form <intended>, then it is a little > odd that the origin (when reading <operational>) isn’t just or:intended. > (on the other hand, I can see it being useful to know that some piece of > config came from <system> instead of <running>) > > RFC8342 shows “system configuration” merging *after* intended. In that case > it is a little easier to see how the origin would be or:system. > > But even if we put that issue aside (and just allow some config in <intended> > to have origin = or:system when it comes from the <system> DS), I’m not > certain I agree that all elements that appear in the <operational> DS with > origin = or:system must necessarily also show up in the <system> DS. > > For built-in referenceable list entries (e.g. qos polices, system interface) > I can see how they are 1:1 between the <system> DS and or:system in the > <operational> DS. > > But I’m less certain that we’ve considered all potential types of elements or > scenarios where reading something from the <operational> DS can return > or:system. For example: > > * User configures pir = 1022 (e.g. some QoS policing parameter) > * Server accepts pir = 1022, but rounds/maps it to a value that is > actually supported on that particular hardware platform, so the system is > actually using pir = 1024 > * Reading <operational> should return pir = 1024, but could the origin be > or:system in this case? > * I think it would be odd for pir to suddenly show up in the <system> DS > in this situation (and I don’t think we should mandate that) > > Jason > > > From: Kent Watsen <[email protected]> > Sent: Thursday, November 21, 2024 8:29 AM > To: Jürgen Schönwälder <[email protected]>; Jason Sterne > (Nokia) <[email protected]>; maqiufang <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] origin "system" in system-config-09 > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > Juergen, > > Thank you for helping to close this item. > > Jason, > > Are you okay with this resolution? > > Qiufang, > > Please update the draft to define what happens in case an update to <system> > schema and/or data causes <intended> to become invalid. > > As a participant, I wonder if it would be possible to enumerate such cases. > For instance, let’s assume a software-update removes or renames a “shared > object” in <system> that is being used. In this case, I would hope that the > installer would check for use of the old shared object and prompt the user > what to do. For instance, if the shared object was removed, the installer > could auto-create the shared object in <running>. Similarly, if the shared > object was renamed, the installer could auto-update the leafref in <running> > to point to the new name. Likely it will be impossible to enumerate all > possibilities, and so some generic catch-all text will be needed. For > instance (please rephrase), “Servers MUST ensure that updates to <system> > schema and/or data do not result in <intended> becoming invalid. It is out > of scope of this document to define specific remediation mechanisms." > > Kent > > > while re-reading parts of the I-D, I tend to agree that using > or:system seems about right. > > Perhaps more explanation would be helpful how to resolve problems is > if client config depends on <system> confif and changes to <system> > cause <intended> to become invalid. Or is the undefined merge going to > "unmerge" stale client config in this situation? Or does the device > reboot to signal it had an internal problem? ;-) Section 6 details > that such a situation is possible, it does not detail how system > changes leading to an invalid <intended> are handled. > > /js > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
