Hi Jason, > On Nov 21, 2024, at 12:19 PM, Jason Sterne (Nokia) > <[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). > 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>. 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. > Jason Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
