INTERNET-DRAFT Expires November 1996 INTERNET-DRAFT Draft Domestication of Opaque May 27, 1996 The Domestication of the Opaque Type for SNMPv1 and SNMPv2 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]