INTERNET-DRAFT                                                  Rob Frye
                                                MCI Communications Corp.
                                                           David B. Levi
                                                     SNMP Research, Inc.
                                                       Shawn A. Routhier
                                                 Integrated Systems Inc.
                                                             Bert Wijnen
                                                IBM T.J. Watson Research
        Coexistence between Version 1, Version 2, and Version 3
         of the Internet-standard Network Management Framework
                    <draft-ietf-snmpv3-coex-00.txt>
                    <draft-ietf-snmpv3-coex-01.txt>

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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``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 ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Copyright Notice

   Copyright (C) The Internet Society (date). All Rights Reserved.

Abstract

   The purpose of this document is to describe coexistence between
   version 3 of the Internet-standard Network Management Framework
   [RFC2271], termed the SNMP version 3 framework Framework,
   (SNMPv3), version 2 of the Internet-standard Network Management
   Framework [RFC1901], termed
   the SNMP version 2 framework (SNMPv2), and the original Internet-
   standard Internet-standard Network
   Management Framework (SNMPv1) [RFC1157]. (SNMPv1).  This document obsoletes RFC 1908 [13]
   and RFC2089 [14].

   Table Of Contents

   1 Overview .....................................................    4
   1.1 SNMPv1 .....................................................    4
   1.2 SNMPv2 .....................................................    5
   1.3 SNMPv3 .....................................................    5    6
   1.4 SNMPv1 and SNMPv2 MIB Instrumentation ......................    6
   2 SMI and Management Information Mappings ......................    7    8
   2.1 Object Definitions .........................................    7    8
   2.2 Trap and Notification Definitions ...........................................    9 ..........................   10
   2.3 Compliance Statements ......................................   10   11
   2.4 Capabilities Statements ....................................   10   11
   3 SNMPv1 and SNMPv2 MIB Instrumentation ........................   12
   4 Translating Notifications Between SNMP Formats ............... Parameters .........................   13
   4.1
   3.1 Translating SNMPv1 Format Notification Parameters to SNMPv2 Format .................  No-
        tification Parameters .....................................   14
   4.2
   3.2 Translating SNMPv2 Format Notification Parameters to SNMPv1 Format .................  No-
        tification Parameters .....................................   15
   4.3 Notification Translation Failure ...........................   16
   4.3.1 discussion about additional varbinds (agent_addr,  com-
        munity) ...................................................   17
   5
   4 Approaches to Coexistence in a Multi-lingual Network .........   18
   5.1
   4.1 Multi-lingual implementations ..............................   18
   5.1.1
   4.1.1 Command Generator ........................................   18
   5.1.2
   4.1.2 Command Responder ........................................   18
   5.1.3 Notification Originator ..................................   19
   5.1.4 Notification Receiver ....................................   19
   5.2 Proxy Implementations ......................................
   4.1.2.1 Handling Counter64 .....................................   19
   6 Multi-Lingual Command Responder Behaviour ....................   21
   6.1 Mapping SMIv2 into SMIv1 ...................................   21
   6.2
   4.1.2.2 Mapping SNMPv2 Exceptions ..................................   21
   6.2.1 ..............................   20
   4.1.2.2.1 Mapping nosuchObject and noSuchInstance ..................   22
   6.2.2 ..............   20
   4.1.2.2.2 Mapping endOfMibView .....................................   22
   6.3 .................................   21
   4.1.2.3 Processing An SNMPv1 GetRequest ............................   23
   6.4 ........................   21
   4.1.2.4 Processing An SNMPv1 GetNextRequest ........................ ....................   22
   4.1.3 Notification Originator ..................................   23
   4.1.4 Notification Receiver ....................................   24
   7
   4.2 Proxy Implementations ......................................   24
   4.3 Error Status Mappings ........................................ ......................................   26
   8
   5 Message Processing Models and Security Models ................   27
   8.1
   5.1 Mappings ...................................................   27
   8.2 Elements Of Procedure ......................................
   5.2 The SNMPv1 Message Processing Model ........................   27
   8.2.1
   5.2.1 Processing An Incoming Request ...........................   28
   8.2.2 Processing
   5.2.2 Generating An Outgoing Response ..........................   28
   8.2.3 Processing An Incoming Notification ......................   28
   8.2.4 Processing   30
   5.2.3 Generating An Outgoing Notification ......................   28
   8.3   30
   5.3 The SNMP Community MIB ..............................................   28
   9 Module ..............................   31
   6 Intellectual Property ........................................   35
   10   40
   7 Acknowledgments .............................................   36
   11 ..............................................   41
   8 Security Considerations .....................................   38
   12 ......................................   42
   9 References ..................................................   39
   13 ...................................................   43
   10 Editor's Address ............................................   41   45
   A. Full Copyright Statement ....................................   42   46

1.  Overview

   The purpose of this document is to describe coexistence between
   version 3 of the Internet-standard Network Management Framework
   [RFC2271], Framework,
   termed the SNMP version 3 framework (SNMPv3), version 2 of the
   Internet-standard Network Management Framework [RFC1901], Framework, termed the SNMP
   version 2 framework (SNMPv2), and the original Internet-
   standard Internet-standard
   Network Management Framework (SNMPv1) [RFC1157]. (SNMPv1).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [15].

   There are five four general aspects of coexistence described in this
   document.  Each of these is described in a separate section:

       -  Conversion of MIB documents between SMIv1 and SMIv2 formats is
          documented in section 2.

       -  Mapping of notifications between SMIv1 and SMIv2 formats notification parameters is documented in section 4. 3.

       -  Approaches to coexistence between SNMPv1, SNMPv2, and SNMPv3 entities which support the
          various versions of SNMP in a multi-lingual network is
          documented in section
          5.

       -  Processing 4.  This section addresses the
          processing of protocol operations in multi-lingual
          implementations is documented in section 6.
          implementations, as well as behaviour of proxy
          implementations.

       -  The SNMPv1 Message Processing Model and Community-Based
          Security Model, which provides mechanisms for adapting SNMPv1 and SNMPv2
          into the SNMPv3 view-based
          access control, View-Based Access Control Model (VACM) [20], is
          documented in section 8. 5 (this section also addresses the
          SNMPv2c Message Processing Model and Community-Based Security
          Model).

1.1.  SNMPv1

   SNMPv1 is defined by these three documents:

       -  STD 16, RFC 1155 [RFC1155] [1] which defines the Structure of Management
          Information (SMI), (SMIv1), the mechanisms used for describing and
          naming objects for the purpose of management.

       -  STD 16, RFC 1212 [RFC1212] [3] which defines a more concise description
          mechanism, which is wholly consistent with the
          SMI. SMIv1.

       -  STD 15, RFC 1157 [RFC1157] [2] which defines the Simple Network
          Management Protocol (SNMP), (SNMPv1), the protocol used for network
          access to managed objects.

       -  (NOTE: Rob had suggested adding rfcs 1213, 2011, 2012, 2013,
          1215.  Which, if any, of these should we add?)  RFC 1215 [4] which defines a convention for defining Traps for
          use with the SMIv1.

   Note that throughout this document, the term 'SMIv1' is used.  This
   term generally refers to the information presented in RFC 1155, RFC
   1212, and RFC 1215.

1.2.  SNMPv2

   SNMPv2 is defined by these six documents:

       -  RFC 1902 which defines Version 2 of the Structure of
          Management Information (SMI) [RFC1902]. (SMIv2) [7].

       -  RFC 1903 which defines common MIB "Textual Conventions"
          [RFC1903]. [8].

       -  RFC 1904 which defines Conformance Statements and requirements
          for defining agent and manager capabilities [RFC1904]. [9].

       -  RFC 1905 which defines the Protocol Operations used in
          processing [RFC1905]. [10].

       -  RFC 1906 which defines the Transport Mappings used "on the
          wire" [RFC1906]. [11].

       -  RFC 1907 which defines the basic Management Information Base
          upon which other MIBs can be built [RFC1907].

   In addition, [12].

   Note that SMIv2 as used throughout this document refers to the following first
   three documents augment listed above (RFCs 1902, 1903, and 1904).

   The following document augments the definition of SNMPv2:

       -  RFC 1901 [6] is an Experimental definition for using SNMPv2 format
          PDUs within a community-based message format. wrapper.  This is
          referred to throughout this document as SNMPv2c [RFC1901].

       -  RFC 2011 defines the IP MIB using SMIv2. SNMPv2c.

1.3.  SNMPv3

   SNMPv3 is defined by the these five documents:

       -  RFC 2271 which defines the v3 an Architecture for Describing SNMP
          Management Frameworks [RFC2271]. [16].

       -  RFC 2272 which defines Message Processing and Dispatching
          [RFC2272].
          [17].

       -  RFC 2273 which defines various SNMPv3 SNMP Applications [RFC2273]. [18].

       -  RFC 2274 which defines the User-based Security Model (USM),
          providing for both Authenticated and Private (encrypted) SNMP
          transactions [RFC2274].
          messages [19].

       -  RFC 2275 which defines the View-based Access Control Model
          (VACM), providing the ability to limit access to different MIB
          objects on a per-user basis [RFC2275]. [20].

   SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907
   described above.

1.4.  SNMPv1 and SNMPv2 MIB Instrumentation

   In several places, this document refers to 'SNMPv1 MIB
   Instrumentation' and 'SNMPv2 MIB Instrumentation'.  These terms refer
   to the part of an SNMP agent which actually implements MIB objects,
   and which actually initiates generation of notifications.
   Differences between the two types of MIB instrumentation are:

       -  Error-status values generated.

       -  Generation of exception codes.

       -  Use of the Counter64 data type.

       -  The format of parameters provided when a notification is
          generated.

   SNMPv1 MIB instrumentation will generate SNMPv1 error-status values,
   will never generate exception codes nor use the Counter64 data type,
   and will provide SNMPv1 format parameters for generating
   notifications.  Note also that SNMPv1 MIB instrumentation will
   actually never generate a readOnly error (a noSuchName error would
   always occur in the situation where one would expect a readOnly
   error).

   SNMPv2 MIB instrumentation will generate SNMPv2 error-status values,
   will generate exception codes, will use the Counter64 data type, and
   will provide SNMPv2 format parameters for generating notifications.
   Note that SNMPv2 MIB instrumentation will never generate readOnly,
   noSuchName, or badValue errors.

   Note that a particular multi-lingual implementation may choose to
   implement all MIB instrumentation as SNMPv2 MIB instrumentation.

