Hi Bart,
I think that the best solution to problem is perhaps to avoid it
altogether. I.e. I don't think that the only-if-feature leaf should be
marked mandatory. Instead, it would be better to define a sensible
default value/behaviour if the leaf is absent even when the feature is
supported.
Alternatively, you can simulate something similar to an if-feature
statement by using a when or must expression instead that is predicated
on a leaf that the client must explicitly set to enable the feature,
giving control back to the client.
E.g. something along the lines of ...
leaf enable-super-feature {
if-feature test-feature;
type boolean;
default "false";
}
...
leaf only-if-feature {
when '/enable-super-feature = "true"';
type string;
mandatory true;
}
It would be interesting if you have a concrete example where neither of
the above suggestions would work or be appropriate.
Thanks,
Rob
On 05/03/2018 09:25, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
Hi,
We have a question with respect to YANG models using features. Assume
that a part of the model is defined under a feature and that this
feature-dependent part defines a leaf as mandatory.
module servers {
namespace "http://www.example.com/servers";;
prefix servers;
import ietf-inet-types {
prefix inet;
}
revision 2018-03-01 {
description
"Initial version.";
}
feature test-feature {
description "testing feature";
}
container servers {
list server {
key name;
max-elements 64;
leaf name {
type string;
}
leaf ip {
type inet:ip-address;
mandatory true;
}
leaf port {
type inet:port-number;
mandatory true;
}
leaf only-if-feature {
if-feature test-feature;
type string;
mandatory true;
}
}
}
}
Now assume that we have a device that implements the model step-wise
by first not supporting this feature and in a sub-sequent release by
supporting this feature (and uses a persistent running datastore).
The question arising now is how to deal with this mandatory leaf?
Normally this can only be configured by a client, meaning that without
any “help”, the NC server will not be able to startup with the data
contained in the device’s persistent datastore unless a value is set
for the mandatory leaf that now becomes available as a result of
supporting the feature.
When modeling as follows it seems the NC server can start with the
model supporting the feature that was not supported before:
module servers {
namespace "http://www.example.com/servers";;
prefix servers;
import ietf-inet-types {
prefix inet;
}
revision 2018-03-01 {
description
"Initial version.";
}
feature test-feature {
description "testing feature";
}
container servers {
list server {
key name;
max-elements 64;
leaf name {
type string;
}
leaf ip {
type inet:ip-address;
mandatory true;
}
leaf port {
type inet:port-number;
mandatory true;
}
container only-if-feature {
presence "see if this helps";
if-feature test-feature;
leaf only-if-feature {
type string;
mandatory true;
}
}
}
}
}
Are recommendations or guidelines in place to deal with this?
Regards, Bart
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
