Subject: [netmod] restricted enumeration

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 13:52:33 +0200

Hi,

if we have

typedef foo {
  type enumeration {
    enum one;
    enum two;
  }
}

typedef bar {
  type foo;
}

what is the set of values permitted for "bar"? Is it empty or the same as for "foo"?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 13:56:59 +0200

> what is the set of values permitted for "bar"? Is it empty or the

The set is { one, two } - where is the hidden catch??

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 14:02:34 +0200

On Fri, Apr 29, 2016 at 02:01:08PM +0200, Ladislav Lhotka wrote:
> 
> > On 29 Apr 2016, at 13:56, Juergen Schoenwaelder <[email-masked]> wrote:
> > 
> In sec. 9.6.4 of 6020bis:
> 
>    When an existing enumeration type is restricted, the set of assigned
>    names in the new type MUST be a subset of the base type's set of
>    assigned names.  The value of such an assigned name MUST NOT be
>    changed.
> 
> In our case there are no names assigned in the new type "bar", i.e. empty set (which is a subset of the base type's set).
>

There is no type restriction hence there is no restriction of the
value space.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 14:01:08 +0200

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 14:19:08 +0200

> On 29 Apr 2016, at 14:02, Juergen Schoenwaelder <[email-masked]> wrote:
> 

The problem here is that enum statements aren't really restrictions but rather specify the new set of values. It would be kind of discontinuos: with

typedef bar {
 type foo {
   enum one;
   enum two;
 }
}

the "bar" set would be {one, two}. If I remove the "enum two;" statement, the set would be just {one}, but then if I remove the "enum one;" statement, the set would again become {one, two}.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 14:30:25 +0200

> the "bar" set would be {one, two}. If I remove the "enum two;" statement, the set would be just {one}, but then if I remove the "enum one;" statement, the set would again become {one, two}.

So what? Apparently, being able to use foo without having to repeat
all values of foo is the main reason to define foo in the first place.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 14:36:55 +0200

> On 29 Apr 2016, at 14:30, Juergen Schoenwaelder <[email-masked]> wrote:
> 

So what about this:

typedef bar {
 type foo {
   enum one {
     if-feature fancy;
   }
 }
}

If "fancy" feature is supported then the "bar" set is {one}. But if it isn't supported, then what?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 14:41:07 +0200

> If "fancy" feature is supported then the "bar" set is {one}. But if it isn't supported, then what?

If the "fancy" feature is not set, the value set of "bar" is {} (since
there is a restriction reducing the value set to an empty set).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 14:57:36 +0200

> On 29 Apr 2016, at 14:41, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I think you have no support for this conclusion in 6020bis text, it depends on what "conditional" means. One defensible interpretation is that 

type foo {
  enum one {
    if-feature fancy;
  }
}

is equivalent to

type foo {
}

if feature "fancy" isn't supported.

Or are you saying that "type foo {}" is not the same as "type foo;"?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 15:07:12 +0200

> Or are you saying that "type foo {}" is not the same as "type foo;"?

Yes, "type foo {}" has a restriction while "type foo;" does not have a
restriction. OK, I think I see your point now that we have a case
where there is a subtle difference between "{}" and ";" and so you
suggest to interpret "type foo {}" as all values of foo?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 15:28:34 +0200

> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Now it becomes really interesting! :-) I wonder if there is any YANG parser out there that is able to distinguish those two syntactic forms. I think they must be considered identical by all means.

My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not the 1.0 semantics though.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 15:37:05 +0200

> My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not t…

I see the reasoning but then having to repeat all enumerations
whenever you use foo seems not at all user friendly...

/js

---

From: Per Hedeland <[email-masked]>
Date: Fri, 29 Apr 2016 15:51:22 +0200

> Now it becomes really interesting! :-) I wonder if there is any YANG parser out there that is able to distinguish those two syntactic forms. I think they must be considered identical by all means.

+1. Though if I read the ABNF right, "type foo {}" is actually illegal
if foo is an enum type.:-)

> My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not t…

No, it isn't - and I think the answer to your *original* question is
quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
says:

   An enumeration can be restricted with the "enum" (Section 9.6.4)
   statement.

If there is no "enum" statement, there is no restriction, and thus foo
and bar are identical. The "if-feature removes all the enum
restrictions" case is perhaps ambiguous with an "extremely literal"
interpretation of "if-feature", but to me (just having implemented
if-feature for enums/bits in our compiler) it is obvious that this case
too is a restriction and not an identity - the if-feature only modifies
the specifics of the restriction.

But adding some text that clarifies this can't hurt I guess (just like
the text that points out that the outcome of if-feature evaluation does
not affect the value assignment).

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 16:15:30 +0200

> On 29 Apr 2016, at 15:51, Per Hedeland <[email-masked]> wrote:
> 

I don't think so:

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [type-body-stmts]
                          "}") stmtsep

Everything inside the braces is optional.
 
> the specifics of the restriction.

Yes, this makes sense, too, but needs to be explained. In a way, solution Y10-02 would have been more straightforward.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Fri, 29 Apr 2016 16:32:18 +0200

> Everything inside the braces is optional.

Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
flipping between the two) has:

                              type-body-stmts
                          "}")

> Yes, this makes sense, too, but needs to be explained.

I think some text would be appreciated if you think it is needed.

> In a way, solution Y10-02 would have been more straightforward.

Please don't do that.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 17:07:43 +0200

> On 29 Apr 2016, at 16:32, Per Hedeland <[email-masked]> wrote:
> 

OLD

NEW
   When an existing enumeration type is restricted by means of one or more
   "enum" statements (even if any or all of them are disabled through an
   "if-feature" statement), the set of assigned names in the new type MUST
   be a subset of the base type's set of assigned names.  The value of such
   an assigned name MUST NOT be changed.

   If a new type is derived from an existing enumeration type and no "enum"
   restrictions are specified, then the sets of permitted values are the same
   for both types.

And the same for bits type, mutatis mutandis.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Fri, 29 Apr 2016 17:46:07 +0200

> And the same for bits type, mutatis mutandis.

Agree with the first paragraph, but I do think the second is superfluous
- it just says "if there is no restriction statement, the type isn't
restricted". This is true for all types.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Apr 2016 18:28:13 +0200

> On 29 Apr 2016, at 17:46, Per Hedeland <[email-masked]> wrote:
> 

OK, Lada