2.  SMI and Management Information Mappings

   The SNMPv2 SMIv2 approach towards describing collections of managed objects
   is nearly a proper superset of the approach defined in the Internet-
   standard SNMPv1 Network Management Framework. SMIv1.
   For example, both approaches use ASN.1 [10] an adapted subset of ASN.1 (1988)
   [11] as the basis for a formal descriptive notation.  Indeed, one
   might note that the SNMPv2 SMIv2 approach largely codifies the existing
   practice for defining MIB modules, based on extensive experience with
   the SNMPv1 framework. SMIv1.

   The following sections consider the three areas:  MIB modules,
   compliance statements, and capabilities statements.

   MIB modules defined using the SNMPv1 framework SMIv1 may continue to be used with the
   protocol versions which use SNMPv2 protocol. PDUs.  However, for the MIB
   modules to conform to the SNMPv2 framework, SMIv2, the following changes are required: SHALL be made:

2.1.  Object Definitions

   In general, conversion of a MIB module does not require the
   deprecation of the objects contained therein.  Only if  If the semantics of an
   object truly changes should deprecation changes, the object SHALL be performed. deprecated, otherwise
   deprecation is not required.

(1)  The IMPORTS statement must MUST reference SNMPv2-SMI, instead of
     RFC1155-SMI and RFC-1212.

(2)  The MODULE-IDENTITY macro must MUST be invoked immediately after any
     IMPORTs statement.

(3)  For any descriptor which contains the hyphen character, the hyphen
     character is removed.

(4)  For any label for a named-number enumeration which contains the
     hyphen character, the hyphen character is removed.

(5)  For any object with an integer-valued SYNTAX clause, in which the
     corresponding INTEGER does not have a range restriction (i.e., the
     INTEGER has neither a defined set of named-number enumerations nor
     an assignment of lower- and upper-bounds on its value), the object
     must
     MUST have the value of its SYNTAX clause changed to Integer32.

(6)  For any object with a SYNTAX clause value of an enumerated INTEGER,
     the hyphen character is removed from any named-number labels which
     contain the hyphen character.

(7)

(4)  For any object with a SYNTAX clause value of Counter, the object
     must
     MUST have the value of its SYNTAX clause changed to Counter32.

(8)

(5)  For any object with a SYNTAX clause value of Gauge, the object must MUST
     have the value of its SYNTAX clause changed to Gauge32.

(9)

(6)  For all objects, the ACCESS clause must MUST be replaced by a MAX-ACCESS
     clause.  The value of the MAX-ACCESS clause is SHALL be the same as
     that of the ACCESS clause unless some other value makes "protocol
     sense" as the maximal level of access for the object.  In
     particular, object types for which instances can be explicitly
     created by a protocol set operation, will SHALL have a MAX-ACCESS clause
     of "read-create".  If the value of the ACCESS clause is "write-only", "write-
     only", then the value of the MAX-ACCESS clause is "read-write", MUST be "read-
     write", and the DESCRIPTION clause
     notes SHALL note that reading this
     object will result in implementation-specific results.

(10)

(7)  For all objects, if the value of the STATUS clause is "mandatory",
     the value must MUST be replaced with "current".

(11)

(8)  For all objects, if the value of the STATUS clause is "optional",
     the value must MUST be replaced with "obsolete".

(12)

(9)  For any object not containing a DESCRIPTION clause, the object must MUST
     have a DESCRIPTION clause defined.

(13)

(10) For any object corresponding to a conceptual row which does not
     have an INDEX clause, the object must MUST have either an INDEX clause
     or an AUGMENTS clause defined.

(14)

(11) For any object with an INDEX clause that references an object with
     a syntax of NetworkAddress, the value of the STATUS clause of both
     objects is MUST be changed to "obsolete".

(15)

(12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
     value which is expressed as a collection of sub-identifiers, change the
     value MUST be changed to reference a single ASN.1 identifier.  This
     may require defining a series of new objects in order to define the
     single ASN.1 identifier.

   Other changes are desirable, but not necessary:

(1)  Creation and deletion of conceptual rows is inconsistent using the
     SNMPv1 framework.
     SMIv1.  The SNMPv2 and SNMPv3 frameworks correct SMIv2 corrects this.  As such, if the MIB module
     undergoes review early in its lifetime, and it contains conceptual
     tables which allow creation and deletion of conceptual rows, then it may be worthwhile to deprecate
     the objects relating to those tables MAY be deprecated and replace them replaced
     with objects defined using the new approach.  The new approach can
     be found in section 7 of RFC1902 [7], and the RowStatus and
     StorageType TEXTUAL-CONVENTIONs are described in section 2 of
     RFC1903 [8].

(2)  For any object with a string-valued SYNTAX clause, in which the
     corresponding OCTET STRING does not have a size restriction (i.e.,
     the OCTET STRING has no assignment of lower- and upper-bounds on
     its length), it is recommended that the bounds for the size of the object SHOULD be
     defined.

(3)  For all  All textual conventions informally defined in the MIB module,
     it is recommended that those conventions module SHOULD
     be redefined using the TEXTUAL-
     CONVENTION macro be redefined. TEXTUAL-CONVENTION macro.  Such a change
     would not necessitate deprecating objects previously defined using
     an informal textual convention.

(4)  For any object which represents a measurement in some kind of
     units, it is recommended that a UNITS clause SHOULD be added to the definition of that
     object.

(5)  For any conceptual row which is an extension of another conceptual
     row, i.e., for which subordinate columnar objects both exist and
     are identified via the same semantics as the other conceptual row,
     it is recommended that
     an AUGMENTS clause SHOULD be used in place of the INDEX clause for
     the object corresponding to the conceptual row which is an
     extension.

   Finally, when encountering to avoid common errors in SNMPv1 SMIv1 MIB modules:

(1)  For any non-columnar object that is instanced as if it were
     immediately subordinate to a conceptual row, the value of the
     STATUS clause of that object is MUST be changed to "obsolete".

(2)  For any conceptual row object that is not contained immediately
     subordinate to a conceptual table, the value of the STATUS clause
     of that object (and all subordinate objects) is MUST be changed to
     "obsolete".

2.2.  Trap and Notification Definitions

   If a MIB module is changed to conform to the SNMPv2 framework, SMIv2, then each
   occurrence of the TRAP-TYPE macro must MUST be changed to a corresponding
   invocation of the NOTIFICATION-TYPE macro:

(1)  The IMPORTS statement must not MUST NOT reference RFC-1215, RFC-1215 [4], and should MUST
     reference SNMPv2-SMI instead.

(2)  The ENTERPRISE clause must MUST be removed.

(3)  The VARIABLES clause must MUST be renamed to the OBJECTS clause.

(4)  The STATUS clause must MUST be added, with a value of 'current'.

(5)  The value of an invocation of the NOTIFICATION-TYPE macro is an
     OBJECT IDENTIFIER, not an INTEGER, and must MUST be changed accordingly.
     Specifically, if the value of the ENTERPRISE clause is not 'snmp'
     then the value of the invocation is SHALL be the value of the
     ENTERPRISE clause extended with two sub-identifiers, the first of
     which has the value 0, and the second has the value of the
     invocation of the TRAP-TYPE.

(6)  The DESCRIPTION clause must MUST be added, if not already present.

(7)  One or more NOTIFICATION-GROUPs should SHOULD be defined, and related
     notifications should SHOULD be collected into those groups.

2.3.  Compliance Statements

   For those information modules which are "standard", a corresponding
   invocation of the MODULE-COMPLIANCE macro must and related OBJECT-GROUP
   macros MUST be included within the information module (or in a
   companion information module), and any commentary text in the
   information module which relates to compliance
   must SHOULD be removed.
   Typically this editing can occur when the information module
   undergoes review.

2.4.  Capabilities Statements

   In the SNMPv1 framework, the informational document [11] SMIv1, RFC1303 [5] uses the MODULE-CONFORMANCE macro to
   describe an agent's capabilities with respect to one or more MIB
   modules.  Converting such a description for use with the SNMPv2 framework SMIv2
   requires these changes:

(1)  Use the  The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-
     CONFORMANCE.

(2)  The STATUS clause must MUST be added, with a value of 'current'.

(3)  For all  All occurrences of the CREATION-REQUIRES clause, note the
     slight change in semantics, and omit this clause MUST either be
     omitted if appropriate. appropriate, or be changed such that the semantics are
     consistent with RFC1904 [9].

   In order to ease the coexistence between SNMPv1, SNMPv2, and SNMPv3, coexistence, object groups defined in an SMIv1
   compliant MIB module may be referenced by the INCLUDES clause of an
   invocation of the AGENT-
   CAPABILITIES AGENT-CAPABILITIES macro: upon encountering a
   reference to an OBJECT IDENTIFIER subtree defined in an SNMPv1 SMIv1 MIB
   module, all leaf objects which are subordinate to the subtree and
   have a STATUS clause value of mandatory are deemed to be INCLUDEd.
   (Note that this method is ambiguous when different revisions of a SNMPv1 an
   SMIv1 MIB have different sets of mandatory objects under the same
   subtree; in such cases, the only solution is to rewrite the MIB using
   the SMIv2 in order to define the object groups unambiguously.)

3.  SNMPv1 and SNMPv2 MIB Instrumentation

   In several places, this document refers to SNMPv1 MIB Instrumentation
   and SNMPv2 MIB Instrumentation.  This refers to the part of an SNMP
   agent which actually implements MIB objects, and which actually
   initiates generation of notifications.  Differences between the two
   types of MIB instrumentation are:

       -  Error-status values generated.

       -  Generation of exception codes.

       -  Use of the Counter64 data type.

       -  The format of parameters provided when a notification is
          generated.

   SNMPv1 MIB instrumentation will generate SNMPv1 error-status values,
   will never generate exception codes nor use the Counter64 data type,
   and will provide SNMPv1 format parameters for generating
   notifications.

   SNMPv2 MIB instrumentation will generate SNMPv2 error-status values,
   will generate exception codes, will use the Counter64 data type, and
   will provide SNMPv2 format parameters for generating notifications.

4.  Translating Notifications Between SNMP Formats Parameters

   This section describes how data contained in a notification is parameters used for generating
   notifications are translated between the SNMPv1 format used for SNMPv1
   notification protocol operations and the format used for SNMPv2 format.  There
   are two parts
   notification protocol operations.  The parameters used to the generate a
   notification are called 'notification parameters'.  The format of a notification, the SMI version
   parameters used for SNMPv1 notification protocol operations is
   refered to define the notification, and the in this document as 'SNMPv1 notification parameters.'  The
   format of parameters used for SNMPv2 notification protocol operations
   is refered to
   represent a generated notification. in this document as 'SNMPv2 notification parameters.'

   The SMI version used to define a notification will generally usually determine the format
   which type of notification parameters used are provided by MIB
   instrumentation when a notification is
   generated by generated.

   The situations where notification parameters MUST be translated are:

       -  When MIB instrumentation.  There are two formats for
   parameters, those used in an SNMPv1 notification, and those used instrumentation in an SNMPv2 notification.  These entity generates a set of information are refered to in
   this section as 'notification parameters format'.  There are two
   formats, the SNMPv1 notification parameter format and the SNMPv2
   notification parameter format.  There are two situations where
          notification parameters must be translated between SNMP formats:

       -  When instrumentation in an entity generates a set of
          notification parameters using one SNMP particular format, and the
          configuration of the entity indicates that the notification
          must be sent using a protocol an SNMP message version that requires
          notification parameters in the
          other SNMP format. format for notification parameters.

       -  When a proxy receives a notification in one that was sent using an
          SNMP format, message version that requires one format of notification
          parameters, and must forward the notification using a protocol an SNMP
          message version that requires a different SNMP format. the other format of notification
          parameters.

   In addition, it may MAY be desirable to translate notification parameters
   in a notification receiver application in order to present
   notifications to the end user in a consistent format.

   Note that for the purposes of this section, the format set of notification
   parameters is independent of whether the notification is to be sent
   as a trap or an inform.

   SNMPv1 notification parameters consist of:

       -  An enterprise value (OBJECT IDENTIFIER).

       -  An agent-addr value (NetworkAddress).

       -  A generic-trap value (INTEGER).

       -  A specific-trap value (INTEGER).

       -  A time-stamp value (TimeTicks).

       -  A list of variable-bindings (VarBindList).

   SNMPv2 notification parameters consist of:

       -  A sysUpTime value (TimeTicks).  This appears in the first
          variable-binding in an SNMPv2 notification. SNMPv2-Trap-PDU or InformRequest-PDU.

       -  An snmpTrapOID value (OBJECT IDENTIFIER).  This appears in the
          second variable-binding in an SNMPv2 notification. SNMPv2-Trap-PDU or
          InformRequest-PDU.

       -  A list of variable-bindings (VarBindList).  This refers to all
          but the first two variable-bindings in an SNMPv2 notification.

4.1. SNMPv2-Trap-PDU or
          InformRequest-PDU.

3.1.  Translating SNMPv1 Format Notification Parameters to SNMPv2 Format Notification
Parameters

   The following procedure describes how to translate SNMPv1
   notification parameters into SNMPv2 notification parameters:

(1)  The SNMPv2 sysUpTime value is SHALL be taken directly from the SNMPv1 time-
     stamp
     time-stamp value.

(2)  If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the
     SNMPv2 snmpTrapOID value is SHALL be the concatentation of the SNMPv1
     enterprise value and two additional sub-identifiers, '0', and the
     SNMPv1 specific-trap value.

(3)  If the SNMPv1 generic-trap value is not 'enterpriseSpecific(6)',
     the SNMPv2 snmpTrapOID value is SHALL be the corresponding trap as
     defined in [RFC1907]. section 2 of RFC1907 [12]:

            generic-trap value   snmpTrapOID.0
            ==================   =============
            0                    1.3.6.1.6.3.1.1.5.1 (coldStart)
            1                    1.3.6.1.6.3.1.1.5.2 (warmStart)
            2                    1.3.6.1.6.3.1.1.5.3 (linkDown)
            3                    1.3.6.1.6.3.1.1.5.4 (linkUp)
            4                    1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
            5                    1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)

