Internet Draft     Coexistence between SNMP versions          7 Aug 1998


INTERNET-DRAFT                                                  Rob Frye
                                                MCI Communications Corp.
                                                           David B. Levi
                                                     SNMP Research, Inc.
                                                             Bert Wijnen
                                                IBM T.J. Watson Research
                                                              7 Aug 1998


        Coexistence between Version 1, Version 2, and Version 3
         of the Internet-standard Network Management Framework
                    <draft-ietf-snmpv3-coex-00.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.
















SNMPv3 Working Group     Expires February 1999            [Page 1]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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 (SNMPv3), version 2 of
   the Internet-standard Network Management Framework [RFC1901], termed
   the SNMP version 2 framework (SNMPv2), and the original Internet-
   standard Network Management Framework (SNMPv1) [RFC1157].











































SNMPv3 Working Group     Expires February 1999            [Page 2]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


   Table Of Contents


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



SNMPv3 Working Group     Expires February 1999            [Page 3]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


1.  Overview

   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 (SNMPv3), version 2 of
   the Internet-standard Network Management Framework [RFC1901], termed
   the SNMP version 2 framework (SNMPv2), and the original Internet-
   standard Network Management Framework (SNMPv1) [RFC1157].

   There are five 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 is
          documented in section 4.

       -  Approaches to coexistence between SNMPv1, SNMPv2, and SNMPv3
          entities in a multi-lingual network is documented in section
          5.

       -  Processing of protocol operations in multi-lingual
          implementations is documented in section 6.

       -  The Community-Based Security Model, which provides mechanisms
          for adapting SNMPv1 and SNMPv2 into the SNMPv3 view-based
          access control, is documented in section 8.



1.1.  SNMPv1   SNMPv1 is defined by these three documents:

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

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

       -  STD 15, RFC 1157 [RFC1157] which defines the Simple Network
          Management Protocol (SNMP), 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?)





SNMPv3 Working Group     Expires February 1999            [Page 4]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


1.2.  SNMPv2

   SNMPv2 is defined by these six documents:

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

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

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

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

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

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

   In addition, the following three documents augment the definition of
   SNMPv2:

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

       -  RFC 2011 defines the IP MIB using SMIv2.


1.3.  SNMPv3   SNMPv3 is defined by the these five documents:

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

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

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

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






SNMPv3 Working Group     Expires February 1999            [Page 5]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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

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













































SNMPv3 Working Group     Expires February 1999            [Page 6]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


2.  SMI and Management Information Mappings

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

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

   MIB modules defined using the SNMPv1 framework may continue to be
   used with the SNMPv2 protocol.  However, for the MIB modules to
   conform to the SNMPv2 framework, the following changes are required:


2.1.  Object Definitions

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

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

(2)  The MODULE-IDENTITY macro 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 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.






SNMPv3 Working Group     Expires February 1999            [Page 7]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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

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

(9)  For all objects, the ACCESS clause must be replaced by a MAX-ACCESS
     clause.  The value of the MAX-ACCESS clause is 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 have a MAX-ACCESS clause of "read-create".  If
     the value of the ACCESS clause is "write-only", then the value of
     the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause
     notes that reading this object will result implementation-specific
     results.

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

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

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

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

(14) 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 changed to "obsolete".

(15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
     value which is expressed as a collection of sub-identifiers, change
     the value 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.  The SNMPv2 and SNMPv3 frameworks correct 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





SNMPv3 Working Group     Expires February 1999            [Page 8]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


     objects relating to those tables and replace them with objects
     defined using the new approach.

(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 be defined.

(3)  For all textual conventions informally defined in the MIB module,
     it is recommended that those conventions using the TEXTUAL-
     CONVENTION macro be redefined.  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 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 be used in place of the
     INDEX clause for the object corresponding to the conceptual row
     which is an extension.

   Finally, when encountering common errors in SNMPv1 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 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 changed to
     "obsolete".



2.2.  Trap Definitions

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

(1)  The IMPORTS statement must not reference RFC-1215, and should
     reference SNMPv2-SMI instead.





SNMPv3 Working Group     Expires February 1999            [Page 9]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


(2)  The ENTERPRISE clause must be removed.

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

(4)  The STATUS clause 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 be changed accordingly.
     Specifically, if the value of the ENTERPRISE clause is not 'snmp'
     then the value of the invocation is 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 be added, if not already present.

(7)  One or more NOTIFICATION-GROUPs should be defined, and related
     notifications 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 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 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] 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 requires these changes:

(1)  Use the macro name AGENT-CAPABILITIES instead of MODULE-
     CONFORMANCE.

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

(3)  For all occurrences of the CREATION-REQUIRES clause, note the
     slight change in semantics, and omit this clause if appropriate.





SNMPv3 Working Group     Expires February 1999           [Page 10]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


   In order to ease the coexistence between SNMPv1, SNMPv2, and SNMPv3,
   object groups defined in an SMIv1 compliant MIB module may be
   referenced by the INCLUDES clause of an invocation of the AGENT-
   CAPABILITIES macro: upon encountering a reference to an OBJECT
   IDENTIFIER subtree defined in an SNMPv1 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 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.)








































