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

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

OK - thx Martin and Alex.  It seems the conclusion is that changing a type to a union is not allowed.

> -----Original Message-----
> From: Martin Bjorklund <[e-mail]>
> Sent: Monday, August 13, 2018 6:08 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] Module update rules: changing a type to a union
> 
> "Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]> wrote:
> > 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.
> 
> Right.  I think that changing from an enumeration to a union changes
> the syntax of the type, so this would not be allowed.
> 
> 
> /martin
> 
> 
> >
> >
> > 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