(4)  The SNMPv2 variable-bindings is SHALL be the SNMPv1 variable-bindings with variable-bindings.
     In addition, if the translation is being performed by a
     single variable-binding appended. proxy in
     order to forward a received trap, three additional variable-
     bindings will be appended, if these three additional variable-
     bindings do not already exist in the SNMPv1 variable-bindings.  The
     name portion of this the first variable binding contains snmpTrapEnterprise.0 [RFC1907], SHALL contain
     snmpTrapAddress.0, and the value is SHALL contain the SNMPv1 enterprise agent-
     addr value.

(5)  The name portion of the second variable binding SHALL
     contain snmpTrapCommunity.0, and the value SHALL contain the value
     of the agent-addr community-string field is lost when converting
     notification parameters from the received SNMPv1 to SNMPv2.

4.2. message
     which contained the SNMPv1 Trap-PDU.  The name portion of the third
     variable binding SHALL contain snmpTrapEnterprise.0 [12], and the
     value SHALL be the SNMPv1 enterprise value.

3.2.  Translating SNMPv2 Format Notification Parameters to SNMPv1 Format Notification
Parameters

   The following procedure describes how to translate SNMPv2
   notification parameters into SNMPv1 notification parameters:

(1)  The SNMPv1 enterprise value is SHALL be determined as follows:

       -  If the SNMPv2 snmpTrapOID value is one of the standard traps
          as defined in [RFC1907], RFC1907 [12], then the SNMPv1 enterprise value is
          SHALL be set to the value of the variable-binding in the
          SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0 if
          that variable-binding exists.  If it does not exist, the
          SNMPv1 enterprise value is SHALL be set to the value 'snmpTraps'
          as defined in RFC1907 [RFC1907]. [12].

       -  If the SNMPv2 snmpTrapOID value is not one of the standard
          traps as defined in [RFC1907], RFC1907 [12], then the SNMPv1 enterprise
          value is SHALL be set to the SNMPv2 snmpTrapOID value as follows:

           -  If the next-to-last sub-identifier of the snmpTrapOID is
              zero, then the SMIv1 enterprise is SHALL be the SMIv2
              snmpTrapOID with the last 2 sub-identifiers removed,
              otherwise

           -  If the next-to-last sub-identifier of the snmpTrapOID is
              non-zero, then the SMIv1 enterprise is SHALL be the SMIv2
              snmpTrapOID with the last sub-identifier removed.

(2)  The SNMPv1 agent-addr value is SHALL be determined based on the
     situation in which the translation occurs.

       -  If the translation occurs within a notification originator
          application, and the notification is to be sent over UDP, the
          SNMPv1 agent-addr value is SHALL be set to the IP address of the
          SNMP entity in which the notification originator resides.  If
          the notification is to be sent over some other transport, the
          SNMPv1 agent-addr value is SHALL be set to 0.0.0.0.

       -  If the translation occurs within a proxy application, the
          proxy must attempt to determine the original source of the
          notification.  If the SNMPv2 variable-bindings contains a
          variable binding whose name is snmpTrapAddress.0, the agent-
          addr value SHALL be set to the value of that variable binding.
          Otherwise, If this source was an IP or UDP address, that
          address is SHALL be used for the SNMPv1 agent-addr value.
          Otherwise, the SNMPv1 agent-addr value is SHALL be set to
          0.0.0.0.

(3)  If the SNMPv2 snmpTrapOID value is one of the standard traps as
     defined in [RFC1907], RFC1907 [12], the SNMPv1 generic-trap value is SHALL be set
     as follows:

            value of snmpTrapOID.0                generic-trap
            ===============================       ============
            1.3.6.1.6.3.1.1.5.1 (coldStart)                  0
            1.3.6.1.6.3.1.1.5.2 (warmStart)                  1
            1.3.6.1.6.3.1.1.5.3 (linkDown)                   2
            1.3.6.1.6.3.1.1.5.4 (linkUp)                     3
            1.3.6.1.6.3.1.1.5.5 (authenticationFailure)      4
            1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)            5

    Otherwise, the SNMPv1 generic-trap value is SHALL be set to 6.

(4)  If the SNMPv2 snmpTrapOID value is one of the standard traps as
     defined in [RFC1907], RFC1907 [12], the SNMPv1 specific-trap value is SHALL be
     set to zero.  Otherwise, the SNMPv1 specific-trap value is SHALL be
     set to the last sub-identifier of the SNMPv2 snmpTrapOID value.

(5)  The SNMPv1 time-stamp value is SHALL be taken directly from the SNMPv2
     sysUpTime value.

(6)  The SNMPv1 variable-bindings is SHALL be the SNMPv2 variable-bindings
     with the following exceptions:

       -  If a variable-binding whose name is snmpTrapEnterprise.0
          exists in the SNMPv2 variable-bindings, that variable-binding
          is removed.

       -  If a  Any variable-binding whose type is Counter64 which exists in
          the SNMPv2 variable-bindings, the translation fails.  The
          consequences of a failed translation depend on the situation
          in which the translation is being performed.

4.3.  Notification Translation Failure

   If translation of a notification from SNMPv2 to SNMPv1 fails due to
   the existence of a variable-binding with a type of Counter64, the
   result is as follows:

       -  If the translation is being performed within a notification
          originator in order to send an SNMPv1 Trap-PDU, the Trap-PDU
          is simply not sent.  The notification may still be sent using
          other SNMP versions.

       -  If the translation is being performed within a proxy in order
          to forward the notification as an SNMPv1 Trap-PDU, the Trap-
          PDU is not sent.  The notification may still variable-bindings SHALL be forwarded
          using other SNMP versions.

4.3.1.  discussion about additional varbinds (agent_addr, community)

5. removed.

4.  Approaches to Coexistence in a Multi-lingual Network

   There are two basic approaches to coexistence in a multi-lingual
   network, multi-lingual implementations, and proxy implementations.
   Multi-lingual implementations allow elements in a network to
   communicate with each other using an SNMP version which both elements
   support.  This allows a multi-lingual implentation to communicate
   with any mono-lingual implementation, regardless of the SNMP version
   supported by the mono-lingual implementation.

   Proxy implementations provide a mechanism for translating between
   SNMP versions using a third party network element.  This allows
   network elements which support only a single, but different, SNMP
   version to communicate with each other.  Proxy implementations are
   also useful for securing communications over an insecure link between
   two locally secure networks.

5.1.

4.1.  Multi-lingual implementations

   This approach requires an entity to support multiple SNMP message
   formats.
   versions.  Typically this means supporting SNMPv1, SNMPv2c, and
   SNMPv3 message formats. versions.  The behaviour of various types of SNMPv3 SNMP
   applications which support multiple message formats versions is described in
   the following sections.  This approach allows entities which support
   multiple SNMP message formats versions to coexist with and communicate with
   entities which support only a single SNMP message format.

