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? > As long as: > 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 > 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 > 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. > 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]
