Jason, to answer your second question first: If the value of "foo" was determined by the system, then is should use the 'or:system' origin. (I want to know the true origin while troubleshooting.)
Shall we choose a different name to avoid any potential confusion? I am usually split on such questions. On the one hand there is no technical reason not to use the most obvious name, but on the other hand it can be expected that some will screw up on this. (But then they also get an opportunity to learn that identity values are qualified names.) /js On Wed, Nov 06, 2024 at 06:45:39PM +0000, Jason Sterne (Nokia) wrote: > Thanks Jurgen. > > Maybe it would also help reduce confusion if we use a slightly different name > (in addition to namespace) for nodes from the new system DS. Perhaps origin > = system-datastore? > > Any thoughts on my last question? Does it seem reasonable to you that the > leaf "foo" in operational would use origin = or:system in that case where the > applied value differs from the configured value? > > Jason > > > -----Original Message----- > > From: Jürgen Schönwälder <[email protected]> > > Sent: Wednesday, November 6, 2024 1:28 PM > > To: Jason Sterne (Nokia) <[email protected]> > > Cc: [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, > > > > I think the identity values are scoped by their module, hence there > > should be a distinction between 'or:system' and 'sysds:system' (using > > the XML encoding with the default namespace prefixes here as an > > example). > > > > 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. > > > > /js > > > > On Wed, Nov 06, 2024 at 05:59:32PM +0000, Jason Sterne (Nokia) wrote: > > > Hi all, > > > > > > draft-ietf-netmod-system-config-09 - System-defined > > Configuration<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-system-&data=05%7C02%7Cjschoenwaelder%40constructor.university%7Ce8bd55d8141246a217c908dcfe9338dd%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638665155485899808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Exe0oBgOSlFwaKG%2B1ZhgTIElzdHo4E9juZTTuj5NgEs%3D&reserved=0 > > config/> proposes an origin of "system" for nodes in the operational > > datastore > > that came from the system DS. > > > > > > But I'm wondering if we may want to consider differentiating between: > > > > > > * Nodes that use the system origin in the original NMDA spec (before > > > this > > new system DS work), but may not actually exist in the new system DS > > > * Nodes that come from the system DS > > > > > > The way it stands currently, there could be nodes in the operational DS > > > with an > > origin of system that are not in the system DS. Is that confusing? Or are > > we OK > > with: > > > > > > 1. Any node in the system DS shows up as origin "system" in the > > > operational > > DS, but > > > 2. Not all nodes with origin "system" in the operational DS are in the > > > system > > DS > > > > > > Somewhat related to this issue: NMDA allows a config true (CT) node to > > > have > > one value in <running> and a different value in <operational>. The > > <operational> > > view is supposed to return what is actually in use (which can in theory > > differ from > > what was configured in running/intended). > > > > > > If a node "foo" has value 1500 in <intended>, but in operational the > > > value is > > 1492, what should the origin be for node foo? System? > > > [note in this question/example, node "foo" is not in the system DS. It is > > > just a > > standard config node] > > > > > > Jason (he/him) > > > > > > > > _______________________________________________ > > > netmod mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany -- 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]