5.1.1. version.

4.1.1.  Command Generator

   A command generator must select an appropriate message format version when
   sending requests to another entity.  One way to achieve this is to
   consult a local database to select the appropriate message format. version.

   In addition, a command generator should 'downgrade' GetBulk requests
   to GetNext requests when selecting SNMPv1 as the message format version for
   an outgoing request.

5.1.2.

4.1.2.  Command Responder

   A command responder must be able to deal with MIB instrumentation
   that is written using both the SNMPv1 and SNMPv2.  There are three
   aspects to dealing with this.  A command responder must:

       -  Deal correctly with SNMPv2 MIB instrumentation that returns a
          Counter64 value while processing an SNMPv1 message,

       -  Deal correctly with SNMPv2 MIB instrumentation that returns
          one of the three exception values while processing an SNMPv1
          message, and

       -  Map SNMPv2 error codes returned from SNMPv2 MIB
          instrumentation into SNMPv1 error code when processing an
          SNMPv1 message, and message.

   Note that SNMPv1 error codes can be used without any change when
   processing SNMPv2c or SNMPv3 messages.

   Details about how

   The following sections describe the behaviour of a command responder handles these requirements are
   provided in section 6.

5.1.3.  Notification Originator

   A notification originator must be able
   application which supports multiple SNMP message versions, and which
   has access to translate notifications
   between some combination of SNMPv1 and SNMPv2 formats in order to send a notification
   using a particular SNMP message format.  If instrumentation presents
   a notification in the SMIv1 format and configuration information
   specifies MIB
   instrumentation.

4.1.2.1.  Handling Counter64

   The SMIv2 [7] defines one new syntax that notifications be sent using SNMPv2c or SNMPv3, the
   notification must be translated to the SNMPv2 format.  Likewise, if
   instrumentation presents is incompatible with SMIv1.
   This syntax is Counter64.  All other syntaxes defined by SMIv2 are
   compatible with SMIv1.

   The impact on multi-lingual command responders is that they MUST NOT
   ever return a notification variable binding containing a Counter64 value in a
   response to a request that was received using the SNMPv2 format and
   configuration information specifies SNMPv1 message
   version.

   Multi-lingual command responders SHALL take the approach that notifications object
   instances whose type is Counter64 are implicitly excluded from view
   when processing an SNMPv1 message.  So:

       -  On an SNMPv1 GET request, an error-status of noSuchName SHALL
          be sent using
   SNMPv1, returned, and the notification must error-index SHALL be translated set to the variable
          binding that caused this error.

       -  On an SNMPv1 format.

5.1.4.  Notification Receiver

   There are no special requirements GETNEXT request, any object instance which
          contains a syntax of Counter64 shall be skipped, and the next
          object instance that follows the one with a notification receiver.
   However, an implementation syntax of
          Counter64 SHALL be fetched.  This step may find it useful to allow a higher level
   application need to request which SNMP format should be used when
   delivering notifications to that higher level application.  The
   notification receiver would then translate between SNMP formats when
   required repeated
          several times in order to present a notification using the desired format.

5.2.  Proxy Implementations

   A proxy implementation may be used to enable communication between
   entities which support different SNMP message formats.  This find an object whose syntax is
   accomplished in not
          Counter64.

       -  Any SET request that has a proxy forwarding application by performing
   translations on variable binding with a PDU in the following situations:

       -  If Counter64
          value must have come from a GetBulkRequest-PDU SNMPv2 manager, and so it should
          not cause a problem.  However, if an object with SYNTAX of
          Counter64 is received and must be forwarded
          using the in an SNMPv1 message format, SET packet, it SHALL result
          in an ASN.1 parse error since Counter64 is not valid in the proxy forwarder sets
          SNMPv1 protocol. When an ASN.1 parse error occurs, the
          non-repeaters counter
          snmpInASNParseErrs SHALL be incremented and max-repetitions fields no response is
          returned.

4.1.2.2.  Mapping SNMPv2 Exceptions

   SNMPv2 provides a feature called exceptions, which allow an SNMPv2
   Response PDU to 0, return as much management information as possible,
   even when an error occurs.  However, SNMPv1 does not support
   exceptions, and sets the
          tag of the so an SNMPv1 Response PDU to GetNextRequest-PDU.

       -  If a GetResponse-PDU is received whose cannot return any
   management information, and can only return an error-status field has and
   error-index value.

   When an SNMPv1 request is received, a value of 'tooBig', command responder MUST check
   any variable bindings returned from SNMPv2 MIB instrumentation for
   exception values, and the message will convert these exception values into SNMPv1
   error codes.

   The type of exception that can be forwarded using
          the SNMPv2c or SNMPv3 message format, returned from MIB instrumentation
   and the proxy forwarder will
          remove action taken depends on the contents type of the variable-bindings field before
          forwarding the response. SNMP request.

       -  If  For a Trap-PDU is received, and GetRequest, a noSuchObject or noSuchInstance exception
          may be returned.

       -  For a GetNextRequest, an endOfMibView exception may be
          returned.

       -  No exceptions will be forwarded using the
          SNMPv2c or SNMPv3 message format, the proxy will apply the
          translation rules described returned for a SetRequest, and a
          GetBulkRequest should only be received in section 4, an SNMPv2c or SNMPv3
          message, so these request types may be ignored when mapping
          exceptions.

4.1.2.2.1.  Mapping nosuchObject and will forward noSuchInstance

   A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB
   instrumentation indicates that the
          notification as an SNMPv2-Trap-PDU.

       -  If an SNMPv2-Trap-PDU requested object instance can not
   be returned.  The SNMPv1 error code for this condition is received, noSuchName,
   and will so the error-status field of the response PDU SHALL be forwarded using set to
   noSuchName.  Also, the SNMPv1 message format, error-index field SHALL be set to the proxy will apply index of
   the
          translation rules described in section 4, variable binding for which an exception occurred, and will forward the
          notification as a Trap-PDU.

       -  If an InformRequest-PDU is received, any configuration
          information indicating that it would be forwarded using
   variable binding list from the
          SNMPv1 message format, is ignored.  An InformRequest-PDU can
          only original request SHALL be forwarded using the SNMPv2c or SNMPv3 message format.

6.  Multi-Lingual Command Responder Behaviour

   The following sections describe returned
   with the behaviour of response PDU.

   Note that when a command responder
   application which supports response contains multiple SNMP message formats, and which
   has access exceptions, it is an
   implementation choice as to some combination of SNMPv1 and which variable binding the error-index
   should reference.

4.1.2.2.2.  Mapping endOfMibView

   When SNMPv2 MIB
   instrumentation.

6.1.  Mapping SMIv2 into SMIv1

   The SMIv2 [RFC1902] defines one new syntax instrumentation returns a variable binding containing
   an endOfMibView exception, it indicates that is incompatible with
   SMIv1.  This syntax is Counter64.  All other syntaxes defined by
   SMIv2 there are compatible with SMIv1.

   The impact on multi-lingual command responders is that they should
   make sure that they never return a variable binding containing a
   Counter64 value in a response to a request that was received using
   the SNMPv1 message format.

   Multi-lingual command responders should take the approach that no object
   instances whose type is Counter64 are implicitly excluded from view
   when processing an SNMPv1 message.  So:

       -  On available which lexicographically follow the object in the
   request. In an SNMPv1 GET request, we return an error-status of agent, this condition normally results in a
   noSuchName error, and so the error-status field of the response PDU
   SHALL be set to noSuchName. Also, the error-index is field SHALL be set
   to the index of the variable binding
          that causes this error.

       -  On for which an SNMPv1 GETNEXT request, we skip the object instance exception occurred,
   and
          fetch the next object instance that follows the one with a
          syntax of Counter64.

       -  Any SET request that has a variable binding with a Counter64
          value must have come list from the original request SHALL be
   returned with the response PDU.

   Note that when a SNMPv2 manager, and so it should
          not cause a problem.  If we do receive a Counter64 value in an
          SNMPv1 SET packet, response contains multiple exceptions, it should result in an ASN.1 parse error
          since Counter64 is not valid in an
   implementation choice as to which variable binding the error-index
   should reference.

4.1.2.3.  Processing An SNMPv1 protocol. GetRequest

   When processing an
          ASN.1 parse error occurs, SNMPv1 GetRequest, the counter snmpInASNParseErrs is
          incremented and no response is returned.

6.2.  Mapping SNMPv2 Exceptions following procedures MUST
   be followed when calling SNMPv2 provides a feature called exceptions, which allow an MIB instrumentation.

   When such MIB instrumentation returns response data using SNMPv2
   Response PDU to return as much management information as possible,
   even when an error occurs.  However, SNMPv1 does not support
   exceptions, and so an SNMPv1 Response PDU cannot return any
   management information,
   syntax and can only return an error-status and
   error-index value.

   When an SNMPv1 request is received, a command responder must check
   any variable bindings returned from SNMPv2 compliant instrumentation
   for exception values, and convert these exception values into SNMPv1
   error codes.

   The type of exception that can be returned from instrumentation and
   the action taken depends on then:

(1)  If the type of SNMP request.

       -  For a GetRequest, a noSuchObject or noSuchInstance exception
          may be returned.

       -  For a GetNextRequest, an endOfMibView exception may be
          returned. error-status is anything other than noError,

       -  No exceptions will be returned for a SetRequest, and a
          GetBulkRequest should only  The error status SHALL be received in translated to an SNMPv2c or SNMPv3
          message, so these request types may be ignored when mapping
          exceptions.

6.2.1.  Mapping nosuchObject and noSuchInstance

   A noSuchObject or noSuchInstance exception generated by SNMPv2
   compliant instrumentation indicates that the requested object
   instance can not be returned.  The SNMPv1 error code for this
   condition is noSuchName, and so the error-status field of
          using the
   response PDU should table in section 4.3, "Error Status Mappings".

       -  The error-index SHALL be set to noSuchName.  Also, the error-index
   field is set to position (in the index original
          request) of the variable binding for which an
   exception occurred, and that caused the error-status.

       -  The variable binding list from the original
   request is returned with of the response PDU.

   Note that when a response contains multiple exceptions, it is an
   implementation choice PDU SHALL be made
          exactly the same as to which the variable binding the error-index
   should reference.

6.2.2.  Mapping endOfMibView

   When SNMPv2 compliant instrumentation returns a variable binding
   containing an endOfMibView exception, it indicates list that there are no
   object instances available which lexicographically follow the object was
          received in the original request. In an SNMPv1 agent, this condition normally results
   in a noSuchName error, and so

