Subject: [netmod] new YANG 1.1 issues: empty in union

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Apr 2014 17:42:11 -0700

Hi,

There are 3 issues in this email:

Issue 1) empty data type representation not complete in RFC 6020

9.11.4.  Usage Example

   The following leaf

     leaf enable-qos {
         type empty;
     }

   will be encoded as

    * <enable-qos/>*

   if it exists.

The text in 9.11.4 above is mis-leading.
The form *<enable-qos></enable-qos>* is also acceptable.

Issue 2) ABNF for not correct in RFC 6020 for union-specification

   union-specification = 1*(type-stmt stmtsep)

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

   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

>From sec. 9.12:

   A member type can be of any built-in or derived type, except it MUST
   NOT be one of the built-in types "empty" or "leafref".

The ABNF allows both 'empty' and 'leafref' types to be specified,even
though they are not allowed for 'union-specification'

Issue 3) Allow "empty" in union-specification types

The following is illegal in YANG:

   type union {
      type int32;
      type empty;
   }

But the following equivalent encoding is allowed:

  type union {
      type int32;
      type string { length 0; }
   }

Why is "empty" prohibited when a zero-length string
is OK, and it is encoded exactly the same as an
empty type in XML messages.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Apr 2014 14:24:15 +0200 (CEST)

> The form *<enable-qos></enable-qos>* is also acceptable.

I will change the text so that it is clear that this is just one
example of a valid encoding.

> though they are not allowed for 'union-specification'

Ok, but if we do Y30 and Y35, the grammar will be correct :)

> empty type in XML messages.

I agree.  Added as Y35.

/martin