Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-perkins-opaque-01.txt < prev next >

Wrap

Text File | 1997-06-13 | 39KB | 971 lines

INTERNET-DRAFT Expires December 1997 INTERNET-DRAFT Draft Domestication of Opaque June 7, 1997 The Domestication of the Opaque Type for SNMP <draft-perkins-opaque-01.txt> June 7, 1997 David T. Perkins dperkins@snmpinfo.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 12/07/97 [Page 1] Draft Domestication of Opaque June 7, 1997 2. Introduction This memo is informational. It specifies a clarification of the definition and use of the Opaque type defined in Simple Network Management Protocol (SNMP) Structure of Management Information (SMI). There are two versions of the SMI. The first, called SMIv1, is defined by RFCs 1155[1], 1212[2], and 1215[3]. The second, called SMIv2, is defined by RFCs 1902[4], 1903[5], and 1904[6]. 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 SMIv1 and SNMPv1; 2) support future types added to the SMI without changing the SNMP protocol; and 3) support for a discriminated union type. All of the solutions are accomplished without a change to the technical content of the specifications for the SNMPv1[7] and SNMPv2[8][9] protocols. This memo specifies a clarification for both version 1 and version 2 of the SNMP SMI, which is a standard for the Internet community. 3. Background The SMI defines the SNMP MIB module language, which is an augmented subset of the ASN.1 specification language[10]. The SNMP protocol is defined with a proper sub-set of ASN.1 notations and SNMP protocol messages are encoded using a proper sub-set of the Basic Encoding Rules (BER) for ASN.1[11]. The Opaque data type is defined in first version of the SMI for SNMP. The ASN.1 notation is found in section 6 of SMIv1[1] and is shown below: Opaque ::= [APPLICATION 4] IMPLICIT OCTET The Opaque data type is described in section 3.2.3.6 and is shown below: 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. Expires 12/07/97 [Page 2] Draft Domestication of Opaque June 7, 1997 Unfortunately, the last sentence in this description is not correct. This inaccuracy is fixed in the SMIv2[4], and the description for the Opaque data type from section 7.1.9 is shown below: 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. The description was made correct by eliminating the last sentence, which was incorrect and provided no additional useful information. The SNMPv2 WG added a policy statement in RFC 1902 restricting usage of the Opaque type. This restriction was 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 clarify the meaning of the Opaque data type; show how it uniquely (and at a low cost) solves several important problems; and replace the policy from RFC 1902 restricting usage 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 12/07/97 [Page 3] Draft Domestication of Opaque June 7, 1997 4. A Description of the Opaque Type The Opaque type is defined in ASN.1 notation as the following: -- The value for this data type must be the BER serialization -- of a valid ASN.1 value. Opaque ::= [APPLICATION 4] IMPLICIT OCTET This ASN.1 definition means that when values of the Opaque data type are used in SNMP messages, which are encoded using the basic encoding rules of ASN.1 (BER)[11], the result is the following: Serialization of a value, which is an SNMP Opaque data type ------------------------------------------------------ | | | value is serialized | | | | ------------------------------ | | tag | length | | V-tag | V-length | V-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 - V-tag, V-length, and V-value are the serialization of an ASN.1 value using BER serialization A common misinterpretation of the definition of the Opaque type is that values for it can be any string of octet values. This is incorrect, since the SMI clearly specifies that the value must be the BER serialization of a value for an ASN.1 type. The following table contains examples of BER serialization. The first column contains ASN.1 data type specifications. The second column contains a valid value of the ASN.1 data 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 data type. The fourth column contains the BER serialization of the value of data type Opaque in the same row. Expires 12/07/97 [Page 4] Draft Domestication of Opaque June 7, 1997 BER BER Serialization Serialization of Value as Data Type Value of Value Opaque Data 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 These examples clearly demonstrate that the valid values of data 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 Data Type There are two problems with the current definition of the Opaque type. First, there are no restrictions on the ASN.1 data types or values that can be "wrapped." Thus, values and ASN.1 data types, even those not allowed in SNMP, may be serialized. Secondly, usage of the Opaque data type does not require the ASN.1 data 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 data 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 data types to the SMI and protocol. (One example is 64-bit counters in SMI1 and SNMPv1.) The second problem is how to support a "union" data type that is needed in sophisticated environments such as mid-level managers. The taming of the current (and "wild") definition of the Opaque data 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 data type. The replacement definition of the Opaque data type for SMIv1 and SMIv2 is: Expires 12/07/97 [Page 5] Draft Domestication of Opaque June 7, 1997 The Opaque data 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 shall be able to encode and decode SNMP PDUs with the value portion of a variable-bind pair using this type. A conforming SNMP MIB module shall specify the ASN.1 type for the original values in the DESCRIPTION clause of the OBJECT-TYPE or TEXTUAL-CONVENTION constructs where the Opaque data type is used. Furthermore, standards track MIB modules are restricted in their use of the ASN.1 data types wrapped by the Opaque data 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 data type, the CHOICE data type, and specially created APPLICATION data types may be used. Note, that these may be also be qualified with an "IMPLICIT" context-specific tag. However, context-specific tags greater than or equal to 32 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 SMIv1 or in the SNMPv1 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 data type of object types, which is specified in the SYNTAX clause. Such a textual convention is an example domestication of the untamed Opaque data type. The value of the Opaque data type for the textual convention is restricted to a serialized value of a tagged version of the new data type. This approach allows only those SNMP managers or agents who need a new data 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 data type reserves ASN.1 context- specific tags greater than or equal to 32 for special use. One use of Expires 12/07/97 [Page 6] Draft Domestication of Opaque June 7, 1997 the reserved values is to use ASN.1 context-specific tags with values 48 and above 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 data 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(cls), primitive/constructed flag(f), 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 f is 0 - primitive 1 - constructed 5.1.1. 64-Bit Counters To support 64-bit counters in SMIv1 and SMIv2 MIB modules, and use the SNMPv1 and SNMPv2 protocols, the following textual convention must be used in SYNTAX clause instead of the data 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 Expires 12/07/97 [Page 7] Draft Domestication of Opaque June 7, 1997 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 tag is '9f76'h; the length is '03'h; and the value is '00ddce'h.) The BER serialization of value '9f760300ddce'h of data type Opaque is '44069f760300ddce'h. (The tag is '44'h; the length is '06'h; and the value is '9f760300ddce'h.)" SYNTAX Opaque (SIZE(4..12)) With the C64 textual convention, objects can be defined in both the SMIv1 and SMIv2 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 } Expires 12/07/97 [Page 8] Draft Domestication of Opaque June 7, 1997 -- 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 Data Types In the future, there may be a need for a limited number of additional data 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 data types. The domestication of the opaque data type allows new data 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 data type. The addition of new data types is serious business and may not proceed without careful review of the network management area. A new data type may not be defined to associate semantics with an existing data type. (Note that this requirement would not have allowed the Counter or Gauge data types to be created as basic data types. Instead, they would have been textual conventions of an unsigned integer data type.) A new data type may be an ASN.1 universal type or an application-specific type. For each new data type defined, a textual convention must also be defined to wrap the new data type in an Opaque data type. The following example shows the definition of two new data types. The first is an application-specific data type and the second is a universal data type. -- define a new data 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 data type New1 TEXTUAL-CONVENTION STATUS current DESCRIPTION "A new data type with some characteristics specified. The value is restricted to the BER serialization of the following ASN.1 data type: NEW1TYPE ::= [120] IMPLICIT New1Type (note: the value 120 is the sum of '30'h and '48'h) Expires 12/07/97 [Page 9] Draft Domestication of Opaque June 7, 1997 The BER serialization of the length for values of this data type must use the definite length, short encoding form. For example, the BER serialization of value '12345678'h of data type NEW1TYPE is '9f780412345678'h. (The tag is '9f78'h; the length is '04'h; and the value is '12345678'h.) The BER serialization of value '9f780412345678'h of data type Opaque is '44079f780412345678'h. (The tag is '44'h; the length is '07'h; and the value is '9f780412345678'h.)" SYNTAX Opaque (SIZE(7)) or -- define a new data type based on an existing ASN.1 universal -- data type (note: using BER, the tag for the data type is '03'h) New2Type ::= BIT STRING -- define a textual convention to wrap the new data type New2 TEXTUAL-CONVENTION STATUS current DESCRIPTION "A new data type with some characteristics specified. The value is restricted to the BER serialization of the following ASN.1 data type: 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 data 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 tag is '9f33'h; the length is '05'h; and the value is '0012345678'h.) The BER serialization of value '9f33050012345678'h of type data type Opaque is '44089f33050012345678'h. (The tag is '44'h; the length is '08'h; and the value is '9f33050012345678'h.)" SYNTAX Opaque (SIZE(4..65535)) 5.2. Support for Unions There is a need for a union data type that allows a value to be identified and that allows different value encodings based on the identification. This need was present when the first version of the SMI and the core IETF SNMP MIB were created. A union was needed to hold different types of network addresses. The solution that was created, the data type NetworkAddress, proved problematic and was not included in Expires 12/07/97 [Page 10] Draft Domestication of Opaque June 7, 1997 the second version of the SMI. However, the need for a union of network addresses still exists. Other needs also exist for unions. For example, researchers have created mid-level managers that allow running of scripts to compute values, and have the resulting value retrievable via SNMP. The data type of a computed value may be any of the data types allowed by the SMI such as integers, strings, and object identifiers. Without a union data type, however, a mid-level manager must define several objects, each with a different data 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 data type. 5.2.1. Definition of SnmpUnion The domestication of the Opaque data 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 data type follow: -- A discriminated union SnmpUnionType ::= [47] IMPLICIT SEQUENCE { memberId INTEGER (-2147483648.. 2147483647), memberType CHOICE { -- the first six data 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), opaqueVal [APPLICATION 4] IMPLICIT OCTET STRING (SIZE(2..65535)), -- the last four data types are additional special -- APPLICATION types floatVal -- the "single format" as defined in -- ANSI/IEEE Std 754-1985: IEEE Standard for -- Binary Floating Point[12][13] [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[12][13] [ APPLICATION 9] IMPLICIT OCTET STRING (SIZE(8)), int64Val [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808.. 9223372036854775807), Expires 12/07/97 [Page 11] Draft Domestication of Opaque June 7, 1997 uint64Val [APPLICATION 11] IMPLICIT INTEGER (0.. 18446744073709551615) }} -- The textual convention to wrap the SNMP union as an -- Opaque data 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 shall specify in their DESCRIPTION clause a list containing the following information: 1) discriminator value - identifies a member 2) data type for member - one of int32, int64, 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 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 data 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 tag is 'Bf2f'h; the length is '06'h; and the value is '020101020122'h. The value consists of items '020101'h and '020122'h. The first item has tag '02'h; length '01'h; and value '01'h. The second item has tag '02'h; length '01'h; and value '22'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 SMIv1 and SMIv2 formats and can be accessed via both SNMPv1 and SNMPv2 protocols. Shown below are definitions for the same object in both SMI formats: Expires 12/07/97 [Page 12] Draft Domestication of Opaque June 7, 1997 -- 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 } The following example shows 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 1906[9]: 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) Expires 12/07/97 [Page 13] Draft Domestication of Opaque June 7, 1997 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 The following example shows usage of a union to define a textual convention for the value that results 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 Signed integer result 4 int64 Big signed integer result 5 string String result 6 oid Object identifier result 7 uint32 Unsigned integer result 8 uint64 Big unsigned integer result 9 float Float result 10 double Double result" SYNTAX SnmpUnion Expires 12/07/97 [Page 14] Draft Domestication of Opaque June 7, 1997 5.2.3. Example BER for SnmpUnion Values Below is shown an object definition and a table containing 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 Signed integer 2 int64 Big signed integer 3 string String result 4 oid Object identifier result 5 none 6 uint32 Unsigned integer result 7 uint64 Big unsigned integer result 8 opaque 9 float Float result 10 double Double result" ::= { exmpl 3 } Member Example BER Serialization ID Syntax Value SnmpUnion data type -- ------ ------- ------------------- 1 int32 1 'bf2f06020101020101'h BER of object's value is '4409bf2f06020101020101'h 2 int64 1 'bf2f060201024a0101'h BER of object's value is '4409bf2f060201024a0101'h 3 string "01" 'bf2f0702010304023031'h BER of object's value is '440abf2f0702010304023031'h 4 oid 1.3.6 'bf2f0702010406034306'h BER of object's value is '440abf2f0702010406034306'h 5 none - 'bf2f050201050500'h BER of object's value is '4408bf2f050201050500'h 6 unit32 56782 'bf2f08020106420300ddce'h BER of object's value is '440bbf2f08020106420300ddce' Expires 12/07/97 [Page 15] Draft Domestication of Opaque June 7, 1997 7 unit64 56782 'bf2f080201074b0300ddce'h BER of object's value is '440bbf2f080201074b0300ddce'h 8 opaque '010100'h 'bf2f080201084403010100'h BER of object's value is '440bbf2f080201084403010100'h 9 float 123 'bf2f09020109480442f60000'h BER of object's value is '440cbf2f09020109480442f60000'h 10 double 123 'bf2f0d02010a4908405ec00000000000'h BER of object's value is '4410bf2f0d02010a4908405ec00000000000'h 6. Suggestions for Further Work The SnmpUnion textual convention is 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 a construct be added to a future version of the SMI to specify the characteristics of members of a union. The resulting addition should be well defined so that it is parsable with a MIB compiler. 7. Acknowledgments Thanks go to Sandy M. Perkins for editorial assistance and review. Expires 12/07/97 [Page 16] Draft Domestication of Opaque June 7, 1997 8. References [1] K. McCloghrie, M. Rose, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, 05/10/1990. [2] K. McCloghrie, M. Rose, "Concise MIB Definitions", RFC 1212, 03/26/1991. [3] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, 03/27/1991. [4] 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. [5] 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. [6] 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. [7] M. Schoffstall, M. Fedor, J. Davin, J. Case, "A Simple Network Management Protocol (SNMP)", RFC 1157, 05/10/1990. [8] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, 01/22/1996. [9] 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, 01/22/1996. [10] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [11] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [12] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985. [13] R. Srinivasan, "XDR: External Data Representation Standard", RFC 1832, 08/09/1995. Expires 12/07/97 [Page 17]