(2)  If the error-status field of the response
   PDU should be set to noSuchName. Also, the error- index field is set
   to the index of noError, the variable binding bindings SHALL be
     checked for which an any SNMPv2 exception occurred,
   and the variable binding list from the original request is returned
   with the response PDU.

   Note (noSuchObject or noSuchInstance)
     or an SNMPv2 syntax that when a response contains multiple exceptions, it is unknown to SNMPv1 (Counter64).  If
     there are any such variable bindings, one of those variable
     bindings SHALL be selected (it is an implementation choice as to
     which variable binding the error-index
   should reference.

6.3.  Processing An SNMPv1 GetRequest

   When processing an SNMPv1 GetRequest, the following procedures should
   be followed when calling SNMPv2 MIB instrumentation.

   When such instrumentation returns response data using SNMPv2 syntax
   and error-status values, then:

(1)  If the error-status is anything other than noError, selected), and:

       -  The error status is translated to an SNMPv1 error-status using
          the table in section 7, "Mapping SNMPv2 error-status into
          SNMPv1 error-status" SHALL be set to noSuchName,

       -  The error-index is SHALL be set to the position (in the variable
          binding list of the original request) of the selected variable binding that caused the error-status.
          binding, and

       -  The variable binding list of the response PDU is made SHALL be exactly
          the same as the variable binding list that was received in the
          original request.

(2)

(3)  If the error-status is noError, then find any variable binding that
     contains an SNMPv2 exception (noSuchObject or noSuchInstance) or an
     SNMPv2 syntax that is unknown to SNMPv1 (Counter64).  (Note that if there are more than one, the agent may choose any such variable
     binding.)  If there are any no such variable bindings, then then:

       -  The error-status SHALL be set to noError,

       -  The error-index SHALL be set to zero, and

       -  The variable binding list of the response SHALL be composed
          from the data as it is returned by the MIB instrumentation.

4.1.2.4.  Processing An SNMPv1 GetNextRequest

   When processing an SNMPv1 GetNextRequest, the following procedures
   MUST be followed when SNMPv2 MIB instrumentation is called as part of
   processing the request.  There may be repetitive calls to (possibly
   different pieces of) MIB instrumentation to try to find the first
   object which lexicographically follows each of the objects in the
   request.  This is implementation specific.  These procedures are
   followed only for data returned from SNMPv2 MIB instrumentation.
   Data returned from SNMPv1 MIB instrumentation may be treated in the
     one chosen:

       -  Set
   normal manner for an SNMPv1 request.

   First, if the MIB instrumentation returns an error-status of anything
   other than noError:

(1)  The error status SHALL be translated to noSuchName

       -  Set an SNMPv1 error-status
     using the table in section 4.3, "Error Status Mappings".

(2)  The error-index SHALL be set to the position (in the variable binding
          list of the original
     request) of the variable binding that
          returned such an SNMPv2 exception or syntax.

       -  Make caused the error-status.

(3)  The variable binding list of the response PDU SHALL be exactly the
     same as the variable binding list that was received the variable binding list that was received in the original
     request.

   Otherwise, if the MIB instrumentation returns an error-status of
   noError:

(1)  Any variable bindings containing an SNMPv2 syntax of Counter64
     SHALL be considered to be not in view, and the MIB instrumentation
     SHALL be called as often as is required until either a value other
     than Counter64 is returned, or an error occurs.

(2)  If there is any variable binding that contains an SNMPv2 exception
     endOfMibView (there may be more than one, it is an implementation
     decision as to which is chosen):

       -  The error-status SHALL be set to noSuchName,

       -  The error-index SHALL be set to the position (in the variable
          binding list of the original request) of the variable binding
          that returned such an SNMPv2 exception, and

       -  The variable binding list of the response PDU SHALL be exactly
          the same as the variable binding list that was received in the
          original request.

(3)  If there are no such variable bindings, then:

       -  The error-status SHALL be set to noError,

       -  The error-index SHALL be set to zero, and

       -  The variable binding list of the response SHALL be composed
          from the data as it is returned by the MIB instrumentation.

4.1.3.  Notification Originator

   A notification originator must be able to translate between SNMPv1
   notifications parameters and SNMPv2 notification parameters in order
   to send a notification using a particular SNMP message version.  If
   MIB instrumentation presents a notification using SNMPv1 notification
   parameters, and configuration information specifies that
   notifications be sent using SNMPv2c or SNMPv3, the notification
   parameters must be translated to SNMPv2 notification parameters.
   Likewise, if MIB instrumentation presents a notification using SNMPv2
   notification parameters, and configuration information specifies that
   notifications be sent using SNMPv1, the notification parameters must
   be translated to SNMPv1 notification parameters.

   When a notification originator generates a notification, using
   parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-
   MIB, if the SNMP version used to generate the notification is SNMPv1,
   the PDU type used will always be a TrapPDU, regardless of whether the
   value of snmpNotifyType is trap(1) or inform(2).

   Note also that access control and notification filtering are
   performed in the usual manner for notifications, regardless of the
   SNMP message version to be used when sending a notification.  The
   parameters for performing access control are found in the usual
   manner (i.e. from inspecting the SNMP-TARGET-MIB and SNMP-
   NOTIFICATION-MIB).  In particular, when generating an SNMPv1 Trap, in
   order to perform the access check specified in [18], section 3.3,
   bullet (3), the notification originator may need to generate a value
   for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of
   this document (if the SNMPv1 notificaton parameters being used were
   previously translated from a set of SNMPv2 notification parameters,
   this value may already be known, in which case it need not be
   generated).

4.1.4.  Notification Receiver

   There are no special requirements of a notification receiver.
   However, an implementation may find it useful to allow a higher level
   application to request whether notifications should be delivered to a
   higher level application using SNMPv1 notification parameter or
   SNMPv2 notification parameters.  The notification receiver would then
   translate notification parameters when required in order to present a
   notification using the desired set of parameters.

4.2.  Proxy Implementations

   A proxy implementation may be used to enable communication between
   entities which support different SNMP message versions.  This is
   accomplished in a proxy forwarder application by performing
   translations on a PDU in the following situations:

       -  If a GetBulkRequest-PDU is received and must be forwarded
          using the SNMPv1 message version, the proxy forwarder SHALL
          set the non-repeaters and max-repetitions fields to 0, and
          SHALL set the tag of the PDU to GetNextRequest-PDU.

       -  If a GetResponse-PDU is received whose error-status field has
          a value of 'tooBig', and the message will be forwarded using
          the SNMPv2c or SNMPv3 message version, the proxy forwarder
          SHALL remove the contents of the variable-bindings field
          before forwarding the response.

       -  If a GetResponse-PDU is received which contains variable-
          bindings of type Counter64 or which contain an SNMPv2
          exception code, and the message would be forwarded using the
          SNMPv1 message version, the proxy MUST generate an alternate
          response PDU consisting of the request-id and variable
          bindings from the original SNMPv1 request, containing a
          noSuchName error-status value, and containing an error-index
          value indicating the position of the variable-binding
          containing the Counter64 type.

       -  If a Trap-PDU is received, and will be forwarded using the
          SNMPv2c or SNMPv3 message version, the proxy SHALL apply the
          translation rules described in section 3, and SHALL forward
          the notification as an SNMPv2-Trap-PDU.

       -  If an SNMPv2-Trap-PDU is received, and will be forwarded using
          the SNMPv1 message version, the proxy SHALL apply the
          translation rules described in section 3, and SHALL forward
          the notification as a Trap-PDU.

       -  If an InformRequest-PDU is received, any configuration
          information indicating that it would be forwarded using the
          SNMPv1 message version SHALL be ignored.  An InformRequest-PDU
          can only be forwarded using the SNMPv2c or SNMPv3 message
          version.

       -  In all other cases, the proxy SHALL forward a received PDU
          without change.

   Note that when an SNMPv1 agent generates a message containing a
   Trap-PDU which is subsequently forwarded by one or more proxy
   forwarders using SNMP versions other than SNMPv1, the community
   string and agent-addr fields from the original message generated by
   the SNMPv1 agent will be preserved through the use of the
   snmpTrapAddress and snmpTrapCommunity objects.

4.3.  Error Status Mappings

   The following tables shows the mappings of SNMPv1 error-status values
   into SNMPv2 error-status values, and the mappings of SNMPv2 error-
   status values into SNMPv1 error-status values.

                          SNMPv1 error-status    SNMPv2 error-status
                          ===================    ===================
                          noError                noError
                          tooBig                 tooBig
                          noSuchName             noSuchName
                          badValue               badValue
                          genErr                 genErr

                          SNMPv2 error-status    SNMPv1 error-status
                          ===================    ===================
                          noError                noError
                          tooBig                 tooBig
                          genErr                 genErr
                          wrongValue             badValue
                          wrongEncoding          badValue
                          wrongType              badValue
                          wrongLength            badValue
                          inconsistentValue      badValue
                          noAccess               noSuchName
                          notWritable            noSuchName
                          noCreation             noSuchName
                          inconsistentName       noSuchName
                          resourceUnavailable    genErr
                          commitFailed           genErr
                          undoFailed             genErr
                          authorizationError     noSuchName

5.  Message Processing Models and Security Models

In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the
following models must be defined:

       -  The SNMPv1 Message Processing Model

       -  The SNMPv1 Community-Based Security Model

   The following models are also described in this document:

       -  The SNMPv2c Message Processing Model

       -  The SNMPv2c Community-Based Security Model

          In most respects, the SNMPv1 Message Processing Model and the
          SNMPv2c Message Processing Model are identical, and so these
          are not discussed independently in this document.  Differences
          between the two models are described as required.

          Similarly, the SNMPv1 Community-Based Security Model and the
          SNMPv2c Community-Based Security Model are nearly identical,
          and so are not discussed independently.  Differences between
          these two models are also described as required.

5.1.  Mappings

The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
require mappings between parameters used in SNMPv1 (and SNMPv2c)
messages, and the version independent parameters used in the SNMP
architecture [16].  The parameters which MUST be mapped consist of the
SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and
contextEngineID/contextName pair.  A MIB module (the SNMP-COMMUNITY-MIB)
is provided in this document in order to perform these mappings.  This
MIB provides mappings in both directions, that is, a community name may
be mapped to a securityName, contextEngineID, and contextName, or the
combination of securityName, contextEngineID, and contextName may be
mapped to a community name.