SNMPv3 Working Group     Expires February 1999           [Page 11]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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.


























SNMPv3 Working Group     Expires February 1999           [Page 12]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


4.  Translating Notifications Between SNMP Formats

   This section describes how data contained in a notification is
   translated between the SNMPv1 format and the SNMPv2 format.  There
   are two parts to the format of a notification, the SMI version used
   to define the notification, and the format of parameters used to
   represent a generated notification.

   The SMI version used to define a notification will generally
   determine the format of parameters used when a notification is
   generated by MIB instrumentation.  There are two formats for
   parameters, those used in an SNMPv1 notification, and those used in
   an SNMPv2 notification.  These 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 format, and the
          configuration of the entity indicates that the notification
          must be sent using a protocol version that requires
          notification parameters in the other SNMP format.

       -  When a proxy receives a notification in one SNMP format, and
          must forward the notification using a protocol version that
          requires a different SNMP format.

   In addition, it 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 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).






SNMPv3 Working Group     Expires February 1999           [Page 13]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


       -  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.

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

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



4.1.  Translating SNMPv1 Format to SNMPv2 Format

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

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

(2)  If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the
     SNMPv2 snmpTrapOID value is 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 the corresponding trap as defined
     in [RFC1907].

(4)  The SNMPv2 variable-bindings is the SNMPv1 variable-bindings with a
     single variable-binding appended.  The name portion of this
     variable binding contains snmpTrapEnterprise.0 [RFC1907], and the
     value is the SNMPv1 enterprise value.

(5)  The value of the agent-addr field is lost when converting
     notification parameters from SNMPv1 to SNMPv2.










SNMPv3 Working Group     Expires February 1999           [Page 14]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


4.2.  Translating SNMPv2 Format to SNMPv1 Format

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

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

       -  If the SNMPv2 snmpTrapOID value is one of the standard traps
          as defined in [RFC1907], then the SNMPv1 enterprise value is
          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 set to the value 'snmpTraps' as defined in
          RFC1907 [RFC1907].

       -  If the SNMPv2 snmpTrapOID value is not one of the standard
          traps as defined in [RFC1907], then the SNMPv1 enterprise
          value is 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 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 the SMIv2
              snmpTrapOID with the last sub-identifier removed.

(2)  The SNMPv1 agent-addr value is 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 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 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 this source was an IP or UDP address, that
          address is used for the SNMPv1 agent-addr value.  Otherwise,
          the SNMPv1 agent-addr value is set to 0.0.0.0.

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





SNMPv3 Working Group     Expires February 1999           [Page 15]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


               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 set to 6.

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

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

(6)  The SNMPv1 variable-bindings is 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 variable-binding whose type is Counter64 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 be forwarded





SNMPv3 Working Group     Expires February 1999           [Page 16]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


          using other SNMP versions.


4.3.1.  discussion about additional varbinds (agent_addr, community)















































SNMPv3 Working Group     Expires February 1999           [Page 17]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


5.  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.  Multi-lingual implementations

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



5.1.1.  Command Generator

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

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



5.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:





SNMPv3 Working Group     Expires February 1999           [Page 18]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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

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

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

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

   Details about how a command responder handles these requirements are
   provided in section 6.



5.1.3.  Notification Originator

   A notification originator must be able to translate notifications
   between 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 that notifications be sent using SNMPv2c or SNMPv3, the
   notification must be translated to the SNMPv2 format.  Likewise, if
   instrumentation presents a notification in the SNMPv2 format and
   configuration information specifies that notifications be sent using
   SNMPv1, the notification must be translated to the SNMPv1 format.



5.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 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 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 is
   accomplished in a proxy forwarding application by performing





