Presumably you will have to decide on a sensible default value to use.
What value will your actual device use after the software upgrade? That should
be the value it stores in the data tree when performing the upgrade.
________________________________
From: netmod <netmod-boun...@ietf.org> on behalf of Bogaert, Bart (Nokia -
BE/Antwerp) <bart.boga...@nokia.com>
Sent: Monday, 5 March 2018 10:25 p.m.
To: netmod@ietf.org
Subject: [netmod] Guideline on modeling including features and phased support
by a device
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
