Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid parser for YANG enumeration type #1415

Open
alexandergall opened this issue Feb 4, 2019 · 4 comments
Open

Invalid parser for YANG enumeration type #1415

alexandergall opened this issue Feb 4, 2019 · 4 comments
Labels

Comments

@alexandergall
Copy link
Contributor

Consider the schema

module test {
  namespace test;
  prefix test;
  
  leaf test {
    type enumeration {
      enum foo { value 1; }
      enum bar { value 2; }
    }
  }
}

In my understanding, the following should be a valid configuration

test foo;

and the parser should produce the Lua table

{ test = 1 }

Instead, I get an error

test foo;
         ^
lib/yang/parser.lua:49: <unknown>:1:9: error: enumeration foo is not a valid value

The error originates from lib.yang.data

local function enum_validator(enums, f)
   if not enums then return f end
   return function (val, P)
      if not enums[val] then
         P:error('enumeration '..val..' is not a valid value')
      end
      return f(val, P)
   end
end

The enums table is keyed by the enumeration values, rather than the names of the enum objects. This seems backwards to me unless I completely misunderstand the semantics of enumeration.

@alexandergall
Copy link
Contributor Author

Looking a bit at the code it seems to me that the semantics of enumeration have just not been implemented yet. When enum_validator() is called, the substatements have been parsed into the array

{ {
    if_features = {},
    kind = "enum",
    name = "foo",
    value = 1
  }, {
    if_features = {},
    kind = "enum",
    name = "bar",
    value = 2
  } }

The value from the configuration is then used as a key into this array, which is completely bogus. What should happen is that the missing values are assigned according to 9.6.4.2 of RFC6020 (in this example they are set explicitely but that's optional) and the value from the configuration needs to be compared with the name attribute of the enums. The first part probably needs to be done somewhere else.

@dpino
Copy link
Contributor

dpino commented Feb 5, 2019

Good investigation. Definitely this is a bug, enum_validator should validate on key, not value. If you need to continue with your work, simply disable the enum_validator. I'd try to look into this issue if I have some spare time.

@alexandergall
Copy link
Contributor Author

I have implemented this here https://github.com/alexandergall/snabbswitch/tree/yang-enumeration. I tried to guess where the code should go :) Can you please have a look (I'm also unsure about the style of error messages this should generate)?

I'm not sure whether it's actually useful to set the numeric value in the final Lua table or the name of the selected enum. My code currently does the latter, i.e. in the example above, the result is

{ test = "foo" }

This seems more useful since otherwise the Lua code processing this table needs to define the same name-to-value mapping as the schema.

dpino referenced this issue in alexandergall/snabbswitch Feb 5, 2019
Implement semantics according to RFC6020, 9.6.  When validating a
configuration against a schema which contains

leaf foo {
  type enumeratoion {
    enum bar;
    enum baz;
  }
}

the resulting Lua table will contain the key "foo" whose value is the
string of the chosen enum in the configuration, e.g.

{
  foo = "baz"
}

It is debatable whether this should actually result in the numerical
value assigned to the name in the schema.
@alexandergall
Copy link
Contributor Author

Proposed fix: #1416

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants