Hi Lada,
On 13/12/2018 09:58, Ladislav Lhotka wrote:
On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
Ladislav Lhotka <[email protected]> wrote:
On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
Hi Lada,
I basically agree with Jan's suggestion.
I don't think that I would use a when statement for this scenario since
you
want a leaf to report the operational value that is in effect, and one of
the
aims of NMDA is to try and get the configured and operational value onto
the
same path wherever possible.
But, I think that the question about validity of must statements is more
interesting. RFC 8342 states that these can be violated in operational,
but
the intention is that the constraints in <operational> should generally
apply
(but never be actually checked by the server). In this case, it might be
useful to be able to annotate a must statement to indicate that it only
applies to configuration data and not operational data.
Another option could be that "must" constraints on config data do not apply
in
<operational>, whereas constraints on "config false" data serve as binding
guidelines for implementors.
Not sure what "binding guideline" means, but note that RFC 8342 says
for <operational>:
<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 [...]
According to the definition of SHOULD and MAY in RFC 2119, this sentence
contradicts itself.
I don't actually see the contradiction here.
- SHOULD can be violated if there are good reasons to do so (otherwise
it is a MUST)
- The MAY, and its associated condition, explains some conditions under
which it is reasonable for the SHOULD to be violated.
Thanks,
Rob
Only semantic constraints MAY be violated. These are the YANG
"when", "must", "mandatory", "unique", "min-elements", and
"max-elements" statements; and the uniqueness of key values.
It is nice to see "when" listed among semantic constraints. Note, however, that
in sec. 8.1 of RFC 7950, "when" ended up among the constraints that are true in
all data trees (despite my hefty protests in the past). So this is really weird.
Lada
It would be useful with a YANG statement that indicates when the
modeller's intention is that a constraint doesn't apply to
<operational>. For now, this can be indicated in the description
statement, for example:
leaf foo {
when "../auto-foo = 'false'" {
description
"This when expression does not apply to <operational>.";
}
...
}
/martin
Anyway, the logic of my example could then be implemented using "must". I
agree
though that ignoring the configured value if auto-foo is true may be
preferable.
Lada
Thanks,
Rob
On 12/12/2018 14:52, Jan Lindblad wrote:
Lada,
Maybe you could just skip the when and explain the behavior in the
description? E.g.
leaf foo {
...
description "Foo controls bla, bla.
Any configured value will be ignored when auto-foo is true.";
}
Best Regards,
/jan
On 12 Dec 2018, at 15:33, Ladislav Lhotka <[email protected]> wrote:
Hi,
in some cases, constraints expressed with "when" or "must" may only be
intended for configuration datastores. A typical example is an
auto-negotiable parameter:
leaf auto-foo {
type boolean;
default true;
description "If true, parameter 'foo' will be auto-negotiated.";
}
leaf foo {
when "../auto-foo = 'false'";
...
}
This means that if auto-foo is true, it is impossible to configure the
foo parameter. However, even with auto-foo = true, it is desirable to
see the auto-negotiated value in <operational>, so, ideally, the
"when"
constraint should not apply in <operational>.
How can this logic be modelled under NMDA? Is an extra leaf
"foo-operational" needed?
Thanks, Lada
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
