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 <[email protected]> > Sent: Monday, August 13, 2018 6:08 AM > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Module update rules: changing a type to a union > > "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
