Subject: [netmod] Question on when-construction involving identities not detected as an error during module compilation

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 18 May 2018 10:10:52 +0000

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 May 2018 12:16:26 +0200 (CEST)

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]> wrote:
> 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.

Strictly speaking, the "when" expressions are not erroneous; they are
proper XPath expressions that happen to always return "false".

A good compiler could detect this and produce a warning, but it would
be incorrect to flag this as an error.

/martin

---

From: Michal Vaško <[email-masked]>
Date: Fri, 18 May 2018 12:23:18 +0200

Hi,

> be incorrect to flag this as an error.

Exactly and you can try using yanglint(1) from libyang [1], which prints both problems you mentioned as warnings.

Kind regards,
Michal Vasko

[1] https://github.com/cesnet/libyang

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 18 May 2018 12:24:57 +0200

> be incorrect to flag this as an error.

I would also add that the XPath expression in the above module uses string
comparison which is known to be problematic. Instead, you should use the new
functions derived-from() and derived-from-or-self() introduced in YANG 1.1.

Lada

> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67