Re: [netmod] EXTERNAL: Module update rules: changing a type to a union

[Alex Campbell <[e-mail]>]

Hi,


It seems to be that the rule you quoted specifically states that expanding the value space is not okay:


   o  A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.



________________________________
From: netmod <[e-mail]> on behalf of Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
Sent: Saturday, 11 August 2018 3:19 a.m.
To: [e-mail]
Subject: EXTERNAL: [netmod] Module update rules: changing a type to a union

Hi all,

I'm uncertain about how to interpret the YANG module update rules when a type changes to a union.

Is the following change allowed?

From:
  typedef my-type {
    type enumeration {
      enum "foo";
    }
  }
To:
  typedef my-type {
    type union {
      type enumeration {
        enum "foo";
      }
      type uint32;
    }
  }

The general spirit of the rules is that expanding the value space is generally OK, but this case does seem to violate this paragraph of section 11:

   o  A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.


Does the addition of the union change the semantics of the type if that union encompasses the original type?

With XML encoding I can see how an "old" client could easily still communicate with a "new" server for this change. But I wonder about other possible encodings that might change when a type becomes a union that contains additional types.

Regards,
Jason