Thinking more about this has led me to another related question for the old
NETCONF RFC 6241 (pre NMDA) <get> operation.
(4)
YANG model (config false leaf inside a config true tree):
container system {
list item {
key name;
leaf name { type string; }
leaf property-x { type string; }
leaf counter1 {
config false;
type uint8;
}
}
}
Can a <get> ever return the leaf ‘counter1’ for an ‘item’ that isn’t explicitly
configured (i.e. in running)?
Notice that this model has state nodes inside a config tree. Maybe NETCONF just
didn’t handle this type of model very well pre-NMDA (and hence the scenario I’m
bringing up, and likely a mix of implementation choices out there for this
one…).
The RFC 8343 Interfaces YANG model deals with this by having a separate config
false /interfaces-state tree for pre-NMDA implementations. But that separation
isn’t always available in all models (e.g. OpenConfig models), and it still
begs the question of what <get> should return for the “combined config + state”
tree in RFC 8343 in the scenario I describe above.
Jason
From: Jason Sterne (Nokia) <[email protected]>
Sent: Monday, October 21, 2024 10:25 AM
To: Kent Watsen <[email protected]>
Cc: [email protected]
Subject: [netmod] Re: Can get-data from operational return a non-configured
presence container?
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]<mailto:[email protected]>>
Sent: Thursday, October 17, 2024 5:38 PM
To: Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[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]
