Hi Jason and Juergen, This email responds to both of your messages, i.e., keep scrolling! ;)
Kent // contributor > On Nov 7, 2024, at 1:35 PM, Jason Sterne (Nokia) > <[email protected]> wrote: > > Hi Kent, > > My thinking was along the lines of what Jurgen mentions here: there are some > values in operational that come from the system, but don't come from the > system DS. Before a server implements ietf-system, *all* such values fall into that category, right? Now assume in the next release the server implements ietf-system, which just indicates what values are/were selected before. Nothing else (e.g., internal code) changes. Did the value suddenly come from the <system> datastore, or is it more that the <system> datastore accurately modeled the system’s behavior? I think that it is that latter, but read on... > I don't think the intention was that *anything* marked with origin "system" > is also sitting there in the system DS. That would entail the data-tree in <system> being perfectly complete and accurate, which is ideal but highly unlikely. FWIW, I view this point as supporting my perspective of not trying to over engineer this. > My example of node "foo" having different values was between <running> and > <operational> (nothing to do with system DS). In the current specs (without > the new DS draft), do you agree the origin of foo would be "or:system"? Yes. > I'm simply talking about a situation where the user asks for 1500 in the > <running> but the server can't quite program that in the h/w due to some > other constraints, or some rounding function, etc and can only do 1492 so > that is what they report in <operational>. I don't think it makes sense for > that leaf to suddenly now show up in the system DS. Why not? The system-config draft indicates that the contents of the <system> datastore may change based on events such as a software/hardware/license change. What else of you think the draft intends then? [keep scrolling] > Jason > >> -----Original Message----- >> From: Jürgen Schönwälder <[email protected]> >> Sent: Thursday, November 7, 2024 4:02 AM >> To: Kent Watsen <[email protected]> >> Cc: Jason Sterne (Nokia) <[email protected]>; [email protected] >> Subject: Re: [netmod] Re: 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. >> >> >> >> On Thu, Nov 07, 2024 at 08:01:14AM +0000, Kent Watsen wrote: >>> >>>> I think it is important to keep the distinction between 'or:system' >>>> and 'sysds:system' since config generated by the system is different >>>> than config originating from a system datastore. >>> >>> I saw this comment last night and it didn’t sit right. >>> >>> Assume a server initially has no <system> datastore, and so reports a node’s >> origin as “ds:system”. >>> >>> Then later supports the <system> datastore, trying to expose some of what it >> does internally. Nothing has changed with the internal code, only the >> datastore >> was created. Why should the node’s origin change? >> >> For me, a valued copied from a datastore is different than a value >> generated by some program logic buried somewhere inside the system. I >> assume we have different understandings what a system datastore is all >> about, which then may be a bigger problem. I appreciate this perspective, but I also think that the entire goal of the <system> datastore is to model (as best as possible) the values that the buried program logic generates. >>> Regarding a value in <operational> varying from a value in <system>, >>> this just seems like a bug in the YANG defined for the <system> >>> datastore. >> >> For me, the origin indicates where I can find the source of a value. >> If the source is the system datastore, then I expect that to be >> reported and I expect to find the value also in the system datastore. >> If the source of the value is the system itself, then I expect that to >> be reported and I do not necessarily expect to find the value in the >> system datastore. I get that but, again, I see any variance as an opportunity for the server-developer to update the values populated in <system> to better model the system’s true behavior. >> I fear we may have a bigger problem by not agreeing on what the system >> datastore actually is... Indeed. It might help to think about the use-case that <system> intends to support. My understanding is that it’s trying to reveal more about what the buried program logic does, so that the network’s functioning can be better understood, e.g., to implement a digital twin. K. >> >> /js >> >> -- >> 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]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