5.2.  The SNMPv1 Message Processing Model

   The SNMPv1 Message Processing Model handles processing of SNMPv1
   messages.  The processing of messages is handled generally in the
   same manner as described in RFC1157 [2], with differences and
   clarifications as described in the
          original request. following sections.  The
   SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
   SNMPv2c is 1).

5.2.1.  Processing An Incoming Request

   In RFC1157 [2], section 4.1, item (3)  If there for an entity which receives a
   message, states that various parameters are no such variable bindings, then:

       -  Set the error-status to noError

       -  Set the error-index passed to zero

       -  Compose the variable binding list of the response, using the
          data as it 'desired
   authentication scheme.'  The desired authentication scheme in this
   case is returned by the instrumentation code.

6.4.  Processing An SNMPv1 GetNextRequest

   When processing an SNMPv1 GetNextRequest, Community-Based Security Model, which will be
   called using the following procedures processIncomingMsg ASI.  The parameters passed to
   this ASI are:

       -  The messageProcessingModel, which will be 0 (or 1 for
          SNMPv2c).

       -  The maxMessageSize, which should be followed when SNMPv2 MIB instrumentation is called as part the maximum size of processing a
          message that the request.  There may be repetitive calls to
   (possibly different pieces of) instrumentation code to try to find receiving entity can generate (since there is
          no such value in the first object received message).

       -  The securityParameters, which lexicographically follows each consist of the objects
   in community string
          and the request.  This is implementation specific.  These procedures
   are followed only for data returned from SNMPv2 instrumentation.
   Data returned from SNMPv1 instrumentation may message's source and destination transport addresses.

       -  The securityModel, which will be treated in the
   normal manner 1 (or 2 for an SNMPv1 request.

   First, if the instrumentation returns an error-status of anything
   other than noError:

(1) SNMPv2c).

       -  The error status is translated securityLevel, which will be noAuthNoPriv.

       -  The wholeMsg and wholeMsgLength.

   The Community-Based Security Model will attempt to an SNMPv1 error-status using select a row in
   the snmpCommunityTable.  This is done by performing a search through
   the
     table snmpCommunityTable in section 7, "Mapping SNMPv2 error-status into SNMPv1
     error-status"

(2) lexicographic order.  The error-index first entry for
   which the following matching criteria are satisfied will be selected:

       -  The community string is set equal to the position (in the original request) of
     the variable binding that caused the error-status.

(3)  The variable binding list of snmpCommunityName value.

       -  If the response PDU snmpCommunityTransportTag is made exactly not an empty string, the
     same as
          transportDomain and transportAddress from which the variable binding list that message
          was received must match one of the entries in the original
     request.

   Otherwise, if
          snmpTargetAddrTable selected by the instrumentation returns snmpCommunityTransportTag
          value.  If the snmpCommunityTransportTag is an error-status empty string,
          it is ignored for the purpose of noError:

(1) matching.

   If there are any variable bindings containing no such entry can be found, an SNMPv2 syntax authentication failure occurs as
   described in RFC1157 [2].

   The parameters returned from the Community-Based Security Model are:

       -  The securityEngineID, which will always be the local value of
     Counter64, then consider these variable bindings to
          snmpEngineID.0.

       -  The securityName.

       -  The scopedPDU.  Note that this parameter will actually consist
          of three values, the contextSnmpEngineID, the contextName, and
          the PDU.  These must be separate values, since the first two
          do not actually appear in view
     and repeat the call to message.

       -  The maxSizeResponseScopedPDU.

       -  The securityStateReference.

   The appropriate SNMP application will then be called (depending on
   the instrumentation code as often as needed
     until a value other than Counter64 is returned.

(2)  Find any variable binding that contains an SNMPv2 exception
     endOfMibView.  (Note that if there are more than one, of the agent may
     choose any such variable binding.)  If there are any such variable
     bindings, then contextEngineID and the request type in the PDU)
   using the processPdu ASI.  The parameters passed to this ASI are:

       -  The messageProcessingModel, which will be 0 (or 1 for
          SNMPv2c).

       -  The securityModel, which will be 1 (or 2 for the one chosen: SNMPv2c).

       -  Set  The securityName, which was returned from the error-status call to noSuchName
          processIncomingMsg.

       -  Set the error-index to the position (in the variable binding
          list  The securityLevel, which is noAuthNoPriv.

       -  The contextEngineID, which was returned as part of the original request) of
          ScopedPDU from the variable binding that
          returned such an SNMPv2 exception. call to processIncomingMsg.

       -  Make the variable binding list  The contextName, which was returned as part of the response PDU exactly ScopedPDU
          from the
          same as call to processIncomingMsg.

       -  The pduVersion, which should indicate an SNMPv1 version PDU
          (if the variable binding list that message version was received in the
          original request.

(3)  If there are no such variable bindings, then: SNMPv2c, this would be an SNMPv2
          version PDU).

       -  Set  The PDU, which was returned as part of the error-status ScopedPDU from the
          call to noError processIncomingMsg.

       -  Set  The maxSizeResponseScopedPDU which was returned from the error-index call
          to zero processIncomingMsg.

       -  Compose the variable binding list of  The stateReference which was returned from the response, using call to
          processIncomingMsg.

   The SNMP application should process the
          data request as it described
   previously in this document.  Note that access control is returned applied by the instrumentation code.

7.  Error Status Mappings
   an SNMPv3 command responder application as usual.  The following table shows parameters as
   passed to the mappings of SNMPv2 error-status values
   into SNMPv1 error-status values.

                          SNMPv2 error-status    SNMPv1 error-status
                          ===================    ===================
                          noError                noError
                          tooBig                 tooBig
                          noSuchName             noSuchName
                          badValue               badValue
                          readOnly               readOnly
                          genErr                 genErr
                          wrongValue             badValue
                          wrongEncoding          badValue
                          wrongType              badValue
                          wrongLength            badValue
                          inconsistentValue      badValue
                          noAccess               noSuchName
                          notWritable            noSuchName
                          noCreation             noSuchName
                          inconsistentName       noSuchName
                          resourceUnavailable    genErr
                          commitFailed           genErr
                          undoFailed             genErr
                          authorizationError     noSuchName

8.  Message Processing Models and Security Models

In order processPdu ASI will be used in calls to adapt SNMPv1 and SNMPv2c into the SNMPv3 architecture, four
additional models
   isAccessAllowed ASI.

5.2.2.  Generating An Outgoing Response

   There is no special processing required for generating an outgoing
   response.  However, the community string used in an outgoing response
   must be defined:

       - the same as the community string from the original request.
   The original community string MUST be present in the stateReference
   information of the original request.

5.2.3.  Generating An Outgoing Notification

   In a multi-lingual SNMP entity, the parameters used for generating
   notifications will be obtained by examining the SNMP-TARGET-MIB and
   SNMP-NOTIFICATION-MIB.  These parameters will be passed to the SNMPv1
   Message Processing Model

       - using the sendPdu ASI.  The SNMPv2c SNMPv1 Message
   Processing Model will attempt to locate an appropriate community
   string in the snmpCommunityTable based on the parameters passed to
   the sendPdu ASI.  This is done by performing a search through the
   snmpCommunityTable in lexicographic order.  The first entry for which
   the following matching criteria are satisfied will be selected:

       -  The SNMPv1 Community-Based Security Model securityName must be equal to the
          snmpCommunitySecurityName value.

       -  The SNMPv2c Community-Based Security Model

          In most respects, contextEngineID must be equal to the SNMPv1 Message Processing Model and
          snmpCommunityContextEngineID value.

       -  The contextName must be equal to the
          SNMPv2c Message Processing Model are identical, and so these
          are snmpCommunityContextName
          value.

       -  If the snmpCommunityTransportTag is not discussed independently an empty string, the
          transportDomain and transportAddress must match one of the
          entries in this document.  Differences
          between the two models are described as required.

          Similarly, snmpTargetAddrTable selected by the SNMPv1 Community-Based Security Model and
          snmpCommunityTransportTag value.  If the
          SNMPv2c Community-Based Security Model are nearly identical,
          and so are
          snmpCommunityTransportTag is an empty string, it is ignored
          for the purpose of matching.

   If no such entry can be found, the notification is not discussed independently.  Differences between
          these two models are also described as required.

8.1.  Mappings

The SNMPv1 and SNMPv2c Message Processing Models and Security Models
require mappings between parameters sent.
   Otherwise, the community string used in SNMPv1 and SNMPv2c messages,
and those use in SNMPv3 messages.  The parameters which must the outgoing notification
   will be mapped
consist the value of the SNMPv1 and SNMPv2c community name, and snmpCommunityName column of the SNMPv3
securityName selected
   row.

5.3.  The SNMP Community MIB Module

   The SNMP-COMMUNITY-MIB contains objects for mapping between community
   strings and contextEngineID/contextName pair.  A version-independent SNMP message parameters.  In
   addition, this MIB module (the
SNMP-COMMUNITY-MIB) is provided provides a mechanism for performing source address
   validation on incoming requests, and for selecting community strings
   based on target addresses for outgoing notifications.  These two
   features are accomplished by providing a tag in this document the
   snmpCommunityTable which selects sets of entries in order to perform
these mappings. the
   snmpTargetAddrTable [18].  In addition, the SNMP-COMMUNITY-MIB
   augments the snmpTargetAddrTable with a transport address mask value.
   This MIB provides mappings allows selected entries in both directions, that is, the snmpTargetAddrTable to specify
   multiple addresses (rather than just a community name may single address per entry).
   This would typically be mapped used to specify a securityName, contextEngineID, and
contextName, or subnet in an
   snmpTargetAddrTable rather than just a single address.

   The mask value, snmpTargetAddrTMask, is used to select which bits of
   a transport address must match bits of the combination corresponding instance of securityName, contextEngineID, and
contextName may be mapped
   snmpTargetAddrTAddress, in order for the transport address to match a community name.

8.2.  Elements Of Procedure
   particular entry in the snmpTargetAddrTable.  The following sections describe value of
   snmpTargetAddrTMask must always be an OCTET STRING of the procedures for processing various
types same length
   as the snmpTargetAddrTAddress.

   Each bit of SNMPv1 and SNMPv2c messages.

8.2.1.  Processing An Incoming Request

8.2.2.  Processing An Outgoing Response

8.2.3.  Processing An Incoming Notification

8.2.4.  Processing An Outgoing Notification

