I don't think we can just say to get rid of leafrefs and use name bindings instead (or require-instance false). In many situations, the "built in" system objects were talking about in the draft are in a list that can also contain user-configured entries, and it is useful in many data models to have hard leafrefs (require instance true) to those entries (e.g. avoid misconfig with dangling references).
> -----Original Message----- > From: Jürgen Schönwälder <[email protected]> > Sent: Thursday, November 21, 2024 3:06 PM > To: Jason Sterne (Nokia) <[email protected]> > Cc: Kent Watsen <[email protected]>; maqiufang > <[email protected]>; [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. > > > > 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]
