I would like to get some guidance on best practice for modeling special values.
For certain technologies, the management specification notes special integer
values to represent certain conditions.
For example, an SNR margin could be defined as an unsigned 8-bit integer where
the values of 0-30 represent the margin in dB and a special value, 255, which
represents the value is unavailable (a valid use case when the line is not
synchronized).
In the past, we have defined MIB objects using the same type and special
integer value as defined in the management specification. This means that users
of the MIB need to be aware of all special values defined and how they map to
what they represent. We duplicated this in our current YANG model as well.
leaf snr-margin {
type uint8 {
range "0..30 | 255";
}
}
Recently, I proposed in BBF to model these special values in a more explicit
manner as a union between an enumeration and an integer. Given the example
above, you could have this.
leaf snr-margin {
type union {
type enumeration {
enum unavailable;
}
type uint8 {
range "0..30";
}
}
}
This allows for all special values to be mapped to explicit values instead of
numeric ones. This proposal was met with some opposition on the implementation
side of things as being more complex than necessary as the special integer
value is sufficient and requires no extra processing to parse a union of string
and integer.
I now ask this working group what are your opinions on this with respect to a
best practice of modeling? Should we continue down the legacy path of modeling
special integer values or would a better solution be to use a union of an
enumeration and integer to define these special values more explicitly at the
expense of implementation complexity?
Best regards,
Joey
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