8.3.  Community MIB each octet in the snmpTargetAddrTMask value corresponds
   to the same bit of the same octet in the snmpTargetAddrTAddress
   value.  For bits that are set in the snmpTargetAddrTMask value (i.e.
   bits equal to 1), the corresponding bits in the
   snmpTargetAddrTAddress value must match the bits in a transport
   address.  If all such bits match, the transport address is matched by
   that snmpTargetAddrTable entry.  Otherwise, the transport address is
   not matched.

      SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN

      IMPORTS
          IpAddress
              FROM RFC1155-SMI
          MODULE-IDENTITY,
          OBJECT-TYPE,
          Integer32,
          Counter32,
          UInteger32
              FROM SNMPv2-SMI
          RowStatus,
          TestAndIncr,
          StorageType
              FROM SNMPv2-TC
          SnmpAdminString
              FROM SNMP-FRAMEWORK-MIB
          SnmpTagValue
              FROM SNMP-TARGET-MIB
          MODULE-COMPLIANCE,
          OBJECT-GROUP
              FROM SNMPv2-CONF;

      snmpCommunityMIB MODULE-IDENTITY
          LAST-UPDATED "9805110000Z"            -- 11 May 1998, midnight
          ORGANIZATION "SNMPv3 Working Group"
          CONTACT-INFO "WG-email:   snmpv3@tis.com
                        Subscribe:  majordomo@tis.com
                                    In msg body:  subscribe snmpv3

                        Chair:      Russ Mundy
                                    Trusted Information Systems
                        postal:     3060 Washington Rd
                                    Glenwood MD 21738
                                    USA
                        email:      mundy@tis.com
                        phone:      +1-301-854-6889

                        Co-editor:  Rob Frye
                                    MCI Communications Corp.
                        Postal:     2100 Reston Parkway, Suite 600
                                    Reston, VA 20191
                                    USA
                        E-mail:     Rob.Frye@mci.com
                        Phone:      +1 703 715 7225

                        Co-editor:  David B. Levi
                                    SNMP Research, Inc.
                        Postal:     3001 Kimberlin Heights Road
                                    Knoxville, TN 37920-9716
                        E-mail:     levi@snmp.com
                        Phone:      +1 423 573 1434

                        Co-editor:  Shawn A. Routhier
                                    Integrated Systems Inc.
                        Postal:     333 North Ave 4th Floor
                                    Wakefield, MA 01880
                        E-mail:     sar@epilogue.com
                        Phone:      +1 781 245 0804

                        Co-editor:  Bert Wijnen
                                    IBM T. J. Watson Research
                        postal:     Schagen 33
                                    3461 GL Linschoten
                                    Netherlands
                        email:      wijnen@vnet.ibm.com
                        phone:      +31-348-432-794
                       "

              DESCRIPTION
                  "This MIB module defines objects to help support coexistence
                   between SNMPv1, SNMPv2, and SNMPv3."
          ::= { snmpModules xxx 18 }

      -- get assignment from IANA

   -- Administrative assignments ****************************************

      snmpCommunityMIBObjects     OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
      snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }

      --
      -- The snmpCommunityTable contains a database of community strings.
      -- This table provides mappings between community strings, and the
      -- parameters required for View-based Access Control.
      --

      snmpCommunityTable OBJECT-TYPE
          SYNTAX       SEQUENCE OF SnmpCommunityEntry
          MAX-ACCESS   not-accessible
          STATUS       current
          DESCRIPTION
              "The table of community strings configured in the SNMP
               engine's Local Configuration Datastore (LCD)."
          ::= { snmpCommunityMIBObjects 1 }

      snmpCommunityEntry OBJECT-TYPE
          SYNTAX       SnmpCommunityEntry
          MAX-ACCESS   not-accessible
          STATUS       current
          DESCRIPTION
              "Information about a particular community string."
          INDEX       { snmpCommunityIndex }
          ::= { snmpCommunityTable 1 }

      SnmpCommunityEntry ::= SEQUENCE {
          snmpCommunityIndex               Integer32,               SnmpAdminString,
          snmpCommunityName                OCTET STRING,
          snmpCommunitySecurityName        SnmpAdminString,
          snmpCommunityContextEngineID     SnmpEngineID,
          snmpCommunityContextName         SnmpAdminString,
          snmpCommunityTransportTag        SnmpTagValue,
          snmpCommunityStorageType         StorageType,
          snmpCommunityStatus              RowStatus
      }

      snmpCommunityIndex OBJECT-TYPE
          SYNTAX      Integer32      SnmpAdminString (SIZE(1..128))
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
              "The unique index value of a row in this table."
          ::= { snmpCommunityEntry 1 }

      snmpCommunityName OBJECT-TYPE
          SYNTAX       OCTET STRING (SIZE(1..64))
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "The community string for which a row in this table
               represents a configuration."
          ::= { snmpCommunityEntry 2 }

      snmpCommunitySecurityName OBJECT-TYPE
          SYNTAX       SnmpAdminString
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "A human readable string representing the corresponding
               value of snmpCommunityName in a Security Model
               independent format."
          ::= { snmpCommunityEntry 3 }

      snmpCommunityContextEngineID OBJECT-TYPE
          SYNTAX       SnmpEngineID
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "The contextEngineID indicating the location of the
               context in which management information is accessed
               when using the community string specified by the
               corresponding instance of snmpCommunityName.

               The default value is the snmpEngineID of the entity in
               which this object is instantiated."
          ::= { snmpCommunityEntry 4 }

      snmpCommunityContextName OBJECT-TYPE
          SYNTAX       SnmpAdminString
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "The context in which management information is accessed
               when using the community string specified by the corresponding
               instance of snmpCommunityName."
          DEFVAL      { ''H }   -- the empty string
          ::= { snmpCommunityEntry 5 }

   -- Comments on TransportTag
   --    based

      snmpCommunityTransportTag OBJECT-TYPE
          SYNTAX       SnmpTagValue
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "This object specifies a set of transport endpoints
               from which an agent will accept management requests.
               If a management request containing this community
               is received on a transport endpoint other than the
               transport endpoints identified by this object, the
               request is deemed unauthentic.

               The transports identified by this object are specified
               in the snmpTargetAddrTable.  Entries in that table
               whose snmpTargetAddrTagList contains this tag we can limit value
               are identified.

               If the use value of an this object has zero-length, transport
               endpoints are not checked when authenticating messages
               containing this community string."
          DEFVAL      { ''H }   -- the empty string
          ::= { snmpCommunityEntry 6 }

      snmpCommunityStorageType OBJECT-TYPE
          SYNTAX       StorageType
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "The storage type for this conceptual row in the
               snmpCommunityTable.  Conceptual rows having the value
               'permanent' need not allow write-access to any
               columnar object in the row."
          ::= { snmpCommunityEntry 7 }

      snmpCommunityStatus OBJECT-TYPE
          SYNTAX       RowStatus
          MAX-ACCESS   read-create
          STATUS       current
          DESCRIPTION
              "The status of this conceptual row in the snmpCommunityTable.

               An entry in this table is not qualified for activation
               until instances of all corresponding columns have been
               initialized, either through default values, or through
               Set operations.  The snmpCommunityName and
               snmpCommunitySecurityName objects must be explicitly set."
          ::= { snmpCommunityEntry 8 }

      --
      -- The snmpTargetAddrMaskTable augments the snmpTargetAddrTable with
      -- a transport address mask value.  This allows entries in the
      -- snmpTargetAddrTable to define a defined
   -- set of transport end-points. Maybe we want to augemnt the addresses instead of just
      --    snmpTargetAddrTable to also contain a snmpTargetAddrTMask single address.
      --

      snmpTargetAddrMaskTable OBJECT-TYPE
          SYNTAX       SEQUENCE OF SnmpTargetAddrMaskEntry
          MAX-ACCESS   not-accessible
          STATUS       current
          DESCRIPTION
              "The table of type TAddress which we can use as mask values associated with the
               snmpTargetAddrTable."
          ::= { snmpCommunityMIBObjects 2 }

      snmpTargetAddrMaskEntry OBJECT-TYPE
          SYNTAX       SnmpTargetAddrMaskEntry
          MAX-ACCESS   not-accessible
          STATUS       current
          DESCRIPTION
              "Information about a mask.
   --    Opinions are welcome.

   snmpCommunityTransportTag particular mask value."
          AUGMENTS       { snmpTargetAddrEntry }
          ::= { snmpTargetAddrMaskTable 1 }
      SnmpTargetAddrMaskEntry ::= SEQUENCE {
          snmpTargetAddrTMask              OCTET STRING
      }

      snmpTargetAddrTMask OBJECT-TYPE
          SYNTAX       SnmpTagValue      OCTET STRING (SIZE (1..255))
          MAX-ACCESS  read-create
          STATUS      current
          DESCRIPTION
           "This object specifies a set of transport endpoints
            from which
              "The mask value associated with an agent will accept management requests.
            If a management request containing this community
            is received on a transport endpoint other than the
            transport endpoints identified by this object, entry in the
            request is deemed unauthentic.
               snmpTargetAddrTable.  The transports identified by value of this object are specified
            in must
               be the snmpTargteAddrTable.  Entries in that table
            whose snmpTargetAddrTagList contains this tag value
            are identified.

            If same length as the corresponding instance of
               snmpTargetAddrTAddress.

               The value of this object has zero-length, transport
            endpoints are must be set before the
               corresponding value of snmpTargetAddrRowStatus may
               be set to active(1).

               This object may not checked when authenticating messages
            containing this community string."
       DEFVAL      { ''H }   -- be set while the empty string value of the
               corresponding instance of snmpTargetAddrRowStatus
               is active(1)."
          ::= { snmpCommunityEntry 6 snmpTargetAddrMaskEntry 1 }

   snmpCommunityStorageType

      --
      -- The snmpTrapAddress and snmpTrapCommunity objects are included
      -- in notifications that are forwarded by a proxy, which were
      -- originally received as SNMPv1 Trap messages.
      --

      snmpTrapAddress OBJECT-TYPE
          SYNTAX       StorageType      IpAddress
          MAX-ACCESS   read-create  accessible-for-notify
          STATUS      current
          DESCRIPTION
              "The storage type for this conceptual row in the
            snmpCommunityTable.  Conceptual rows having value of the agent-addr field of a Trap PDU which
               is forwarded by a proxy forwarder application using
               an SNMP version other than SNMPv1.  The value
            'permanent' need not allow write-access to any
            columnar of this
               object in SHOULD contain the row." value of the agent-addr field
               from the original Trap PDU as generated by an SNMPv1
               agent."
          ::= { snmpCommunityEntry 7 snmpCommunityMIBObjects 3 }

   snmpCommunityStatus

      snmpTrapCommunity OBJECT-TYPE
          SYNTAX       RowStatus      OCTET STRING
          MAX-ACCESS   read-create  accessible-for-notify
          STATUS      current
          DESCRIPTION
              "The status value of this conceptual row in the snmpCommunityTable.

            An entry in this table is not qualified for activation
            until instances community string field of all corresponding columns have been
            initialized, either through default values, or through
            Set operations. an SNMPv1
               message containing a Trap PDU which is forwarded by a
               a proxy forwarder application using an SNMP version
               other than SNMPv1.  The snmpCommunityName and
            snmpCommunitySecurityName objects must be explicitly set." value of this object SHOULD
               contain the value of the community string field from
               the original SNMPv1 message containing a Trap PDU as
               generated by an SNMPv1 agent."
          ::= { snmpCommunityEntry 8 snmpCommunityMIBObjects 4 }

      -- Conformance Information *******************************************

      snmpCommunityMIBCompliances OBJECT IDENTIFIER
                                  ::= { snmpCommunityMIBConformance 1 }
      snmpCommunityMIBGroups      OBJECT IDENTIFIER
                                  ::= { snmpCommunityMIBConformance 2 }

      -- Compliance statements

      snmpCommunityMIBCompliance MODULE-COMPLIANCE
          STATUS       current
          DESCRIPTION
              "The compliance statement for SNMP engines which
               implement the SNMP-COMMUNITY-MIB."

          MODULE       -- this module
              MANDATORY-GROUPS { snmpCommunityGroup }

              OBJECT           snmpCommunityName
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

              OBJECT           snmpCommunitySecurityName
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

              OBJECT           snmpCommunitySecurityLevel
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

              OBJECT           snmpCommunityContextEngineID
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

              OBJECT           snmpCommunityContextName
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."
              OBJECT           snmpCommunityTransportLabel           snmpCommunityTransportTag
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

              OBJECT           snmpCommunityStorageType
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

              OBJECT           snmpCommunityStatus
              MIN-ACCESS       read-only
              DESCRIPTION     "Write access is not required."

          ::= { usmMIBCompliances snmpCommunityMIBCompliances 1 }

      snmpCommunityGroup OBJECT-GROUP
          OBJECTS {
              snmpCommunityIndex,
              snmpCommunityName,
              snmpCommunitySecurityName,
              snmpCommunityContextEngineID,
              snmpCommunityContextName,
           snmpCommunityTransportLabel,
              snmpCommunityTransportTag,
              snmpCommunityStorageType,
           snmpCommunityStatus
              snmpCommunityStatus,
              snmpTargetAddrTMask
          }
          STATUS       current
          DESCRIPTION
              "A collection of objects providing for configuration
               of community strings for SNMPv1 or SNMPv2c (and SNMPv2c) usage."
          ::= { snmpCommunityMIBGroups 1 }

      END