SNMPv3 Working Group     Expires February 1999           [Page 19]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


   translations on a PDU in the following situations:

       -  If a GetBulkRequest-PDU is received and must be forwarded
          using the SNMPv1 message format, the proxy forwarder sets the
          non-repeaters and max-repetitions fields to 0, and sets 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 format, the proxy forwarder will
          remove the contents of the variable-bindings field before
          forwarding the response.

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

       -  If an SNMPv2-Trap-PDU is received, and will be forwarded using
          the SNMPv1 message format, the proxy will apply the
          translation rules described in section 4, 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 the
          SNMPv1 message format, is ignored.  An InformRequest-PDU can
          only be forwarded using the SNMPv2c or SNMPv3 message format.
























SNMPv3 Working Group     Expires February 1999           [Page 20]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


6.  Multi-Lingual Command Responder Behaviour

   The following sections describe the behaviour of a command responder
   application which supports multiple SNMP message formats, and which
   has access to some combination of SNMPv1 and SNMPv2 MIB
   instrumentation.



6.1.  Mapping SMIv2 into SMIv1

   The SMIv2 [RFC1902] defines one new syntax that 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 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 object
   instances whose type is Counter64 are implicitly excluded from view
   when processing an SNMPv1 message.  So:

       -  On an SNMPv1 GET request, we return an error-status of
          noSuchName and the error-index is set to the variable binding
          that causes this error.

       -  On an SNMPv1 GETNEXT request, we skip the object instance 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 from a SNMPv2 manager, and so it should
          not cause a problem.  If we do receive a Counter64 value in an
          SNMPv1 SET packet, it should result in an ASN.1 parse error
          since Counter64 is not valid in the SNMPv1 protocol. When an
          ASN.1 parse error occurs, the counter snmpInASNParseErrs is
          incremented and no response is returned.


6.2.  Mapping SNMPv2 Exceptions

   SNMPv2 provides a feature called exceptions, which allow an 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





SNMPv3 Working Group     Expires February 1999           [Page 21]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


   management information, 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 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.

       -  No exceptions will be returned for a SetRequest, and a
          GetBulkRequest should only be received in 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 the
   response PDU should be set to noSuchName.  Also, the error-index
   field is set to the index of the variable binding for which an
   exception occurred, and the variable binding list from the original
   request is returned with the response PDU.

   Note that when a response contains multiple exceptions, it is an
   implementation choice as to which 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 that there are no
   object instances available which lexicographically follow the object
   in the request. In an SNMPv1 agent, this condition normally results





SNMPv3 Working Group     Expires February 1999           [Page 22]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


   in a noSuchName error, and so the error-status field of the response
   PDU should be set to noSuchName. Also, the error- index field is set
   to the index of the variable binding for which an exception occurred,
   and the variable binding list from the original request is returned
   with the response PDU.

   Note that when a response contains multiple exceptions, 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,

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

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

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

(2)  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 such variable bindings, then for the
     one chosen:

       -  Set the error-status to noSuchName

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





SNMPv3 Working Group     Expires February 1999           [Page 23]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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

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

       -  Set the error-status to noError

       -  Set the error-index to zero

       -  Compose the variable binding list of the response, using the
          data as it is returned by the instrumentation code.



6.4.  Processing An SNMPv1 GetNextRequest

   When processing an SNMPv1 GetNextRequest, the following procedures
   should be followed when SNMPv2 MIB instrumentation is called as part
   of processing the request.  There may be repetitive calls to
   (possibly different pieces of) instrumentation code 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 instrumentation.
   Data returned from SNMPv1 instrumentation may be treated in the
   normal manner for an SNMPv1 request.

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

(1)  The error status is translated to an SNMPv1 error-status using the
     table in section 7, "Mapping SNMPv2 error-status into SNMPv1
     error-status"

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

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

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

(1)  If there are any variable bindings containing an SNMPv2 syntax of
     Counter64, then consider these variable bindings to be not in view
     and repeat the call to the instrumentation code as often as needed
     until a value other than Counter64 is returned.





SNMPv3 Working Group     Expires February 1999           [Page 24]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


(2)  Find any variable binding that contains an SNMPv2 exception
     endOfMibView.  (Note that if there are more than one, the agent may
     choose any such variable binding.)  If there are any such variable
     bindings, then for the one chosen:

       -  Set the error-status to noSuchName

       -  Set the error-index to the position (in the variable binding
          list of the original request) of the variable binding that
          returned such an SNMPv2 exception.

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

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

       -  Set the error-status to noError

       -  Set the error-index to zero

       -  Compose the variable binding list of the response, using the
          data as it is returned by the instrumentation code.




























SNMPv3 Working Group     Expires February 1999           [Page 25]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


7.  Error Status Mappings

   The following table shows 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

























SNMPv3 Working Group     Expires February 1999           [Page 26]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


8.  Message Processing Models and Security Models

