Hi, Kent, Jason, Please see inline.
From: Kent Watsen [mailto:[email protected]] Sent: Friday, November 22, 2024 5:27 AM To: Jason Sterne (Nokia) <[email protected]> Cc: Jürgen Schönwälder <[email protected]>; [email protected] Subject: [netmod] Re: origin "system" in system-config-09 Hi Jason, [>>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? Fair. We didn’t consider the possibility of a <system> datastore when RFC8342. In that case, I recommend this draft *update* RFC8342 to clarify that. Agreed? The definition of “or: intended” is updated in Section 1.3<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-09#section-1.3> as configuration provided by <running>. If it is not going to tie the origin value to any datastore, maybe we can fix this as configuration explicitly provided by clients. The latter seems better to me, but please feel free to suggest. 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. Sounds right to me. 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 sounds like a useful clarification. I will update the draft and add this sentence. I learned the case Jason provided below, which I tend to agree, but I do not like to impose restrictions on the scenarios in which the system configuration should or should not be present in <system>, I would treat its contents as implementation-specific. Even though some may think system configuration that is not constantly changing are suitable for <system>, because otherwise it might end up with validity of config that references <system> depending on certain resources or operational state. But there may be other cases where <system> is just there for visibility. Maybe admitting that not all “or: system” configuration in <operational> are from <system> and allowing that flexibility are good enough. Best Regards, Qiufang 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). I admit that I also struggle with some of the origin identities. Sometimes I feel that we made it too complicated. Maybe there should've been only two identities “intended” and “system”. For instance, one could argue that a client not setting a value to allow a “default” value to be used is intentional. Similarly, it seems that anything that comes from a “dynamic" datastore is also intentional, and anything that is *learned* is from the system... Should we start an NMDA-next tracker... Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
