enclosed in parenthesis.
Value Examples:
null // legal identity name
snmpUDPDomain // legal identity name
Restriction Examples:
Pointer (snmpTransportDomain) // legal restriction
3.3. ObjectIdentifier
The ObjectIdentifier base type represents administratively assigned
names for use with SNMP and COPS-PR. This type SHOULD NOT be used in
protocol independent SMIng modules. It is meant to be used in SNMP
and COPS-PR mappings of attributes of type Pointer (Section 3.2).
Values of this type may be denoted as a sequence of numerical non-
negative sub-identifier values in which each MUST NOT exceed 2^32-1
(4294967295). Sub-identifiers may be denoted in decimal or `0x’-
prefixed hexadecimal. They are separated by single dots and without
any intermediate white space. Alternatively (and preferred in most
cases), the first element may be a previously defined or imported
lower-case identifier, representing a static object identifier
prefix.
Although the number of sub-identifiers in SMIng object identifiers is
not limited, module designers should realize that there may be
implementations that stick with the SMIv1/v2 limit of 128 sub-
identifiers.
Object identifier derived types cannot be restricted in any way.
Value Examples:
1.3.6.1 // legal numerical oid
mib-2.1 // legal oid with identifier prefix
internet.4.1.0x0627.0x01 // legal oid with hex subids
iso.-1 // illegal negative subid
iso.org.6 // illegal non-heading identifier
IF-MIB::ifNumber.0 // legal fully qualified instance oid
3.4. Integer32
The Integer32 base type represents integer values between
-2^31 (-2147483648) and 2^31-1 (2147483647).
Values of type Integer32 may be denoted as decimal or hexadecimal
numbers, where only decimal numbers can be negative. Decimal numbers
other than zero MUST NOT have leading zero digits. Hexadecimal
numbers are prefixed by `0x’ and MUST have an even number of at least
two hexadecimal digits, where letters MAY be upper-case, but lower-
case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Integer32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. Each value can be given in decimal or `0x’-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given they
all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type, the new
restriction MUST be equal or more limiting, that is raising the lower
bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate
gaps.
Value Examples:
015 // illegal leading zero
-123 // legal negative value
- 1 // illegal intermediate space
0xabc // illegal hexadecimal value length
-0xff // illegal sign on hex value
0x80000000 // illegal value, too large
0xf00f // legal hexadecimal value
Restriction Examples:
Integer32 (0 | 5..10) // legal range spec
Integer32 (5..10 | 2..3) // illegal ordering
Integer32 (4..8 | 5..10) // illegal overlapping
3.5. Integer64
The Integer64 base type represents integer values between
-2^63 (-9223372036854775808) and 2^63-1 (9223372036854775807).
Values of type Integer64 may be denoted as decimal or hexadecimal
numbers, where only decimal numbers can be negative. Decimal numbers
other than zero MUST NOT have leading zero digits. Hexadecimal
numbers are prefixed by `0x’ and MUST have an even number of
hexadecimal digits, where letters MAY be upper-case, but lower-case
characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Integer64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, with the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. Each value can be given in decimal or `0x’-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given, they
all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type, the new
restriction MUST be equal or more limiting, that is raising the lower
bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate
gaps.
Value Examples:
015 // illegal leading zero
-123 // legal negative value
- 1 // illegal intermediate space
0xabc // illegal hexadecimal value length
-0xff // illegal sign on hex value
0x80000000 // legal value
Restriction Examples:
Integer64 (0 | 5..10) // legal range spec
Integer64 (5..10 | 2..3) // illegal ordering
Integer64 (4..8 | 5..10) // illegal overlapping
3.6. Unsigned32
The Unsigned32 base type represents positive integer values between 0
and 2^32-1 (4294967295).
Values of type Unsigned32 may be denoted as decimal or hexadecimal
numbers. Decimal numbers other than zero MUST NOT have leading zero
digits. Hexadecimal numbers are prefixed by `0x’ and MUST have an
even number of hexadecimal digits, where letters MAY be upper-case,
but lower-case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Unsigned32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, with the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. Each value can be given in decimal or `0x’-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given, they
all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type, the new
restriction MUST be equal or more limiting, that is raising the lower
bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate
gaps.
Value Examples:
015 // illegal leading zero
-123 // illegal negative value
0xabc // illegal hexadecimal value length
0x80000000 // legal hexadecimal value
0x8080000000 // illegal value, too large
Restriction Examples:
Unsigned32 (0 | 5..10) // legal range spec
Unsigned32 (5..10 | 2..3) // illegal ordering
Unsigned32 (4..8 | 5..10) // illegal overlapping
3.7. Unsigned64
The Unsigned64 base type represents positive integer values between 0
and 2^64-1 (18446744073709551615).
Values of type Unsigned64 may be denoted as decimal or hexadecimal
numbers. Decimal numbers other than zero MUST NOT have leading zero
digits. Hexadecimal numbers are prefixed by `0x’ and MUST have an
even number of hexadecimal digits, where letters MAY be upper-case,
but lower-case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Unsigned64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, with the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. Each value can be given in decimal or `0x’-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given, they
all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type, the new
restriction MUST be equal or more limiting, that is raising the lower
bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate
gaps.
Value Examples:
015 // illegal leading zero
-123 // illegal negative value
0xabc // illegal hexadecimal value length
0x8080000000 // legal hexadecimal value
Restriction Examples:
Unsigned64 (1..10000000000) // legal range spec
Unsigned64 (5..10 | 2..3) // illegal ordering
3.8. Float32
The Float32 base type represents floating point values of single
precision as described by [IEEE754].
Values of type Float32 may be denoted as a decimal fraction with an
optional exponent, as known from many programming languages. See the
grammar rule `floatValue’ of Appendix B for the detailed syntax.
Special values are `snan’ (signalling Not-a-Number), `qnan’ (quiet
Not-a-Number), `neginf’ (negative infinity), and `posinf’ (positive
infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the
Float32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, with the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. If multiple values or ranges are given, they all MUST be
disjoint and MUST be in ascending order. If a value restriction is
applied to an already restricted type, the new restriction MUST be
equal or more limiting, that is raising the lower bounds, reducing
the upper bounds, removing explicit values or ranges, or splitting
ranges into multiple ranges with intermediate gaps. The special
values `snan’, `qnan’, `neginf’, and `posinf’ must be explicitly
listed in restrictions if they shall be included, where `snan’ and
`qnan’ cannot be used in ranges.
Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float32.
Note also that most floating point encodings disallow the
representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be handled
with care.
Value Examples:
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
Restriction Examples:
Float32 (-1.0..1.0) // legal range spec
Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float32 (neginf..-0.0) // legal range spec
Float32 (-10.0..10.0 | 0) // illegal overlapping
3.9. Float64
The Float64 base type represents floating point values of double
precision as described by [IEEE754].
Values of type Float64 may be denoted as a decimal fraction with an
optional exponent, as known from many programming languages. See the
grammar rule `floatValue’ of Appendix B for the detailed syntax.
Special values are `snan’ (signalling Not-a-Number), `qnan’ (quiet
Not-a-Number), `neginf’ (negative infinity), and `posinf’ (positive
infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the
Float64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, with the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. If multiple values or ranges are given, they all MUST be
disjoint and MUST be in ascending order. If a value restriction is
applied to an already restricted type, the new restriction MUST be
equal or more limiting, that is raising the lower bounds, reducing
the upper bounds, removing explicit values or ranges, or splitting
ranges into multiple ranges with intermediate gaps. The special
values `snan’, `qnan’, `neginf’, and `posinf’ must be explicitly
listed in restrictions if they shall be included, where `snan’ and
`qnan’ cannot be used in ranges.
Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float64.
Note also that most floating point encodings disallow the
representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be handled
with care.
Value Examples:
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
Restriction Examples:
Float64 (-1.0..1.0) // legal range spec
Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float64 (neginf..-0.0) // legal range spec
Float64 (-10.0..10.0 | 0) // illegal overlapping
3.10. Float128
The Float128 base type represents floating point values of quadruple
precision as described by [IEEE754].
Values of type Float128 may be denoted as a decimal fraction with an
optional exponent, as known from many programming languages. See the
grammar rule `floatValue’ of Appendix B for the detailed syntax.
Special values are `snan’ (signalling Not-a-Number), `qnan’ (quiet
Not-a-Number), `neginf’ (negative infinity), and `posinf’ (positive
infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the
Float128 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|’
characters, with the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..’, and an upper
bound. If multiple values or ranges are given, they all MUST be
disjoint and MUST be in ascending order. If a value restriction is
applied to an already restricted type, the new restriction MUST be
equal or more limiting, that is raising the lower bounds, reducing
the upper bounds, removing explicit values or ranges, or splitting
ranges into multiple ranges with intermediate gaps. The special
values `snan’, `qnan’, `neginf’, and `posinf’ must be explicitly
listed in restrictions if they shall be included, where `snan’ and
`qnan’ cannot be used in ranges.
Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float128.
Note also that most floating point encodings disallow the
representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be handled
with care.
Value Examples:
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
Restriction Examples:
Float128 (-1.0..1.0) // legal range spec
Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float128 (neginf..-0.0) // legal range spec
Float128 (-10.0..10.0 | 0) // illegal overlapping
3.11. Enumeration
The Enumeration base type represents values from a set of integers in
the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where
each value has an assigned name. The list of those named numbers has
to be comma-separated, enclosed in parenthesis, and appended to the
`Enumeration’ keyword. Each named number is denoted by its lower-
case identifier followed by the assigned integer value, denoted as a
decimal or `0x’-prefixed hexadecimal number, enclosed in parenthesis.
Hexadecimal numbers must have an even number of at least two digits.
Every name and every number in an enumeration type MUST be unique.
It is RECOMMENDED that values be positive, start at 1, and be
numbered contiguously. All named numbers MUST be given in ascending
order.
Values of enumeration types may be denoted as decimal or `0x’-
prefixed hexadecimal numbers or preferably as their assigned names.
Hexadecimal numbers must have an even number of at least two digits.
When types are derived (directly or indirectly) from an enumeration
type, the set of named numbers may be equal or restricted by removing
one or more named numbers, but no named numbers may be added or
changed regarding its name, value, or both.
Type and Value Examples:
Enumeration (up(1), down(2), testing(3))
Enumeration (down(2), up(1)) // illegal order
0 // legal (though not recommended) value
up // legal value given by name
2 // legal value given by number
3.12. Bits
The Bits base type represents bit sets. That is, a Bits value is a
set of flags identified by small integer numbers starting at 0. Each
bit number has an assigned name. The list of those named numbers has
to be comma-separated, enclosed in parenthesis, and appended to the
`Bits’ keyword. Each named number is denoted by its lower-case
identifier followed by the assigned integer value, denoted as a
decimal or `0x’-prefixed hexadecimal number, enclosed in parenthesis.
Hexadecimal numbers must have an even number of at least two digits.
Every name and every number in a bits type MUST be unique. It is
RECOMMENDED that numbers start at 0 and be numbered contiguously.
Negative numbers are forbidden. All named numbers MUST be given in
ascending order.
Values of bits types may be denoted as a comma-separated list of
decimal or `0x’-prefixed hexadecimal numbers or preferably their
assigned names enclosed in parenthesis. Hexadecimal numbers must
have an even number of at least two digits. There MUST NOT be any
element (by name or number) listed more than once. Elements MUST be
listed in ascending order.
When defining a type derived (directly or indirectly) from a bits
type, the set of named numbers may be restricted by removing one or
more named numbers, but no named numbers may be added or changed
regarding its name, value, or both.
Type and Value Examples:
Bits (readable(0), writable(1), executable(2))
Bits (writable(1), readable(0) // illegal order
() // legal empty value
(readable, writable, 2) // legal value
(0, readable, executable) // illegal, readable(0) appears twice
(writable, 4) // illegal, element 4 out of range
3.13. Display Formats
Attribute and type definitions allow the specification of a format to
be used when a value of that attribute or an attribute of that type
is displayed. Format specifications are represented as textual data.
When the attribute or type has an underlying base type of Integer32,
Integer64, Unsigned32, or Unsigned64, the format consists of an
integer-format specification containing two parts. The first part is
a single character suggesting a display format, either: `x’ for
hexadecimal, `d’ for decimal, `o’ for octal, or `b’ for binary. For
all types, when rendering the value, leading zeros are omitted, and
for negative values, a minus sign is rendered immediately before the
digits. The second part is always omitted for `x’, `o’, and `b’, and
need not be present for `d’. If present, the second part starts with
a hyphen and is followed by a decimal number, which defines the
implied decimal point when rendering the value. For example `d-2’
suggests that a value of 1234 be rendered as `12.34’.
When the attribute or type has an underlying base type of
OctetString, the format consists of one or more octet-format
specifications. Each specification consists of five parts, with each
part using and removing zero or more of the next octets from the
value and producing the next zero or more characters to be displayed.
The octets within the value are processed in order of significance,
most significant first.
The five parts of a octet-format specification are:
1. The (optional) repeat indicator. If present, this part is a `*’,
and indicates that the current octet of the value is to be used as
the repeat count. The repeat count is an unsigned integer (which
may be zero) specifying how many times the remainder of this
octet-format specification should be successively applied. If the
repeat indicator is not present, the repeat count is one.
2. The octet length: one or more decimal digits specifying the number
of octets of the value to be used and formatted by this octet-
specification. Note that the octet length can be zero. If less
than this number of octets remain in the value, then the lesser
number of octets are used.
3. The display format, either: `x’ for hexadecimal, `d’ for decimal,
`o’ for octal, `a’ for ASCII, or `t’ for UTF-8 [RFC3629]. If the
octet length part is greater than one, and the display format part
refers to a numeric format, then network byte-ordering (big-endian
encoding) is used to interpret the octets in the value. The
octets processed by the `t’ display format do not necessarily form
an integral number of UTF-8 characters. Trailing octets which do