9.

6.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

10.  Acknowledgments

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

       Dave Battle (SNMP Research, Inc.)
       Uri Blumenthal (IBM T.J. Watson Research Center)
       Jeff Case (SNMP Research, Inc.)
       John Curran (BBN)
       T. Max Devlin (Hi-TECH Connections)
       John Flick (Hewlett Packard)
       David Harrington (Cabletron Systems Inc.)
       N.C. Hien (IBM T.J. Watson Research Center)
       Dave Levi (SNMP Research, Inc.)
       Louis A Mamakos (UUNET Technologies Inc.)
       Paul Meyer (Secure Computing Corporation)
       Keith McCloghrie (Cisco Systems)
       Russ Mundy (Trusted Information Systems, Inc.)
       Bob Natale (ACE*COMM Corporation)
       Mike O'Dell (UUNET Technologies Inc.)
       Dave Perkins (DeskTalk)
       Peter Polkinghorne (Brunel University)
       Randy Presuhn (BMC Software, Inc.)
       David Reid (SNMP Research, Inc.)
       Shawn Routhier (Epilogue)
       Juergen Schoenwaelder (TU Braunschweig)
       Bob Stewart (Cisco Systems)
       Bert Wijnen (IBM T.J. Watson Research Center)

   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team. Members of
   that Advisory Team were:

       David Harrington (Cabletron Systems Inc.)
       Jeff Johnson (Cisco Systems)
       David Levi (SNMP Research Inc.)
       John Linn (Openvision)
       Russ Mundy (Trusted Information Systems) chair
       Shawn Routhier (Epilogue)
       Glenn Waters (Nortel)
       Bert Wijnen (IBM T. J. Watson Research Center)

   As recommended by to the Advisory Team and IETF Executive
   Director.

7.  Acknowledgments

   This document is the result of the efforts of the SNMPv3 Working Group
   Charter, the
   Group.  The design of the SNMP-COMMUNITY-MIB incorporates as much as practical from previous
   RFCs and drafts. As a result, special thanks are due to work done
   by the authors of previous designs known as SNMPv2u and SNMPv2*:

       Jeff Case (SNMP Research, Inc.)
       David Harrington (Cabletron Systems Inc.)
       David Levi (SNMP Research, Inc.)
       Keith McCloghrie (Cisco Systems)
       Brian O'Keefe (Hewlett Packard)
       Marshall T. Rose (Dover Beach Consulting)
       Jon Saperia (BGS Systems Inc.)
       Steve Waldbusser (International Network Services)
       Glenn W. Waters (Bell-Northern Research Ltd.)

11.

8.  Security Considerations

   Although SNMPv1 and SNMPv2 do not provide any security, allowing
   community names to be mapped into securityName/contextName provides
   the ability to use view-based access control to limit the access of
   unsecured SNMPv1 and SNMPv2 operations.  In fact, it is important for
   network administrators to make use of this capability in order to
   avoid unauthorized access to MIB data that would otherwise be secure.

12.

   Further, the SNMP-COMMUNITY-MIB has the potential to expose community
   strings which provide access to more information than that which is
   available using the usual 'public' community string.  For this
   reason, a security administrator may wish to limit accessibility to
   the SNMP-COMMUNITY-MIB, and in particular, to make in inaccessible
   when using the 'public' community string.

   When a proxy implementation translates messages between SNMPv1 (or
   SNMPv2c) and SNMPv3, there may be a loss of security.  For example,
   an SNMPv3 message received using authentication and privacy which is
   subsequently forwarded using SNMPv1 will lose the security benefits
   of using authentication and privacy.  Careful configuration of
   proxies is required to address such situations.  One approach to deal
   with such situations might be to use an encrypted tunnel.

9.  References

[RFC1155]

[1]  Rose, M. and K. McCloghrie, "Structure and Identification of
     Management Information for TCP/IP-based internets"", STD16, RFC
     1155, May 1990.

[RFC1157]

[2]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", STD15, RFC 1157, SNMP Research, Performance
     Systems International, Performance Systems International, MIT
     Laboratory for Computer Science, May 1990.

[RFC1212]

[3]  McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions.nr
     _F 1 q, Definitions",
     STD 16, RFC 1212, Hughes LAN Systems, Performance Systems
     International, March 1991.

[RFC1213]

[4]  Rose, M. T., "A Convention for Defining Traps for use with the
     SNMP", RFC 1215, March 1991.

[5]  McCloghrie, K., and M. Rose, Editors, "Management Information Base "A Convention for Network Management of TCP/IP-based internets: MIB-II", STD 17, Describing SNMP-
     based Agents", RFC 1213, 1303, Hughes LAN Systems, Performance Systems International,
     March 1991.

[RFC1901] Dover Beach
     Consulting, Inc., February 1992.

[6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Introduction to Community-based SNMPv2", RFC1902, RFC1901, SNMP
     Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network Services, January 1996.

[RFC1902]

[7]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Structure of Management Information for Version 2 of
     the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP
     Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network Services, January 1996.

[RFC1903]

[8]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Textual Conventions for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc.,
     Cisco Systems, Inc., Dover Beach Consulting, Inc., International
     Network Services, January 1996.

[RFC1905]

[9]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Conformance Statements for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.

[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
     Cisco Systems, Inc., Dover Beach Consulting, Inc., International
     Network Services, January 1996.

[RFC1907]

[11] 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.

[12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Management Information Base for Version 2 of the
     Simple Network Management Protocol (SNMPv2)", RFC1905, RFC1907, SNMP
     Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network Services, January 1996.

[RFC1908]

[13] 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", RFC1905, RFC1908, SNMP
     Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network Services, January 1996.

[RFC2271]

[14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi-
     lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January
     1997.

[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
     Architecture for Describing SNMP Management Frameworks", RFC2271,
     January draft-
     ietf-snmpv3-arch-01.txt, September 1998.

[RFC2272]

[17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
     "Message Processing and Dispatching for the Simple Network
     Management Protocol (SNMP)", RFC2272, January draft-ietf-snmpv3-mpc-01.txt,
     September 1998.

[RFC2273]

[18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMPv3 "SNMP
     Applications", RFC2273, January draft-ietf-snmpv3-appl-v2-01.txt, September 1998.

[RFC2274]

[19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-
     Based Security Model for Version 3 of the Simple Network Management
     Protocol (SNMP)", RFC2274, January draft-ietf-snmpv3-usm-v2-02.txt, September 1998.

[RFC2275]

[20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K.,
     "View-based Access Control Model for the Simple Network Management
     Protocol (SNMP)", RFC2275, January draft-ietf-snmpv3-vacm-01.txt, September 1998.

13.

10.  Editor's Address

     Rob Frye
     MCI Communications Corp.
     2100 Reston Parkway, Suite 600
     Reston, VA 20191
     U.S.A.
     Phone: +1 703 715 7225
     EMail: Rob.Frye@mci.com

     David B. Levi
     SNMP Research, Inc.
     3001 Kimberlin Heights Road
     Knoxville, TN 37920-9716
     U.S.A.
     Phone: +1 423 573 1434
     EMail: levi@snmp.com

     Shawn A. Routhier
     Integrated Systems Inc.
     333 North Ave 4th Floor
     Wakefield MA 01880
     U.S.A.
     Phone: + 1 781 245 0804
     EMail: sar@epilogue.com

     Bert Wijnen
     IBM T. J. Watson Research
     Schagen 33
     3461 GL Linschoten
     Netherlands
     Phone: +31 348 432 794
     EMail: wijnen@vnet.ibm.com
   A.  Full Copyright Statement

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.