doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc1906.txt b/doc/rfc/rfc1906.txt
new file mode 100644
index 0000000..84fdd4f
--- /dev/null
+++ b/doc/rfc/rfc1906.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                               SNMPv2 Working Group
+Request for Comments: 1906                                       J. Case
+Obsoletes: 1449                                      SNMP Research, Inc.
+Category: Standards Track                                  K. McCloghrie
+                                                     Cisco Systems, Inc.
+                                                                 M. Rose
+                                            Dover Beach Consulting, Inc.
+                                                           S. Waldbusser
+                                          International Network Services
+                                                            January 1996
+
+
+                Transport Mappings for Version 2 of the
+              Simple Network Management Protocol (SNMPv2)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   1.1 A Note on Terminology ......................................    2
+   2. Definitions .................................................    3
+   3. SNMPv2 over UDP .............................................    5
+   3.1 Serialization ..............................................    5
+   3.2 Well-known Values ..........................................    5
+   4. SNMPv2 over OSI .............................................    6
+   4.1 Serialization ..............................................    6
+   4.2 Well-known Values ..........................................    6
+   5. SNMPv2 over DDP .............................................    6
+   5.1 Serialization ..............................................    6
+   5.2 Well-known Values ..........................................    6
+   5.3 Discussion of AppleTalk Addressing .........................    7
+   5.3.1 How to Acquire NBP names .................................    8
+   5.3.2 When to Turn NBP names into DDP addresses ................    8
+   5.3.3 How to Turn NBP names into DDP addresses .................    8
+   5.3.4 What if NBP is broken ....................................    9
+   6. SNMPv2 over IPX .............................................    9
+   6.1 Serialization ..............................................    9
+   6.2 Well-known Values ..........................................    9
+   7. Proxy to SNMPv1 .............................................   10
+   8. Serialization using the Basic Encoding Rules ................   10
+   8.1 Usage Example ..............................................   11
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 1]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+   9. Security Considerations .....................................   11
+   10. Editor's Address ...........................................   12
+   11. Acknowledgements ...........................................   12
+   12. References .................................................   13
+
+1.  Introduction
+
+   A management system contains:  several (potentially many) nodes, each
+   with a processing entity, termed an agent, which has access to
+   management instrumentation; at least one management station; and, a
+   management protocol, used to convey management information between
+   the agents and management stations.  Operations of the protocol are
+   carried out under an administrative framework which defines
+   authentication, authorization, access control, and privacy policies.
+
+   Management stations execute management applications which monitor and
+   control managed elements.  Managed elements are devices such as
+   hosts, routers, terminal servers, etc., which are monitored and
+   controlled via access to their management information.
+
+   The management protocol, version 2 of the Simple Network Management
+   Protocol [1], may be used over a variety of protocol suites.  It is
+   the purpose of this document to define how the SNMPv2 maps onto an
+   initial set of transport domains.  Other mappings may be defined in
+   the future.
+
+   Although several mappings are defined, the mapping onto UDP is the
+   preferred mapping.  As such, to provide for the greatest level of
+   interoperability, systems which choose to deploy other mappings
+   should also provide for proxy service to the UDP mapping.
+
+1.1.  A Note on Terminology
+
+   For the purpose of exposition, the original Internet-standard Network
+   Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
+   15), and 1212 (STD 16), is termed the SNMP version 1 framework
+   (SNMPv1).  The current framework is termed the SNMP version 2
+   framework (SNMPv2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 2]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+2.  Definitions
+
+SNMPv2-TM DEFINITIONS ::= BEGIN
+
+IMPORTS
+    OBJECT-IDENTITY, snmpDomains, snmpProxys
+        FROM SNMPv2-SMI
+    TEXTUAL-CONVENTION
+        FROM SNMPv2-TC;
+
+-- SNMPv2 over UDP over IPv4
+
+snmpUDPDomain  OBJECT-IDENTITY
+    STATUS     current
+    DESCRIPTION
+            "The SNMPv2 over UDP transport domain.  The corresponding
+            transport address is of type SnmpUDPAddress."
+    ::= { snmpDomains 1 }
+
+SnmpUDPAddress ::= TEXTUAL-CONVENTION
+    DISPLAY-HINT "1d.1d.1d.1d/2d"
+    STATUS       current
+    DESCRIPTION
+            "Represents a UDP address:
+
+               octets   contents        encoding
+                1-4     IP-address      network-byte order
+                5-6     UDP-port        network-byte order
+            "
+    SYNTAX       OCTET STRING (SIZE (6))
+
+
+-- SNMPv2 over OSI
+
+snmpCLNSDomain OBJECT-IDENTITY
+    STATUS     current
+    DESCRIPTION
+            "The SNMPv2 over CLNS transport domain.  The corresponding
+            transport address is of type SnmpOSIAddress."
+    ::= { snmpDomains 2 }
+
+snmpCONSDomain OBJECT-IDENTITY
+    STATUS     current
+    DESCRIPTION
+            "The SNMPv2 over CONS transport domain.  The corresponding
+            transport address is of type SnmpOSIAddress."
+    ::= { snmpDomains 3 }
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 3]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+SnmpOSIAddress ::= TEXTUAL-CONVENTION
+    DISPLAY-HINT "*1x:/1x:"
+    STATUS       current
+    DESCRIPTION
+            "Represents an OSI transport-address:
+
+               octets   contents           encoding
+                  1     length of NSAP     'n' as an unsigned-integer
+                                              (either 0 or from 3 to 20)
+               2..(n+1) NSAP                concrete binary representation
+               (n+2)..m TSEL                string of (up to 64) octets
+            "
+    SYNTAX       OCTET STRING (SIZE (1 | 4..85))
+
+
+-- SNMPv2 over DDP
+
+snmpDDPDomain  OBJECT-IDENTITY
+    STATUS     current
+    DESCRIPTION
+            "The SNMPv2 over DDP transport domain.  The corresponding
+            transport address is of type SnmpNBPAddress."
+    ::= { snmpDomains 4 }
+
+SnmpNBPAddress ::= TEXTUAL-CONVENTION
+    STATUS       current
+    DESCRIPTION
+            "Represents an NBP name:
+
+                 octets        contents          encoding
+                    1          length of object  'n' as an unsigned integer
+                  2..(n+1)     object            string of (up to 32) octets
+                   n+2         length of type    'p' as an unsigned integer
+              (n+3)..(n+2+p)   type              string of (up to 32) octets
+                  n+3+p        length of zone    'q' as an unsigned integer
+            (n+4+p)..(n+3+p+q) zone              string of (up to 32) octets
+
+            For comparison purposes, strings are case-insensitive All
+            strings may contain any octet other than 255 (hex ff)."
+    SYNTAX       OCTET STRING (SIZE (3..99))
+
+
+-- SNMPv2 over IPX
+
+snmpIPXDomain  OBJECT-IDENTITY
+    STATUS     current
+    DESCRIPTION
+            "The SNMPv2 over IPX transport domain.  The corresponding
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 4]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+            transport address is of type SnmpIPXAddress."
+    ::= { snmpDomains 5 }
+
+SnmpIPXAddress ::= TEXTUAL-CONVENTION
+    DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
+    STATUS       current
+    DESCRIPTION
+            "Represents an IPX address:
+
+               octets   contents            encoding
+                1-4     network-number      network-byte order
+                5-10    physical-address    network-byte order
+               11-12    socket-number       network-byte order
+            "
+    SYNTAX       OCTET STRING (SIZE (12))
+
+
+-- for proxy to SNMPv1 (RFC 1157)
+
+rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }
+
+rfc1157Domain  OBJECT-IDENTITY
+    STATUS     current
+    DESCRIPTION
+            "The transport domain for SNMPv1 over UDP.  The
+            corresponding transport address is of type SnmpUDPAddress."
+    ::= { rfc1157Proxy 1 }
+
+--  ::= { rfc1157Proxy 2 }            this OID is obsolete
+
+
+END
+
+3.  SNMPv2 over UDP
+
+   This is the preferred transport mapping.
+
+3.1.  Serialization
+
+   Each instance of a message is serialized (i.e., encoded according to
+   the convention of [1]) onto a single UDP[2] datagram, using the
+   algorithm specified in Section 8.
+
+3.2.  Well-known Values
+
+   It is suggested that administrators configure their SNMPv2 entities
+   acting in an agent role to listen on UDP port 161.  Further, it is
+   suggested that notification sinks be configured to listen on UDP port
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 5]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+   162.
+
+   When an SNMPv2 entity uses this transport mapping, it must be capable
+   of accepting messages that are at least 484 octets in size.
+   Implementation of larger values is encouraged whenever possible.
+
+4.  SNMPv2 over OSI
+
+   This is an optional transport mapping.
+
+4.1.  Serialization
+
+   Each instance of a message is serialized onto a single TSDU [3,4] for
+   the OSI Connectionless-mode Transport Service (CLTS), using the
+   algorithm specified in Section 8.
+
+4.2.  Well-known Values
+
+   It is suggested that administrators configure their SNMPv2 entities
+   acting in an agent role to listen on transport selector "snmp-l"
+   (which consists of six ASCII characters), when using a CL-mode
+   network service to realize the CLTS.  Further, it is suggested that
+   notification sinks be configured to listen on transport selector
+   "snmpt-l" (which consists of seven ASCII characters, six letters and
+   a hyphen) when using a CL-mode network service to realize the CLTS.
+   Similarly, when using a CO-mode network service to realize the CLTS,
+   the suggested transport selectors are "snmp-o" and "snmpt-o", for
+   agent and notification sink, respectively.
+
+   When an SNMPv2 entity uses this transport mapping, it must be capable
+   of accepting messages that are at least 484 octets in size.
+   Implementation of larger values is encouraged whenever possible.
+
+5.  SNMPv2 over DDP
+
+   This is an optional transport mapping.
+
+5.1.  Serialization
+
+   Each instance of a message is serialized onto a single DDP datagram
+   [5], using the algorithm specified in Section 8.
+
+5.2.  Well-known Values
+
+   SNMPv2 messages are sent using DDP protocol type 8.  SNMPv2 entities
+   acting in an agent role listens on DDP socket number 8, whilst
+   notification sinks listen on DDP socket number 9.
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 6]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+   Administrators must configure their SNMPv2 entities acting in an
+   agent role to use NBP type "SNMP Agent" (which consists of ten ASCII
+   characters), whilst notification sinks must be configured to use NBP
+   type "SNMP Trap Handler" (which consists of seventeen ASCII
+   characters).
+
+   The NBP name for agents and notification sinks should be stable - NBP
+   names should not change any more often than the IP address of a
+   typical TCP/IP node.  It is suggested that the NBP name be stored in
+   some form of stable storage.
+
+   When an SNMPv2 entity uses this transport mapping, it must be capable
+   of accepting messages that are at least 484 octets in size.
+   Implementation of larger values is encouraged whenever possible.
+
+5.3.  Discussion of AppleTalk Addressing
+
+   The AppleTalk protocol suite has certain features not manifest in the
+   TCP/IP suite.  AppleTalk's naming strategy and the dynamic nature of
+   address assignment can cause problems for SNMPv2 entities that wish
+   to manage AppleTalk networks.  TCP/IP nodes have an associated IP
+   address which distinguishes each from the other.  In contrast,
+   AppleTalk nodes generally have no such characteristic.  The network-
+   level address, while often relatively stable, can change at every
+   reboot (or more frequently).
+
+   Thus, when SNMPv2 is mapped over DDP, nodes are identified by a
+   "name", rather than by an "address".  Hence, all AppleTalk nodes that
+   implement this mapping are required to respond to NBP lookups and
+   confirms (e.g., implement the NBP protocol stub), which guarantees
+   that a mapping from NBP name to DDP address will be possible.
+
+   In determining the SNMP identity to register for an SNMPv2 entity, it
+   is suggested that the SNMP identity be a name which is associated
+   with other network services offered by the machine.
+
+   NBP lookups, which are used to map NBP names into DDP addresses, can
+   cause large amounts of network traffic as well as consume CPU
+   resources.  It is also the case that the ability to perform an NBP
+   lookup is sensitive to certain network disruptions (such as zone
+   table inconsistencies) which would not prevent direct AppleTalk
+   communications between two SNMPv2 entities.
+
+   Thus, it is recommended that NBP lookups be used infrequently,
+   primarily to create a cache of name-to-address mappings.  These
+   cached mappings should then be used for any further SNMP traffic.  It
+   is recommended that SNMPv2 entities acting in a manager role should
+   maintain this cache between reboots.  This caching can help minimize
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 7]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+   network traffic, reduce CPU load on the network, and allow for (some
+   amount of) network trouble shooting when the basic name-to-address
+   translation mechanism is broken.
+
+5.3.1.  How to Acquire NBP names
+
+   An SNMPv2 entity acting in a manager role may have a pre-configured
+   list of names of "known" SNMPv2 entities acting in an agent role.
+   Similarly, an SNMPv2 entity acting in a manager role might interact
+   with an operator.  Finally, an SNMPv2 entity acting in a manager role
+   might communicate with all SNMPv2 entities acting in an agent role in
+   a set of zones or networks.
+
+5.3.2.  When to Turn NBP names into DDP addresses
+
+   When an SNMPv2 entity uses a cache entry to address an SNMP packet,
+   it should attempt to confirm the validity mapping, if the mapping
+   hasn't been confirmed within the last T1 seconds.  This cache entry
+   lifetime, T1, has a minimum, default value of 60 seconds, and should
+   be configurable.
+
+   An SNMPv2 entity acting in a manager role may decide to prime its
+   cache of names prior to actually communicating with another SNMPv2
+   entity.  In general, it is expected that such an entity may want to
+   keep certain mappings "more current" than other mappings, e.g., those
+   nodes which represent the network infrastructure (e.g., routers) may
+   be deemed "more important".
+
+   Note that an SNMPv2 entity acting in a manager role should not prime
+   its entire cache upon initialization - rather, it should attempt
+   resolutions over an extended period of time (perhaps in some pre-
+   determined or configured priority order).  Each of these resolutions
+   might, in fact, be a wildcard lookup in a given zone.
+
+   An SNMPv2 entity acting in an agent role must never prime its cache.
+   Such an entity should do NBP lookups (or confirms) only when it needs
+   to send an SNMP trap.  When generating a response, such an entity
+   does not need to confirm a cache entry.
+
+5.3.3.  How to Turn NBP names into DDP addresses
+
+   If the only piece of information available is the NBP name, then an
+   NBP lookup should be performed to turn that name into a DDP address.
+   However, if there is a piece of stale information, it can be used as
+   a hint to perform an NBP confirm (which sends a unicast to the
+   network address which is presumed to be the target of the name
+   lookup) to see if the stale information is, in fact, still valid.
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 8]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+   An NBP name to DDP address mapping can also be confirmed implicitly
+   using only SNMP transactions.  For example, an SNMPv2 entity acting
+   in a manager role issuing a retrieval operation could also retrieve
+   the relevant objects from the NBP group [6] for the SNMPv2 entity
+   acting in an agent role.  This information can then be correlated
+   with the source DDP address of the response.
+
+5.3.4.  What if NBP is broken
+
+   Under some circumstances, there may be connectivity between two
+   SNMPv2 entities, but the NBP mapping machinery may be broken, e.g.,
+
+o    the NBP FwdReq (forward NBP lookup onto local attached network)
+     mechanism might be broken at a router on the other entity's
+     network; or,
+
+o    the NBP BrRq (NBP broadcast request) mechanism might be broken
+     at a router on the entity's own network; or,
+
+o    NBP might be broken on the other entity's node.
+
+   An SNMPv2 entity acting in a manager role which is dedicated to
+   AppleTalk management might choose to alleviate some of these failures
+   by directly implementing the router portion of NBP.  For example,
+   such an entity might already know all the zones on the AppleTalk
+   internet and the networks on which each zone appears.  Given an NBP
+   lookup which fails, the entity could send an NBP FwdReq to the
+   network in which the agent was last located.  If that failed, the
+   station could then send an NBP LkUp (NBP lookup packet) as a directed
+   (DDP) multicast to each network number on that network.  Of the above
+   (single) failures, this combined approach will solve the case where
+   either the local router's BrRq-to-FwdReq mechanism is broken or the
+   remote router's FwdReq-to-LkUp mechanism is broken.
+
+6.  SNMPv2 over IPX
+
+   This is an optional transport mapping.
+
+6.1.  Serialization
+
+   Each instance of a message is serialized onto a single IPX datagram
+   [7], using the algorithm specified in Section 8.
+
+6.2.  Well-known Values
+
+   SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
+   Exchange Protocol).
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 9]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+   It is suggested that administrators configure their SNMPv2 entities
+   acting in an agent role to listen on IPX socket 36879 (900f
+   hexadecimal).  Further, it is suggested that notification sinks be
+   configured to listen on IPX socket 36880 (9010 hexadecimal)
+
+   When an SNMPv2 entity uses this transport mapping, it must be capable
+   of accepting messages that are at least 546 octets in size.
+   Implementation of larger values is encouraged whenever possible.
+
+7.  Proxy to SNMPv1
+
+   In order to provide proxy to SNMPv1 [8], it may be useful to define a
+   transport domain, rfc1157Domain, which indicates the transport
+   mapping for SNMP messages as defined in RFC 1157.  Section 3.1 of [9]
+   specifies the behavior of the proxy agent.
+
+8.  Serialization using the Basic Encoding Rules
+
+   When the Basic Encoding Rules [10] are used for serialization:
+
+   (1)  When encoding the length field, only the definite form is used; use
+        of the indefinite form encoding is prohibited.  Note that when
+        using the definite-long form, it is permissible to use more than
+        the minimum number of length octets necessary to encode the length
+        field.
+
+   (2)  When encoding the value field, the primitive form shall be used for
+        all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
+        IDENTIFIER (either IMPLICIT or explicit).  The constructed form of
+        encoding shall be used only for structured types, i.e., a SEQUENCE
+        or an IMPLICIT SEQUENCE.
+
+   (3)  When encoding an object whose syntax is described using the BITS
+        construct, the value is encoded as an OCTET STRING, in which all
+        the named bits in (the definition of) the bitstring, commencing
+        with the first bit and proceeding to the last bit, are placed in
+        bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
+        subsequent octet in turn, followed by as many bits as are needed of
+        the final subsequent octet, commencing with bit 8.  Remaining bits,
+        if any, of the final octet are set to zero on generation and
+        ignored on receipt.
+
+   These restrictions apply to all aspects of ASN.1 encoding, including
+   the message wrappers, protocol data units, and the data objects they
+   contain.
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 10]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+8.1.  Usage Example
+
+   As an example of applying the Basic Encoding Rules, suppose one
+   wanted to encode an instance of the GetBulkRequest-PDU [1]:
+
+     [5] IMPLICIT SEQUENCE {
+             request-id      1414684022,
+             non-repeaters   1,
+             max-repetitions 2,
+             variable-bindings {
+                 { name sysUpTime,
+                   value { unspecified NULL } },
+                 { name ipNetToMediaPhysAddress,
+                   value { unspecified NULL } },
+                 { name ipNetToMediaType,
+                   value { unspecified NULL } }
+             }
+         }
+
+Applying the BER, this would be encoded (in hexadecimal) as:
+
+[5] IMPLICIT SEQUENCE          a5 82 00 39
+    INTEGER                    02 04 52 54 5d 76
+    INTEGER                    02 01 01
+    INTEGER                    02 01 02
+    SEQUENCE                   30 2b
+        SEQUENCE               30 0b
+            OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
+            NULL               05 00
+        SEQUENCE               30 0d
+            OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
+            NULL               05 00
+        SEQUENCE               30 0d
+            OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04
+            NULL               05 00
+
+   Note that the initial SEQUENCE is not encoded using the minimum
+   number of length octets.  (The first octet of the length, 82,
+   indicates that the length of the content is encoded in the next two
+   octets.)
+
+9.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 11]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+10.  Editor's Address
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   US
+
+   Phone: +1 408 526 5260
+   EMail: kzm@cisco.com
+
+11.  Acknowledgements
+
+   This document is the result of significant work by the four major
+   contributors:
+
+   Jeffrey D. Case (SNMP Research, case@snmp.com)
+   Keith McCloghrie (Cisco Systems, kzm@cisco.com)
+   Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
+   Steven Waldbusser (International Network Services, stevew@uni.ins.com)
+
+   In addition, the contributions of the SNMPv2 Working Group are
+   acknowledged.  In particular, a special thanks is extended for the
+   contributions of:
+
+     Alexander I. Alten (Novell)
+     Dave Arneson (Cabletron)
+     Uri Blumenthal (IBM)
+     Doug Book (Chipcom)
+     Kim Curran (Bell-Northern Research)
+     Jim Galvin (Trusted Information Systems)
+     Maria Greene (Ascom Timeplex)
+     Iain Hanson (Digital)
+     Dave Harrington (Cabletron)
+     Nguyen Hien (IBM)
+     Jeff Johnson (Cisco Systems)
+     Michael Kornegay (Object Quest)
+     Deirdre Kostick (AT&T Bell Labs)
+     David Levi (SNMP Research)
+     Daniel Mahoney (Cabletron)
+     Bob Natale (ACE*COMM)
+     Brian O'Keefe (Hewlett Packard)
+     Andrew Pearson (SNMP Research)
+     Dave Perkins (Peer Networks)
+     Randy Presuhn (Peer Networks)
+     Aleksey Romanov (Quality Quorum)
+     Shawn Routhier (Epilogue)
+     Jon Saperia (BGS Systems)
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 12]
+
+RFC 1906             Transport Mappings for SNMPv2          January 1996
+
+
+     Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
+     Kaj Tesink (Bellcore)
+     Glenn Waters (Bell-Northern Research)
+     Bert Wijnen (IBM)
+
+12.  References
+
+[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+[2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+     USC/Information Sciences Institute, August 1980.
+
+[3]  Information processing systems - Open Systems Interconnection -
+     Transport Service Definition, International Organization for
+     Standardization.  International Standard 8072, (June, 1986).
+
+[4]  Information processing systems - Open Systems Interconnection -
+     Transport Service Definition - Addendum 1: Connectionless-mode
+     Transmission, International Organization for Standardization.
+     International Standard 8072/AD 1, (December, 1986).
+
+[5]  G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
+     edition).  Addison-Wesley, 1990.
+
+[6]  Waldbusser, S., "AppleTalk Management Information Base", RFC 1243,
+     Carnegie Mellon University, July 1991.
+
+[7]  Network System Technical Interface Overview.  Novell, Inc, (June,
+     1989).
+
+[8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
+     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
+     Systems International, MIT Laboratory for Computer Science, May
+     1990.
+
+[9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
+     Internet-standard Network Management Framework", RFC 1908,
+     January 1996.
+
+[10] 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.
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 13]
+