Thanks Kent. So the answer for example 1 is “yes” (and foo1 could have an origin of “system”).
But I’m still a little unclear on some aspects of examples 2 and 3. In example 2, would leaf bar only show up in operational if the router considers foo2 to be configured/enabled? In other words, just the fact that foo2 has a descendant leaf with a default doesn’t (on its own) cause foo2 to show up in operational. So we would only expect to see an origin like “system” for foo2 and not an origin of “default”. This may also somewhat hinge on the fact that presence containers can’t really have a default so perhaps they could never show up in operational with a default of enabled/configured? I had a similar question about example 3. I think maybe “item apple” can only be read in operational if the router considers foo3 to be enabled/configured somehow right? Just the presence of “item apple” doesn’t, on its own, cause foo3 to show up in operational (and if it did, I’m not sure what the origin would be in that case). Jason From: Kent Watsen <[email protected]> Sent: Thursday, October 17, 2024 5:38 PM To: Jason Sterne (Nokia) <[email protected]> Cc: [email protected] Subject: Re: [netmod] Can get-data from operational return a non-configured presence container? 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 Jason, I hope others chime in, but my thoughts are that <operational> MAY return CT-nodes that are not configured via <running>, but its “origin” attribute MUST correctly indicate where it came from. Some examples: - the node is *configured* by the <system> datastore - the node is *configured* by a “dynamic” datastore Kent // contributor On Oct 16, 2024, at 5:32 PM, Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi all, (1) Simple example YANG model 1: container system { container foo1 { presence; } } Assume running does *not* have foo configured/enabled. Is it possible for a server to decide to return the following in a response to a get-data from “operational”? i.e. for whatever reason, the server considers foo1 as operationally enabled? <system> <foo1/> </system> I think this might be somewhat analogous to the way an interface can show up in the interfaces list in operational even though it isn’t in the running config. But I’m not positive if presence containers have this same possibility. (2) Simple example YANG model 2: container system { container foo2 { presence; leaf bar { type string; default “hello” } } } Again assume running does *not* have foo configured/enabled (or bar). Would a get-data from “operational” return this? <system> <foo2> <bar>hello</bar> </foo2> </system> (3) Finally, here’s another one: container system { container foo3 { presence; list item { key name; leaf name { type string;} } } } If running contains nothing, but the system considers an item called “apple” to exist operationally, would a get-data from “operational” return this? <system> <foo3> <item> <name>apple</name> </item> </foo3> </system> Jason (he/him) _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
