Hi,
We have a question on YANG module compilation. Assume the following model:
module test-feat-compile {
yang-version 1.1;
namespace "http://www.example.com/test-feat-compile";;
prefix "tfc";
identity failure-reason {
description
"The reason a failure occurred.";
}
identity no-failure {
description
"No failure has occurred.";
}
identity general-error {
base failure-reason;
description
"A general error occurred.";
}
container failure {
description
"Objects associated with a failure.";
leaf failure-reason {
type identityref {
base failure-reason;
}
description
"The reason the failure occurred.";
}
leaf failure-string {
when "../failure-reason != 'no-failure'" {
description
"Only valid when there is a failure.";
}
type string;
description
"A text string indicating the reason for the failure when
either no defined reason exists or additional information
is available beyond the definition of the reason.";
}
}
}
Looking at the when clause there is something obviously wrong (at least this is
how I see it):
* The leaf 'failure-reason' is of type identityref with 'failure-reason'
as base
* Identity 'no-failure' does not have 'failure-reason' as base (see it as
having been forgotten)
Question is: shouldn't this be reported at compile time? Pyang doesn't and the
other compiler we use doesn't report this either.
Even when 'no-failure' is modified into some arbitrary string it is still
accepted while this arbitrary string is not defined anywhere as identity.
And when it comes to the correct syntax, RFC 7950 states (section 9.1.3) that
identities in must and when statements should be prefixed (so tfc:no-failure in
this case). Also this "violation" passes.
So: what can we expect to be checked at compile time in this case? Now you can
only detect these anomalies when using a system supporting the modules and
detect that things do not work as intended. It would be better to have these
erroneous constructions being detected at compile time. If there is something
in the RFC that allows the compiler to behave as it does now it would be good
to know.
Best regards, Bart
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