In order to adapt SNMPv1 and SNMPv2c into the SNMPv3 architecture, four
additional models must be defined:

       -  The SNMPv1 Message Processing Model

       -  The SNMPv2c Message Processing Model

       -  The SNMPv1 Community-Based Security 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.


8.1.  Mappings

The SNMPv1 and SNMPv2c Message Processing Models and Security Models
require mappings between parameters used in SNMPv1 and SNMPv2c messages,
and those use in SNMPv3 messages.  The parameters which must be mapped
consist of the SNMPv1 and SNMPv2c community name, and the SNMPv3
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.


8.2.  Elements Of Procedure

The following sections describe the procedures for processing various
types of SNMPv1 and SNMPv2c messages.









SNMPv3 Working Group     Expires February 1999           [Page 27]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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

   SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       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





SNMPv3 Working Group     Expires February 1999           [Page 28]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


                     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:  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 }   -- 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)."





SNMPv3 Working Group     Expires February 1999           [Page 29]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


       ::= { 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,
       snmpCommunityName                OCTET STRING,
       snmpCommunitySecurityName        SnmpAdminString,
       snmpCommunityContextEngineID     SnmpEngineID,
       snmpCommunityContextName         SnmpAdminString,
       snmpCommunityTransportTag        SnmpTagValue,
       snmpCommunityStorageType         StorageType,
       snmpCommunityStatus              RowStatus
   }

   snmpCommunityIndex OBJECT-TYPE
       SYNTAX      Integer32
       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."





SNMPv3 Working Group     Expires February 1999           [Page 30]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


       ::= { 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 on this tag we can limit the use of an entry to a defined
   --    set of transport end-points. Maybe we want to augemnt the
   --    snmpTargetAddrTable to also contain a snmpTargetAddrTMask
   --    of type TAddress which we can use as a mask.
   --    Opinions are welcome.

   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





SNMPv3 Working Group     Expires February 1999           [Page 31]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


            in the snmpTargteAddrTable.  Entries in that table
            whose snmpTargetAddrTagList contains this tag value
            are identified.

            If the value of 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 }

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

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

   -- Compliance statements

   snmpCommunityMIBCompliance MODULE-COMPLIANCE
       STATUS       current
       DESCRIPTION





SNMPv3 Working Group     Expires February 1999           [Page 32]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


           "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
           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 1 }

   snmpCommunityGroup OBJECT-GROUP
       OBJECTS {
           snmpCommunityIndex,
           snmpCommunityName,
           snmpCommunitySecurityName,
           snmpCommunityContextEngineID,
           snmpCommunityContextName,





SNMPv3 Working Group     Expires February 1999           [Page 33]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


           snmpCommunityTransportLabel,
           snmpCommunityStorageType,
           snmpCommunityStatus
       }
       STATUS       current
       DESCRIPTION
           "A collection of objects providing for configuration
            of community strings for SNMPv1 or SNMPv2c usage."
       ::= { snmpCommunityMIBGroups 1 }

   END








































SNMPv3 Working Group     Expires February 1999           [Page 34]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


9.  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.






























SNMPv3 Working Group     Expires February 1999           [Page 35]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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 the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts. As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:





SNMPv3 Working Group     Expires February 1999           [Page 36]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


       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.)










































SNMPv3 Working Group     Expires February 1999           [Page 37]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


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











































SNMPv3 Working Group     Expires February 1999           [Page 38]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


12.  References

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

[RFC1157]
     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]
     McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions.nr
     _F 1 q, STD 16, RFC 1212, Hughes LAN Systems, Performance Systems
     International, March 1991.

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

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

[RFC1902]
     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]
     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]
     SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Protocol Operations for Version 2 of the Simple





SNMPv3 Working Group     Expires February 1999           [Page 39]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


     Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
     Cisco Systems, Inc., Dover Beach Consulting, Inc., International
     Network Services, January 1996.

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

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

[RFC2271]
     The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
     Architecture for Describing SNMP Management Frameworks", RFC2271,
     January 1998.

[RFC2272]
     The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
     "Message Processing and Dispatching for the Simple Network
     Management Protocol (SNMP)", RFC2272, January 1998.

[RFC2273]
     The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMPv3
     Applications", RFC2273, January 1998.

[RFC2274]
     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 1998.

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










SNMPv3 Working Group     Expires February 1999           [Page 40]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


13.  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

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


























SNMPv3 Working Group     Expires February 1999           [Page 41]


Internet Draft     Coexistence between SNMP versions          7 Aug 1998


   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.


























SNMPv3 Working Group     Expires February 1999           [Page 42]