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]> 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]

Reply via email to