Arguably the guidelines, or YANG, should say "don't allow this" ;-)
I think that what you are describing is just another instance of "don't
augment with a mandatory node rule", or "only backwards compatible
changes revisions should be made to a published YANG module".
The key reasoning behind these rules is that the a client should be able
to work unchanged after the server has been upgraded, as long as they
are not making use of any new functionality.
Thanks,
Rob
On 06/03/2018 11:34, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
Hi Rob,
I agree but the fact is that some of the BBF models have constructions
like that and we were wondering whether this should not be mentioned
in the guildelines document. Normally a server can’t set config true
leafs if there is no default available in the model. That is the
reason we reached out to NETMOD. Your suggestions can work but
require adaptation of the current model.
Regards, Bart
*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Tuesday, March 6, 2018 10:38 AM
*To:* Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>;
netmod@ietf.org
*Subject:* Re: [netmod] Guideline on modeling including features and
phased support by a device
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 <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod