Hi,
Could you please let me know, how confd implements container “presence” sub statement and the default non-presence statement, difference between the two from confd implementation.
Thanks & Regards,
Azeem
Hi,
Could you please let me know, how confd implements container “presence” sub statement and the default non-presence statement, difference between the two from confd implementation.
Thanks & Regards,
Azeem
I’m not sure exactly what you’re asking - how ConfD implements it doesn’t seem useful to know. The implementation behaves as required by the spec, RFC 6020 / RFC 7950. See e.g. 7.5.1. Containers with Presence in 6020.
I wanted to know how confd handles this behavior
“These containers are explicitly created and deleted.”.
This above line is from RFC 7950 - section 7.5.1
I’m afraid I’m still not clear on what your question is. That sentence just describes the possible operations on a presence container. If you are asking how to create or delete a presence container, it depends on the interface. E.g. in NETCONF, the existence of a presence-container node in the <edit-config>
payload will create it if it doesn’t exist and the current operation is merge/replace/create, delete it if it exists and the current operation is delete/remove. In the MAAPI and CDB(-operational) APIs, you need to create and delete them explicitly using maapi_create()/maapi_delete() etc. Does that help?
To be honest I am not able to understand the difference between presence and non presence from the RFC description completely.
It will be very kind of you, if you can explain me the difference between presence and non-presence(default) from CLI/NETCONF perspective.
Thanks & Regards,
Azeem
I think the best way to get some understanding is probably to create a YANG model with both presence and non-presence (np) containers and play around with it - see what you can do and can not do with the confugration. In fact the very first example in the ConfD collection, intro/1-2-3-start-query-mode, has such a module, although perhaps the presence container there isn’t a great illustration of the concept.
Other than that, what I can say is pretty much just a re-iteration of the text in the RFC: presence containers have an “existence” property - they can exist or not - and can thus represent one bit (as in “binary digit”) of information. In contrast, np-containers have no “existence” property, it makes no sense to say that they “exist” (or not) - i.e. they represent 0 bits of information, their only purpose is to give structure to the data model.
Please ignore the reply as it is duplicated with the topic #2021 and I don’t know how to delete it:
For the np-containers, if the container isn’t created but in which contains some must check which doesn’t meet the request, whether the must check should be done?
Use an example to show it:
1.There are two yang files:
module test-leafref {
namespace "http://test/leafref";
prefix leafref;
container ph1 {
list a-list {
key "x";
leaf x {
type string;
}
}
}
}
module test-leafref1 {
namespace "http://test/leafref1";
prefix leafref1;
import test-leafref {
prefix leafref;
}
augment "/leafref:ph1" {
container inner {
list b-list {
key p;
leaf p {
type leafref {
path "/leafref:ph1/leafref:a-list/leafref:x";
}
}
leaf t1{ type string;}
container test-presence {
presence "exist";
must "../t1='3'";
leaf t2{type string;}
}
}
}
}
}
<ph1 xmlns="http://test/leafref">
<a-list>
<x>3</x>
<y>1</y>
</a-list>
<inner xmlns="http://test/leafref1">
<b-list>
<p>3</p>
<t1>2</t1>
</b-list>
</inner>
</ph1>