ConfD User Community

Can enums have the if-feature?


My confd server is providing a module with an enumeration type which includes if-feature, like below. Is this invalid YANG ?

type enumeration {
enum measurement-job {
	if-feature job1;
	value 1;
	description "enum1";
enum threshold-job {
	if-feature job2;
	value 2;
	description "enum2";
enum realtime-job {
	if-feature job3;
	value 3;
	description "enum3";


Other parsers (Opendaylight and MG-Soft’s YANG compiler) do not accept this, respectively complaining…
Errorcode: “Leaf (…) type has default value ‘measurement-job’ marked with an if-feature statement”
[ERROR] ericsson-pm@2017-10-31:855: default: the definition of enum “measurement-job” used for the default value is marked with an “if-feature” statement

According to RFC 6020 it looks like an enum definition may not contain the statement if-feature (see syntax of “enum-stmt” from rfc6020 below)

enum-stmt = enum-keyword sep string optsep
(";" /
“{” stmtsep
;; these stmts can appear in any order
[value-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

Other definitions are allowed to contain an if-feature, e.g. a leaf object (see syntax of “leaf-stmt” from rfc6020 below)

leaf-stmt = leaf-keyword sep identifier-arg-str optsep
“{” stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

I would appreciate if someone could confirm if indeed the if-feature is not allowed in an enum.

Best Regards.


No, if-feature on “enum” (and “bit” and “identity”) was added in YANG 1.1, see and - i.e. it is allowed in a YANG 1.1 module, but not in YANG 1.

I guess they don’t support YANG 1.1 then - which is a pretty serious limitation in my opinion, the RFC is now almost three years old…


Thanks! I have passed on the request to support YANG 1.1.


It seems the invalidity could indeed be related to the enum definition, but indirectly.
In the definition of the leaf type using the typedef there is the keyword “default”.

typedef job-type {
  type enumeration {
    enum measurement-job {
      if-feature measurement-jobs;
        value 1;
        description "Measurement Job";
    leaf type { 
      type job-type;
        default measurement-job;
          description "Type of PM job.";

In RFC7950 there is the following passage:

7.6.4. The leaf’s “default” Statement

The “default” statement, which is optional, takes as an argument a
string that contains a default value for the leaf.

The value of the “default” statement MUST be valid according to the
type specified in the leaf’s “type” statement.

The “default” statement MUST NOT be present on nodes where
“mandatory” is “true”.

The definition of the default value MUST NOT be marked with an
“if-feature” statement. For example, the following is illegal:

 leaf color {
   type enumeration {
     enum blue { if-feature blue; }
   default blue; // illegal - enum value is conditional

Could this be the real reason for the parser error ?


I was about to reply that you’d better ask the authors of those tools about the meaning of their error messages:-), but actually looking at them now (seems I only read your question earlier…), it seems obvious that yes, they are specifically complaining about the default value, not about the if-feature as such.