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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
