Hi Rohit,
The rule is that the operational state datastore always reports the
value in use. So, if f1="foo" and f2="bar" then that is what should be
returned. The fact that it violates a when statement is allowed, but in
this scenario, not ideal.
However, if leaf f2 can hold values even when f1 is not set to "hello"
then I don't think the model below is as clear as it could be.
Perhaps it would be better as:
list list1{
key f1;
leaf f1{
type string;
}
leaf f2{
config false;
type string;
}
leaf f2-cfg-override {
when ".../f1='hello'";
type string;
description "Force f2 override"
}
Or, alternatively, remove the when statements from f2, perhaps add a
default value "bar", and state in the description that it is only
configurable when "f1 is set to hello".
Thanks,
Rob
On 11/07/2018 15:23, Rohit R Ranade wrote:
Hi All,
Consider the model below:
----------------------------------
list list1{
key f1;
leaf f1{
type string;
}
leaf f2{
when ".../f1='hello'";
type string;
}
}
The intention of this model is to allow configuration of leaf f2 by
user, only when value of f1 is 'hello'.. For all other values of f1,
say 'foo', the system will internally choose some value say 'bar'.
When query all fields on <operational>, using condition f1='foo', if
need to output its corresponding f2 value (i.e ‘bar’) the when
condition will get violated . Is there some way to keep the
restriction on <running> , but relaxing it when showing the
<operational> output ?
RFC 8342 has the below section , but I think we cannot use the
statements below as there is no “abnormal” value here.
<operational> SHOULD conform to any constraints specified in the data
model, but given the principal aim of returning "in use" values, it
is possible that constraints MAY be violated under some circumstances
(e.g., an *abnormal value* is "in use", the structure of a list is
being modified, or remnant configuration (see Section 5.3.1) still
exists).
Any help is appreciated.
With Regards,
Rohit R Ranade
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
