One document matched: draft-perkins-opaque-00.txt
INTERNET-DRAFT Expires November 1996 INTERNET-DRAFT
Draft Domestication of Opaque May 27, 1996
The Domestication of the
Opaque Type for
SNMPv1 and SNMPv2
<draft-perkins-opaque-00.txt>
May 27, 1996
David T. Perkins
dperkins@scruznet.com
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Expires 11/27/96 [Page 1]
Draft Domestication of Opaque May 27, 1996
2. Introduction
This memo is experimental. It specifies a "domestication" of the Opaque
type defined in the SNMPv2 SMI[1][2][3] and the SNMPv1 SMI[4][5]. This
memo shows that the Opaque type is well defined, and after domestication
it is an effective and low-cost solution to:
1) support 64-bit counters in the SNMPv1 SMI and protocol;
2) support future types added to the SMI; and
3) support a discriminated union type.
All of these solutions are accomplished without a change to the
technical content of the specifications for the SNMPv1 and SNMPv2 SMIs,
and SNMPv1 and SNMPv2 protocols.
This memo does not specify a standard for the Internet community.
3. Background
The Opaque type is defined in the SMI for SNMPv1[4]. The ASN.1[6]
definition is contained in section 6 and follows:
Opaque ::= [APPLICATION 4] IMPLICIT OCTET
The Opaque type is described in section 3.2.3.6 and follows:
This application-wide type supports the capability to pass arbitrary
ASN.1 syntax. A value is encoded using the ASN.1 basic rules into a
string of octets. This, in turn, is encoded as an OCTET STRING, in
effect "double-wrapping" the original ASN.1 value.
Note that a conforming implementation need only be able to accept
and recognize opaquely-encoded data. It need not be able to unwrap
the data and then interpret its contents.
Further note that by use of the ASN.1 EXTERNAL type, encodings other
than ASN.1 may be used in opaquely-encoded data.
Unfortunately, the last sentence in the above description is not
technically correct. This inaccuracy is fixed in the SNMPv2 SMI[1], and
the description for the Opaque type from section 7.1.9 follows:
The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules
into a string of octets. This, in turn, is encoded as an OCTET
STRING, in effect "double-wrapping" the original ASN.1 value.
Note that a conforming implementation need only be able to accept
and recognize opaquely-encoded data. It need not be able to unwrap
the data and then interpret its contents.
Expires 11/27/96 [Page 2]
Draft Domestication of Opaque May 27, 1996
The description was made technically correct by eliminating the last
sentence, which was incorrect and provided no additional useful
information. However, the SNMPv2 WG added a policy restricting usage of
the Opaque type due to several factors including:
1)misunderstandings caused by the description of the Opaque
type in SMIv1;
2)incorrect "interpretations" spread by a few "SNMP experts";
and
3)no perceived mechanisms to describe the contents (or value)
of an Opaque type when used.
This policy is specified in the following text from section 7.1.9 of the
SMIv2:
The Opaque type is provided solely for backward-compatibility, and
shall not be used for newly-defined object types.
A requirement of "standard" MIB modules is that no object may have a
SYNTAX clause value of Opaque.
The intent of this memo is to further clarify the meaning of the Opaque
type; show how it uniquely (and at a low cost) solves several important
problems; and proposes that the policy from SMIv2 restricting usage be
replaced with the policy specified in this memo. The harnessing of the
Opaque type for practical use is called the "domestication of the Opaque
type."
Expires 11/27/96 [Page 3]
Draft Domestication of Opaque May 27, 1996
4. A Description of the Opaque Type
The Opaque type is defined in ASN.1 as the following:
-- The value for this type must be the BER serialization
-- of a valid ASN.1 value.
Opaque ::= [APPLICATION 4] IMPLICIT OCTET
This ASN.1 definition means that values are encoded using the basic
encoding rules (BER)[7], which yields the following:
------------------------
| tag | length | value |
------------------------
where:
- tag is one octet with value of '44'h.
- length is one or more octets, but is typically one octet for
a length value less than 128, two octets for a length value
less than 256, and three octets for a length value less than
65536.
- value is a string of octets that is the BER serialization of
a valid value of an ASN.1 type
A common interpretation of the definition of the Opaque type is that
values for it can be any string of octet values. This is an incorrect
interpretation. The SMI clearly specifies that the value must be the
BER serialization of a value for an ASN.1 type.
Expires 11/27/96 [Page 4]
Draft Domestication of Opaque May 27, 1996
The following table contains examples of BER serialization. The first
column contains ASN.1 type specifications. The second column contains a
valid value of the ASN.1 type specified in the same row. The third
column contains the BER serialization of the value specified in the same
row. This column also specifies valid values of the Opaque type. The
fourth column contains the BER serialization of the value of type Opaque
in the same row.
BER BER Serialization
Serialization of Value as
Type Value of value Opaque Type
------- -------- --------------- -------------------
INTEGER 67240454 '020404020306'h '4406020404020306'h
OCTET '04020306'h '040404020306'h '4406040404020306'h
STRING
OBJECT 0.4.2.3.6 '060404020306'h '4406060404020306'h
IDENTIFIER
IpAddress 4.2.3.6 '400404020306'h '4406400404020306'h
Counter 67240454 '410404020306'h '4406410404020306'h
Gauge 67240454 '420404020306'h '4406420404020306'h
TimeTicks 67240454 '430404020306'h '4406430404020306'h
Opaque '04020306'h '440404020306'h '4406440404020306'h
Counter64 67240454 '460404020306'h '4406460404020306'h
The examples clearly demonstrate that the valid values of type Opaque
and their BER serialization are well defined. Examining the result of
the BER serialization reveals that the original value is not changed.
Serialization just adds an additional tag and length "around" the
previously serialized value. BER serialization is called "wrapping a
value." The values specified in column two (in the above table) are
wrapped once in column three, and wrapped again (or "double wrapped") in
column four.
5. The Domestication of the Opaque Type
There are two problems with the current definition of the Opaque type.
First, there are no restrictions on the ASN.1 type or values that can be
"wrapped." Thus, values and ASN.1 types, even those not allowed in
SNMP, may be serialized. Secondly, usage of the Opaque type does not
require the ASN.1 type of the double wrapped values to be specified.
Thus, it is difficult, if not impossible, to "unwrap" a serialized
value.
On the other hand, the Opaque type does provide the lowest cost solution
to two critical problems in SNMP. The first problem is how to support
the addition of new basic types to the SMI and protocol. (One example is
64-bit counters in SNMPv1 SMI and protocol.) The second problem is how
Expires 11/27/96 [Page 5]
Draft Domestication of Opaque May 27, 1996
to support a "union" type that is needed in sophisticated environments
such as mid-level managers.
The taming of the current (and "wild") definition of the Opaque type for
practical uses is called the "domestication of Opaque."
The domestication is easily accomplished with a simple harnessing of the
definition of the Opaque type. A proposal for this new definition of
type Opaque follows:
The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules
into a string of octets. This, in turn, is encoded as an OCTET
STRING, in effect "double-wrapping" the original ASN.1 value.
Note that a conforming implementation of the SNMP protocol only has
to encode and decode SNMP PDUs with the value portion of a variable-
bind pair using this type.
A conforming SNMP MIB module must specify the ASN.1 type for the
original values in the DESCRIPTION clause of the OBJECT-TYPE or
TEXTUAL-CONVENTION constructs where the Opaque type is used.
Furthermore, standards track MIBs are restricted in their use of the
ASN.1 types wrapped by the Opaque type. Only the ASN.1 types
defined in the SMI for use as the value for the SYNTAX clause for
columnar and scalar objects, the SEQUENCE type, and the CHOICE type
may be used. Note, that these may be also be qualified with an
"IMPLICIT" context-specific tag. However, context-specific tags
greater than 31 are reserved for special situations, and cannot be
used.
5.1. Support for New Types
SMIv2 added a new type, Counter64, not found in SMIv1. This type was
added to address the need for event and flow counts in situations where
a 32-bit counter rolls over too rapidly (such as in a networking device
using high-speed transmission technology including FDDI and ATM).
Unfortunately, object types that are defined with syntax of Counter64
cannot be converted to a MIB module in the SMIv1 format and cannot be
accessed using the SNMPv1 protocol, since the type Counter64 is not
defined in the SNMPv1 SMI or protocol. However, instead of using the
Counter64 type directly, the Opaque type can be used to hold the
serialization of the Counter64 type, or any other new type that needs to
be added to future SMI versions.
MIB modules written to use this approach must use a textual convention
instead of the new type for the syntax of object types. Such a textual
convention is an example domestication of the untamed Opaque type. The
value of the Opaque type for the textual convention is restricted to a
Expires 11/27/96 [Page 6]
Draft Domestication of Opaque May 27, 1996
serialized value of a tagged version of the new type. This approach
allows only those SNMP managers or agents who need a new type to be
required to be upgraded. This approach requires no change, and does not
impact existing SNMP compliant agents or managers.
The domestication of the Opaque type reserves ASN.1 context-specific
tags greater than or equal to 32 for special use. ASN.1 context-
specific tags with values 48 and above are used for support of new SMI
types in old versions of the SNMP protocol. This is done by adding the
value of the tag for a "new" type to the base value 48 and using the
resulting sum as the context-specific tag for the ASN.1 type.
For example, the tag for type Counter64 is application-specific 6, which
is '46'h in BER. The sum of 48 ('30'h) and '46'h is 118 ('76'h). Thus,
the ASN.1 definition for this context-type is "[118] IMPLICIT
Counter64," with the tag encoded in BER as '9F76'h.
Note that BER encodes tags as three fields. These are class,
primitive/constructed flag, and number. If the number is less than 31,
then all three fields are encoded into one octet. If the number is 31
or greater, then multiple octets are used to encode the tag. The format
is shown below for one and two octet tags:
One octet tag Two octet tag
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
----------------- ----------------- -----------------
|cls|f| 0 - 30 | |cls|f|1 1 1 1 1| |0| 31 - 127 |
----------------- ----------------- -----------------
where:
cls is 00 - universal
01 - application
10 - context specific
11 - private use
flag is 0 - primitive
1 - constructed
Expires 11/27/96 [Page 7]
Draft Domestication of Opaque May 27, 1996
5.1.1. 64-Bit Counters
To support 64-bit counters in SNMPv2 and SNMPv1 MIB modules, and using
the SNMPv1 and SNMPv2 protocols, the following textual convention must
be used in MIB modules for the SYNTAX clause instead of the type
Counter64:
C64 TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A 64-bit counter which monotonically increases
until it reaches a maximum value of (2^64)-1
(18446744073709551615 decimal), when it wraps
around and starts increasing again from zero.
Counters have no defined 'initial' value, and thus,
a single value of a counter has (in general) no
information content. Discontinuities in the
monotonically increasing value normally occur
at re-initialization of the management system,
and at other times as specified in the description
of an object-type using this textual convention.
If such other times can occur, for example, the
creation of an object instance at times other
than re-initialization, then a corresponding
object should be defined with a SYNTAX clause
value of TimeStamp (a well-known textual
convention) indicating the time of the last
discontinuity.
The value of the MAX-ACCESS clause for objects
with a SYNTAX clause of this textual convention
must be either 'read-only' or 'accessible-for-notify'.
A DEFVAL clause is not allowed for objects using
this textual convention.
The value is restricted to the BER serialization of
the following ASN.1 type:
COUNTER64 ::= [118] IMPLICIT Counter64
(note: the value 118 is the sum of '30'h and '46'h)
The BER serialization of the length for values of
this type must use the definite length, short
encoding form.
For example, the BER serialization of value 56782 of
type COUNTER64 is '9f760300ddce'h. The BER serialization
of value '9f760300ddce'h of type Opaque is
'44069f760300ddce'h."
SYNTAX Opaque (SIZE(4..12))
Expires 11/27/96 [Page 8]
Draft Domestication of Opaque May 27, 1996
With the C64 textual convention, objects can be defined in both the
SNMPv1 and SNMPv2 SMI formats and can be accessed via both SNMPv1 and
SNMPv2 protocols. Shown below are definitions for the same object in
both SMI formats:
-- in SMIv1
exmplC64 OBJECT-TYPE
SYNTAX C64
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Example 64-bit counter available in both SNMPv1
and SNMPv2."
::= { exmpls 1 }
-- in SMIv2
exmplC64 OBJECT-TYPE
SYNTAX C64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Example 64-bit counter available in both SNMPv1
and SNMPv2."
::= { exmpls 1 }
5.1.2. Future New Types
In the future there may be a need for a limited number of additional
types to support the usage of SNMP in management of networks other than
those for computer data, such as heating and cooling systems, and
automotive traffic control. Also, distributed management of computer
data networks with so-called mid-level managers may require addition of
new types. The domestication of the opaque type allows new types to be
added without disrupting existing systems and tools used to create them.
The following text describes the process and requirements to add a new
type.
Expires 11/27/96 [Page 9]
Draft Domestication of Opaque May 27, 1996
The addition of new types is serious business and may not proceed
without careful review of the network management area. A new type may
not be defined to associate semantics with an existing type. (Note that
this requirement would not have allowed the Counter or Gauge types to be
created as basic types. Instead, they would have been textual
conventions of an unsigned integer type.) A new type may be an ASN.1
universal type or an application-specific type. For each new type
defined, a textual convention must be also be defined to wrap the new
type in an Opaque type. The following example shows the definition of
two new types. The first is an application-specific type and the second
is a universal type.
-- define a new type using the next available application
-- specific tag (note: using BER, the tag for the type is '48'h)
New1Type ::= [APPLICATION 8] IMPLICIT OCTET STRING (SIZE(4))
-- define a textual convention to wrap the new type
New1 TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A new type with some characteristics specified.
The value is restricted to the BER serialization of
the following ASN.1 type:
NEW1TYPE ::= [120] IMPLICIT New1Type
(note: the value 120 is the sum of '30'h and '48'h)
The BER serialization of the length for values of
this type must use the definite length, short
encoding form.
For example, the BER serialization of value '12345678'h
of type NEW1TYPE is '9f780412345678'h. The BER
serialization of value '9f780412345678'h of type
Opaque is '44079f780412345678'h."
SYNTAX Opaque (SIZE(7))
or
-- define a new type based on an existing ASN.1 universal type
-- (note: using BER, the tag for the type is '03'h)
New2Type ::= BIT STRING
-- define a textual convention to wrap the new type
New2 TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A new type with some characteristics specified.
The value is restricted to the BER serialization of
the following ASN.1 type:
Expires 11/27/96 [Page 10]
Draft Domestication of Opaque May 27, 1996
NEW2TYPE ::= [51] IMPLICIT New2Type
(note: the value 51 is the sum of '30'h and '03'h)
The BER serialization of the length for values of
this type must use the definite length, short
encoding form.
For example, the BER serialization of value '12345678'h
of type NEW2TYPE is '9f33050012345678'h. The BER
serialization of value '9f33050012345678'h of type
Opaque is '44089f33050012345678'h."
SYNTAX Opaque (SIZE(4..65535))
5.2. Support for Unions
There is a need for a union type that allows a value to be identified
and that allows different encodings based on the identification. This
need was present when the first version of the SMI and the IETF MIB were
created. A union was needed to hold different types of network
addresses. The solution that was created, the type NetworkAddress,
proved problematic and was not included in the SMI for SNMPv2. However,
the need for a union of network addresses still exists. Other needs
also exist. For example, researchers have created mid-level managers
that allow running of scripts to compute values, which are retrievable
via SNMP. The type of a computed value may be any of the types allowed
by the SMI such as integers, strings, and object identifiers. Without a
union type, however, a mid-level manager must define several objects,
each with the type of a potential result, and also define an object that
specifies which of the objects actually contains the result. The
development, maintenance, and operational costs of this approach are
quite high. Fortunately, these needs and others are easily satisfied
with a low-cost domestication of the Opaque type.
Expires 11/27/96 [Page 11]
Draft Domestication of Opaque May 27, 1996
5.2.1. Definition of SnmpUnion
The domestication of the Opaque type reserves ASN.1 context-specific
tags greater than or equal to 32 for special use. The ASN.1 context-
specific tag with value of 47 is used to define the SNMP union. The
domestication of opaque requires that the ASN.1 type definition be
specified for the wrapped value. The definitions of the ASN.1 type for
the SNMP union and the textual convention to wrap values as an Opaque
type follow:
-- A discriminated union
SnmpUnionType ::= [47] IMPLICIT SEQUENCE {
memberId INTEGER (-2147483648.. 2147483647),
memberType CHOICE {
-- the following types are currently defined in the SNMP SMI
int32Val INTEGER (-2147483648.. 2147483647),
stringVal OCTECT STRING (SIZE(0..65535)),
oidVal OBJECT IDENTIFIER,
noneVal NULL,
uint32Val [APPLICATION 2] IMPLICIT INTEGER (0..4294967295),
unit64Val [APPLICATION 6] IMPLICIT
INTEGER (0.. 18446744073709551615),
opaqueVal [APPLICATION 4] IMPLICIT
OCTET STRING (SIZE(2..65535)),
-- these two types are not yet defined in the SNMP SMI
floatVal -- the "single format" as defined in
-- ANSI/IEEE Std 754-1985: IEEE Standard for
-- Binary Floating Point
[APPLICATION 8] IMPLICIT OCTET STRING (SIZE(4)),
doubleVal -- the "double format" as defined in
-- ANSI/IEEE Std 754-1985: IEEE Standard for
-- Binary Floating Point
[ APPLICATION 9] IMPLICIT OCTET STRING (SIZE(8)) }}
-- The textual convention to wrap the SNMP union as an Opaque type
SnmpUnion TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A discriminated union, which is used to identify
one member from a choice of members. Each member
represents one kind of value. The objects or
textual conventions that specify this textual
convention in their SYNTAX clause must specify
in their DESCRIPTION clause a list containing
the following information:
1) discriminator value - identifies a member
2) syntax for member - one of int32, string, oid, none,
uint32, uint64, opaque, float, or double
3) description for member - any semantics associated
with the kind of value
Updates to objects (and textual conventions) using
Expires 11/27/96 [Page 12]
Draft Domestication of Opaque May 27, 1996
this textual convention may add new members,
but may never remove or change the semantics of
previously defined members.
The value is restricted to the BER serialization of
the ASN.1 type SnmpUnionType.
The BER serialization of values of type SnmpUnion
must 1) use primitive encoding, 2) use definite
encoding of the lengths, and 3) use the shortest
possible encoding of the lengths.
For example, the BER serialization of value
{ 1, int32Val 34 } of type SnmpUnionType is
'Bf2f06020101020122'h. The BER serialization of
value 'Bf2f06020101020122'h of type Opaque is
'4409Bf2f06020101020122'h."
SYNTAX Opaque (SIZE(7..65535))
5.2.2. Example Uses of SnmpUnion
With the SnmpUnion textual convention, objects can be defined in both
the SNMPv1 and SNMPv2 SMI formats and can be accessed via both SNMPv1
and SNMPv2 protocols. Shown below are definitions for the same object
in both SMI formats:
-- in SMIv1
exmplUnion OBJECT-TYPE
SYNTAX SnmpUnion
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Example object with syntax of union, available in
both SNMPv1 and SNMPv2."
::= { exmpls 2 }
-- in SMIv2
exmplUnion OBJECT-TYPE
SYNTAX SnmpUnion
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Example object with syntax of union, available in
both SNMPv1 and SNMPv2."
::= { exmpls 2 }
An example usage of a union to define a textual convention for all the
transport address types found in "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC 1905[8] follows:
Expires 11/27/96 [Page 13]
Draft Domestication of Opaque May 27, 1996
Taddr TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A transport address. The address can be from any
of the following protocol families: Internet UDP,
Internet TCP, OSI CLNS, OSI CONS, AppleTalk DDP,
and Novel IPX.
ID Syntax Description
1 none no transport address
2 string UDP - in network byte order,
octets 1..4: IP address;
octets 5..6: UDP port
3 string TCP - in network byte order,
octets 1..4: IP address;
octets 5..6: TCP port
4 string CLNS -
octet 1: length of NSAP (an unsigned
integer 'n' with value of either 0
or from 3 to 20);
octets 2..(n+1): NSAP (in concrete binary
representation);
octets (n+2)..m: TSEL (a value of
(up to 64) octets)
5 string CONS - same format as CLNS addresses
6 string DDP - a NBP name
octet 1: value, 'n', is length of object;
octets 2..(n+1): object (a value of
(up to 32) octets);
octet n+2: value, 'p', is length of type;
octets (n+3)..(n+2+p): type (a value of
(up to 32) octets);
octet n+3+p: value, 'q', is length of zone;
octets (n+4+p)..(n+3+p+q): zone (a value
of (up to 32) octets).
For comparison purposes, fields object,
value, and zone are case-insensitive. All
of these fields may contain any octet value
other than 255 (hex ff).
7 string IPX - in network byte order
octets 1..4: network-number;
octets 5..10: physical-address;
octets 11..12: socket-number."
SYNTAX SnmpUnion
Expires 11/27/96 [Page 14]
Draft Domestication of Opaque May 27, 1996
The following example shows usage of a union to define a textual
convention for the resulting value from running a script at a mid-level
manager.
ScriptResult TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The result from running a script
ID Syntax Description
1 none The result is not available yet
2 uint32 Error running the script, the values are:
1: syntax problem in script
2: no response from script target
3: invalid response from script target
3: out of resources
3 int32 Integer result
4 string String result
5 oid Object identifier result
6 uint32 Unsigned integer result
7 uint64 Big unsigned integer result
8 float Float result
9 double Double result"
SYNTAX SnmpUnion
Expires 11/27/96 [Page 15]
Draft Domestication of Opaque May 27, 1996
5.2.3. Example BER for SnmpUnion Values
Below is an object definition and a table showing the BER encoding of
values for the object. This table illustrates the encoding of each kind
of syntax allowed for a union member.
exmplUnionObj TEXTUAL-CONVENTION
SYNTAX SnmpUnion
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An example object that shows each type of
syntax allowed for members of a union:
ID Syntax Description
1 int32 Integer
2 string String result
3 oid Object identifier result
4 none
5 uint32 Unsigned integer result
6 uint64 Big unsigned integer result
7 opaque
8 float Float result
9 double Double result"
::= { exmpl 3 }
Member Example BER Serialization
ID Syntax Value SnmpUnion type
-- ------ ------- -----------------
1 int32 1 'bf2f06020101020101'h
BER of value of exmplUnionObj is '4409bf2f06020101020101'h
2 string "01" 'bf2f0702010204023031'h
BER of value of exmplUnionObj is '440abf2f0702010204023031'h
3 oid 1.3.6 'bf2f0702010306034306'h
BER of value of exmplUnionObj is '440abf2f0702010306034306'h
4 none - 'bf2f050201040500'h
BER of value of exmplUnionObj is '4408bf2f050201040500'h
5 unit32 56782 'bf2f08020105420300ddce'h
BER of value of exmplUnionObj is '440bbf2f08020105420300ddce'
6 unit64 56782 'bf2f08020106460300ddce'h
BER of value of exmplUnionObj is '440bbf2f08020106460300ddce'h
7 opaque '010100'h 'bf2f080201074403010100'h
BER of value of exmplUnionObj is '440bbf2f080201074403010100'h
8 float 123 'bf2f09020108480442f60000'h
BER of value of exmplUnionObj is '440cbf2f09020108480442f60000'h
9 double 123 'bf2f0d0201094908405ec00000000000'h
BER of value of exmplUnionObj is
'4410bf2f0d0201094908405ec00000000000'h
Expires 11/27/96 [Page 16]
Draft Domestication of Opaque May 27, 1996
6. Suggestions for Further Study
The SnmpUnion textual convention appears to be a powerful addition to
the usage of SNMP. However, there is currently no direct support for it
in the SMI. Thus, the identification, syntax, and description of the
members of a union can only be specified in the DESCRIPTION clause for
the object or textual convention where it is used. Inside a DESCRIPTION
clause, there is no enforcement of proper specification. A MIB compiler
cannot reliably parse the content of the a DESCRIPTION clause and make
that information available to its users, such as application programs.
For these reasons, it is suggested that further investigation begin for
adding a construct to the SMI to specify the characteristics of members
of a union. The construct should be well defined so that it is parsable
with a MB compiler.
7. Acknowledgments
Thanks go to Sandy M. Perkins for editorial assistance and review.
8. References
[1] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of
Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1902, 01/22/1996.
[2] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual
Conventions for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1903, 01/22/1996.
[3] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance
Statements for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1904, 01/22/1996.
Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1442, 05/03/1993.
[4] K. McCloghrie, M. Rose, "Structure and Identification of Managemen
Information for TCP/IP-based Internets", RFC 1155, 05/10/1990.
[5] K. McCloghrie, M. Rose, "Concise MIB Definitions", RFC 1212,
03/26/1991.
[6] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[7] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
Expires 11/27/96 [Page 17]
Draft Domestication of Opaque May 27, 1996
One (ASN.1), International Organization for Standardization.
International Standard 8825, (December, 1987).
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
Expires 11/27/96 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:43 |