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 <[email protected]> on behalf of Sterne, Jason (Nokia -
CA/Ottawa) <[email protected]>
Sent: Saturday, 11 August 2018 3:19 a.m.
To: [email protected]
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
