Thx Kent. Please see inline. Jason From: Kent Watsen <[email protected]> Sent: Thursday, November 21, 2024 3:41 PM To: Jason Sterne (Nokia) <[email protected]> Cc: Jürgen Schönwälder <[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. Hi Jason, On Nov 21, 2024, at 12:19 PM, Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>> 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>) My understanding from RFC8342 is that the origin identities do not point to a specific datastore, but rather some characteristics of the data. For instance, "or:intended" does not mean from the <intended> datastore, but rather it was intended (by clients). Similarly, “or:system” does not mean from the <system> datastore, but rather from the system (running code). [>>JTS:] It may indeed be OK to consider origin identities as not necessarily tied to a DS, but 8342 does say this: intended: represents configuration provided by <intended> So I’m not sure if having some config that shows up in <intended> can then show up in <operational> with an origin besides or:intended without considering that an update (change) to 8342? As long as: 1. We’re ok that some data (i.e. from the <system> DS) that appears in <intended> doesn’t need to have origin or:intended in <operational>, and 2. We don’t really feel it is important to differentiate the origin of data that came from the <system> DS from data that comes from “the system” (running code, items added by the system but not present in the <system> DS 3. We agree that not all data in <operational> with origin or:system must also be present in the <system> DS then we can just use or:system and not have any new sys:system identity. 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. It is not expected that 100% of the "or:system” nodes in <operational> will be in <system>. [>>JTS:] I think we should put this sentence right in the draft. That sets the bar unrealistically high. I assume that <system> will be both incomplete and sometimes not exact (like in your ‘pir' example below). The real system (running code) will always have the final say, regardless what is in <system> datastore. 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) Agreed, that would be weird.[>>JTS:] Glad we’re on the same page on that. I may also be incorrect that the origin in this case is supposed to be or:system but it isn’t obvious to me what else to use. Or:intended isn’t quite right although maybe it could also be “good enough” since the source of the value is from user configuration (even if we didn’t use the exact value). Jason Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
