INTERNET DRAFT                        Expires April 23, 1993



                ISO/CCITT and Internet Management Coexistence (IIMC):

                       ISO/CCITT to Internet Management Proxy

                                     (IIMCPROXY)


                                   October 9, 1992


                                     April Chang

                                    NetLabs, Inc
                                 4920 El Camino Real
                                 Los Altos, CA 94022
                               april_chang@netlabs.com



            Status of this Memo

            This memo provides information to the network and systems
            management community.  This memo is not proposed to be a
            standard, but is intended as a contribution to ongoing work
            in the area of multi-protocol management coexistence and
            interworking.  This memo is part of a package of ISO/CCITT
            and Internet Management Coexistence (IIMC) drafts; see also
            [IIMCIMIBTRANS], [IIMCIMIB-II], [IIMCPARTY], and
            [IIMCOMIBTRANS].

            This document is an Internet Draft.  Internet Drafts are
            working documents of the Internet Engineering Task Force
            (IETF), its Areas, and its Working Groups.  Note that other
            groups may also distribute working documents as Internet
            Drafts.

            Internet Drafts are draft documents valid for a maximum of
            six months.  Internet Drafts may be updated, replaced, or
            obsoleted by other documents at any time.  It is not
            appropriate to use Internet Drafts as reference material or
            to cite them other than as a "working draft" or "work in
            progress".

            Please check the 1id-abstracts.txt listing contained in the
            internet-drafts Shadow Directories on nic.ddn.mil,
            nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au
            to learn the current status of any Internet Draft.

            Distribution of this memo is unlimited.  Comments on this
            memo should be sent to iimc@thumper.bellcore.com by November
            20, 1992.


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            Abstract

            This memo is intended to facilitate the use of the OSI
            Common Management Information Protocol (CMIP) for integrated
            management of networks via proxy management of TCP/IP
            networks that are managed using Simple Network Management
            Protocol (SNMP).  This memo describes a ISO/Internet "proxy"
            which allows interworking between CMIP-based managers and
            SNMP-based agents.  The proxy emulates CMIS service requests
            by mapping between corresponding ISO/CCITT GDMO and Internet
            MIB definitions, and generating SNMP message(s) needed to
            emulate the service.  The proxy also emulates CMIS service
            responses and notifications by converting incoming SNMP
            response and trap message(s) in a similar fashion.  Thus,
            the proxy appears as a CMIP-based agent to the manager, and
            as an SNMP-based manager to the agent.  The proxy depends on
            the availability of corresponding MIB definitions translated
            as described in [OIMMIBTRANS].


            Table of Contents

            Status of this Memo ......................................i
            Abstract .................................................ii
            Table of Contents ........................................ii
            1. Introduction ..........................................1
            1.1. Background ..........................................1
            1.2. Overview ............................................2
            1.3. Scope ...............................................3
            1.4. Terms and Conventions ...............................5
            2. ISO/Internet Proxy Configuration ......................6
            2.1. Schema Information ..................................6
            2.2. Proxy Objects and Party Objects .....................6
            2.3. Usage ...............................................8
            3. Elements of CMISE Service Emulation ...................9
            3.1. Association Service .................................9
            3.2. Management Object Selection .........................10
            3.3. Synchronization .....................................12
            3.4. Management Operation Services .......................13
            3.5. Management Notification Services ....................19
            3.6. Common Response Parameter ...........................19
            4. CMIP and SNMP Protocol Mapping ........................20
            4.1. Management Object Selection .........................20
            4.2. Check for Existence of the Object ...................21
            4.3. Create With Referenced Object .......................23
            4.4. Perform the Get Operation ...........................23
            4.5. Perform the Set Operation ...........................23
            4.6. Perform the Create Operation ........................23
            4.7. Perform the Delete Operation ........................24
            4.8. Form a Variable Binding .............................24
            4.9. SNMP error to CMIP error mapping ....................25
            5. CMIP Processing Failure ...............................26
            6. Functional Units ......................................27
            7. Abbreviations .........................................28


            Chang                                                Page ii


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            8. Acknowledgements ......................................28
            Appendix A: CMIP to RFC 1157 Agent proxy .................29
            Appendix B: Example Operation ............................31





















































            Chang                                               Page iii


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992



            1. Introduction

            1.1. Background

            This memo is part of a package of ISO/CCITT and Internet
            Management Coexistence (IIMC) drafts.  Other memos included
            in this package are:

              -Translation of Internet MIBs to ISO/CCITT GDMO MIBs
               (LaBarre) [IIMCIMIBTRANS]
              -Translation of ISO/CCITT GDMO MIBs to Internet MIBs
               (Newnan) [IIMCOMIBTRANS]
              -Translation of Internet MIB-II (RFC1213) to ISO/CCITT
               GDMO MIB (LaBarre) [IIMCMIB-II]
              -Translation of Internet Party MIB (RFC1353) to ISO/CCITT
               GDMO MIB (LaBarre) [IIMCPARTY]

            These memos together comprise a package aimed at integrating
            ISO/CCITT-based and Internet-based management systems.
            These memos are offered as input to coexistence and
            interworking efforts underway throughout the
            industry,including organizations such as:

              - IETF OSI Internet Management (OIM),
              - Network Management Forum Technology Convergence Team,
              - X/Open Systems Management (SysMan),
              - OIW Network Management Special Interest Group (NMSIG),
            and
              - OSF Management Special Interest Group (MANSIG).

            This work was initiated, in part, by NM Forum efforts to
            translate RFC 1214 for use with OMNIPoint 1 implementations.
            Through this effort, it became obvious that end-to-end
            management requires an integrated, unified view of the
            managed network, despite differences in management protocol
            and information structure.  Integrated management can be
            facilitated by the development of "proxy" mechanisms which
            translate between functionally equivalent service, protocol,
            and  SMI differences to create this unified view.  MIB
            translation procedures can be used to support proxy
            management, as well as to take advantage of existing MIB
            definition and avoid duplication of effort.  In this way,
            commercial investment in both ISO/CCITT and Internet-based
            management technologies can be preserved through deployment
            of common methods and tools which support integration.

            This overall strategy was outlined in a joint publication
            developed by the NM Forum and X/Open entitled "ISO/CCITT and
            Internet Management: Coexistence and Interworking Strategy"
            [NMFMC92].  The memos included in the IIMC package are
            intended as detailed specifications which implement several
            of the methodologies identified in this strategy.



            Chang                                                 Page 1


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            1.2. Overview

            The basic model for ISO/CCITT-Internet proxy management is
            illustrated in the following diagram.

                  Manager             Proxy                 Agent
            +-----------------+ +----------------+ +-------------------+
            |+---------------+| |+----++--------+| | +---------------+ |
            ||  Management   || ||GDMO||Internet|| | |    Managed    | |
            || Applications  || ||MIB ||  MIB   || | |   Resources   | |
            |+---------------+| |+----++--------+| | +---------------+ |
            |    |            | |+--------------+| |     |             |
            |    |            | ||   Service    || |     |             |
            |    |            | ||  Emulation   || |     |             |
            |    |            | ||(scoping)     || |     |             |
            |    |            | || (filtering)  || |     |             |
            |    |            | ||  (operations)|| |     |             |
            |+---------+-----+| |+--------------+| |+--------+--------+|
            ||ISO/CCITT|GDMO || || Map Protocols | ||Internet|Internet||
            || Manager |MIB  || ||CMIS|    |SNMP|| || Agent  |  MIB   ||
            |+---------+-----+| |+----+----+----+| |+--------+--------+|
            |   |             | |  |CMIS      |  | |   |               |
            |   |CMIS Services| |  |Services  |  | |   |SNMP "Services"|
            |   |             | |  |          |  | |   |               |
            |   |             | |  |      SNMP|  | |   |               |
            |   |             | |  |"Services"|  | |   |               |
            +-----------------+ +----------------+ +-------------------+
            |       CMIP      | |  CMIP |  SNMP  | |       SNMP        |
            +-----------------+ +----------------+ +-------------------+
                     ^               ^      ^               ^
                     |               |      |               |
                     +---------------+      +---------------+
                       CMIP Messages          SNMP Messages


            The proxy architecture provides emulation of CMIS services
            by mapping to the corresponding SNMP message(s) necessary to
            carry out the service request.  The service emulation allows
            management of Internet objects by an ISO/CCITT manager.  The
            left hand side of the proxy behaves like an ISO/CCITT agent,
            communicating with the ISO/CCITT manager using CMIP
            protocols.  The right hand side  of the proxy behaves like
            an Internet manager, communicating with the Internet agent
            using SNMP protocols.

            The proxy relies on the existence of a pair of directly-
            related MIB definitions, where the Internet MIB has been
            translated into ISO/CCITT GDMO using the procedures
            specified in [OIMMIBTRANS]. The proxy defined in this memo
            uses these MIB definitions and rules to provide run-time
            translation of management information carried in service
            requests and responses.




            Chang                                                 Page 2


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            The proxy architecture is designed with a specified
            interface between the proxy and the underlying protocol
            stacks, and so deals primarily in terms of CMIS services and
            SNMP "services".  The proxy emulates services such as CMIS
            scoping and filtering, processing of CMIS operations, and
            forwarding/logging of CMIS notifications by performing a
            mapping process which must be tailored for each protocol
            (for example, SNMP, Secure SNMP, and SNMP-2 are all variants
            of the same protocol mapping process).

            Finally, [IIMCOMIBTRANS] specifies translation procedures
            for converting ISO/CCITT GDMO MIBs into Internet MIBs.  MIBs
            generated by this translation process cannot be utilized by
            the Proxy defined in this memo, although another kind of
            Proxy could be defined for this purpose in the future.

            1.3. Scope

            The intent of the memo is to facilitate the use of CMIP to
            perform integrated management of networks via proxy
            management networks that are managed using SNMP.  There are
            two major differences between the CMISE and SNMP services:
            one is the object model; and the other is the operations
            supported by the protocols.  The ISO/Internet proxy
            architecture as shown in the above picture provides the
            CMISE service emulation.  In another words, the ISO/Internet
            proxy acts as a CMIP agent with respect to the CMIP manager,
            allowing management of Internet objects by the ISO/CCITT
            manager.  The CMIP requests would be processed by the
            ISO/Internet proxy and CMIP responses would be returned by
            the ISO/Internet proxy.  SNMP traps would be converted to
            CMIP notifications by the ISO/Internet proxy.  The
            implementation of the CMISE service emulation requires that
            a mapping exist between ISO/CCITT objects and Internet
            objects.  There are different approaches that can be used to
            map between Internet objects and ISO/CCITT objects.

                 1) Direct Translation
                 2) Abstract Translation

            The direct translation approach maps each Internet object to
            a newly defined ISO/CCITT object that contains: 1) the same
            information as contained in the Internet object; and 2) the
            attributes that are inherited from the  ISO/CCITT Top object
            class.

            The abstract approach maps the Internet objects to
            previously defined ISO/CCITT objects.  For example, the MIB-
            II system object could be represented by the ISO/CCITT
            system object.  No new object classes or attributes are
            needed with this approach.

            Either or both approaches could be used by a ISO/CCITT
            manager to manage Internet agents.  However, a large number


            Chang                                                 Page 3


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            of Internet MIBs have been defined by the Internet community
            using the Internet SMI [RFC1155] and it is quite possible
            that there is no equivalent ISO/CCITT objects defined for
            some of the Internet MIBs at this point of time.  For
            example, an Internet object and an ISO/CCITT object might be
            defined by different groups, and the attributes in the two
            objects could be significantly different.  The mapping
            between the two objects could be very difficult, if it not
            impossible to perform.

            This memo uses the "direct translation" approach".

            To perform the CMISE service emulation, the ISO/Internet
            proxy can use either of the following two approaches to
            retrieve or modify Internet MIB information:

                 1. State-less approach
                 2. Stateful approach

            The state-less approach would not maintain the Internet
            agent's MIB data.  For each CMIP request, the ISO/Internet
            proxy would perform one or more SNMP requests.

            The stateful approach would be to replicate the proxied
            agent's MIB data.  The ISO/Internet proxy would replicate
            the Internet agent's MIB data locally.  For each CMIP
            request, the ISO/Internet proxy would fulfill the request
            using data in its own local copy of the Internet MIBs.

            The stateful approach will usually provide better response
            time, but has the drawback that the data retrived might not
            be up to date.  This approach also requires a data
            synchronization mechanism between the ISO/Internet proxy and
            the proxied Internet agents.  The frequency at which the MIB
            data in the ISO/Internet proxy is updated would have a
            significant effect on the accuracy of the response.

            This memo uses the first approach.  With that approach the
            ISO/Internet proxy performs the following operations:
            translation of CMIP requests to SNMP requests; translation
            of SNMP responses to CMIP responses; and translation of SNMP
            traps to CMIP notifications.

            If necessary, the Internet MIB data retrived by the
            ISO/Internet proxy could be cached by the proxy in order to
            increase the response time of an operation.  This memo makes
            no assumption that the proxy is maintaining any state
            information, and so takes no advantage of information which
            might be cashed.

            This memo describes a protocol mapping process based on the
            IS CMIP (ISO/IEC 9596-2;1991) and on secure SNMP (RFC 1351 -
            RFC 1353).  A protocol mapping process based on IS CMIP and
            RFC 1157 SNMP would be slightly different from the IS CMIP


            Chang                                                 Page 4


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            to secure SNMP mapping process.  These differences are
            described in Appendix A of this memo.

            This memo assumes that the the CMIP PDU and SNMP PDU
            received by the ISO/Internet proxy are always properly
            encoded.  The uderlying protocol providers should ensure the
            correctness of the service indications and confirmations
            that are passed up to the ISO/Internet proxy.

            1.4. Terms and Conventions

            1.4.1 ISO/CCITT manager: An application entity that
                  implements ISO/IEC 9596-2;1991.

            1.4.2 Internet agent: An application entity that is
                  conformant to RFC 1352.

            1.4.3 ISO/Internet Proxy: An application entity that is
                  responsible of mapping CMIP requests to SNMP
                  requests, SNMP responses to CMIP responses, and SNMP
                  traps to CMIP notifications among any number of
                  ISO/CCITT managers and Internet agents.

            1.4.4 Known Internet agents: A set of one or more Internet
                  agents that a ISO/Internet proxy has knowledge of.
                  The known Internet agents could be represented by
                  proxy object instances.  The SNMP proxy object class
                  is defined in [OIMTRANSMIB].

            1.4.5 Known SNMP Parties: A set of one or more SNMP parties
                  that a ISO/Internet proxy has knowledge of.  The
                  known SNMP parties could be represented by the SNMP
                  party object instances.  The SNMP party Object is
                  defined in [OIMPARTY].

            1.4.6 Pseudo Object: A CMIP object class that represents an
                  SNMP group.  The pseudo object does not contain any
                  SNMP attributes.  For example: a CMIP object that
                  represents "at" in MIB-II, or any CMIP objects
                  representing SNMP tables.

            1.4.7 Access Policy: The SNMP version and the security
                  policy.

            1.4.8 Multiple Instance Object: An object class that may
                  have more than one object instance.  For example,
                  SNMP table entries.

            1.4.9 Delete Information: Delete information is the object
                  identifier of the attribute and its attribute value
                  used to indicate a particular row of a table is
                  deleted.




            Chang                                                 Page 5


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            2.   ISO/Internet Proxy Configuration

            In order for the ISO/Internet proxy to access each proxied
            Internet agent, and to access the proxied agents using the
            appropriate transport and network address, and using the
            appropriate access policy, the ISO/Internet proxy is
            required to have some knowledge about the proxied Internet
            agents.

            2.1. Schema Information

            To perform CMISE service emulation, the ISO/Internet proxy
            requires schema information for all of the Internet MIB
            definitions supported by a proxied agent.  The schema
            information could be described to the ISO/Internet proxy
            using ISO/CCITT GDMO.  Name binding definitions and matching
            rules are required if scoping and filtering are supported.
            The name binding definitions are needed to perform scoping
            and the matching rules are needed to perform filtering.

            A translation procedure for converting Internet MIB and
            Internet trap definitions into corresponding ISO/CCITT GDMO
            definitions is described in [OIMMIBTRANS].  The proxy
            describes in this memo requires as input the schema
            information for any Internet MIB translated to ISO/CCITT
            GDMO format using the [OIMMIBTRANS] procedures.

            The ISO/CCITT GDMO definitions based on RFC [OIMTRANSMIB]
            provide the object class, attribute, attribute syntax, name
            binding, and notification definitions.  If the ISO/CCITT
            object class maps to an SNMP table entry, the behaviour
            clause (as defined in 3.3.1 of [OIMTRANSMIB] would describe
            the following information that is required by the
            ISO/Internet proxy:

                    a) the attributes that form the object instance;
                    b) whether or not the object is a multiple instance
                      object (as defined in section 2.8 of this memo);
                      and
                    c) if the object is a multiple instance object, the
                      delete information for the object (as defined in
                      section 2.9 of this memo).

            2.2. Proxy Objects and Party Objects

            RFC [OIMPARTY] defines some local object classes that are
            required by the ISO/Internet proxy to perform the CMISE
            service emulation.

            The ISO/Internet proxy requires the following instances of
            the local object classes for each proxied Internet agent:

                 - one "cmipsxmpProxyEntry" object instance
                 - one "partyTable" object instance


            Chang                                                 Page 6


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


                 - one or more "partyEntry" object instances

            This memo refers to the above object instances as "local
            objects" or as "local object instances".

            The "cmipsxmpProxyEntry" object instance contains the
            proxied SNMP agent's name and serves as a containment
            object.  All the information related to a particular
            Internet agent would exist below the "cmipsxmpProxyEntry" in
            the managed information tree (MIT).  This information
            includes all the Internet MIB objects that belong to a
            particular Internet agent and any configuration information
            needed by the ISO/Internet proxy (such as a partyTable
            object).

            The "partyTable" object is the container object for all the
            "partyEntry's".  Only one "partyTable" object instance
            should be created below the "cmipsxmpProxyEntry" object
            instance.

            The "partyEntry" object contains the proxied Internet
            agent's address and the security mechanism used between the
            ISO/Internet proxy (acting as Internet manager) and the
            Internet agent.  The security mechanism could either be an
            SNMP 1157 community-based or a secure SNMP party-based
            mechanism.  A different "key" is stored in the "partyEntry"
            object, based on the chosen security mechanism.

            The information described in the preceding paragraphs must
            be available to the ISO/Internet proxy before any CMIP
            requests or SNMP traps can be processed by the ISO/Internet
            proxy.  The ISO/CCITT manager could provide this
            configuration information to the ISO/Internet proxy by
            sending M-Create requests to the ISO/Internet proxy in order
            to create the proxy and party objects.

            If the CMIP request to create an SNMP proxy object succeeds,
            the ISO/Internet proxy adds the SNMP proxy object to its
            list of known Internet agents.  If the CMIP request to
            create an SNMP party object succeeds, the ISO/Internet proxy
            adds the SNMP party object to its list of known SNMP
            parties.

            It is the ISO/CCITT manager's responsibility to manage the
            known Internet agents and known SNMP parties.  CMIP requests
            could be initiated by the ISO/CCITT manager to add, delete,
            or modify elements in the known Internet agents and the
            known SNMP parties.

            2.3. Usage

            The known Internet agents, and the known SNMP parties
            provide the basis for the ISO/Internet proxy to perform the
            following translation:


            Chang                                                 Page 7


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992



                 - Translating CMIP requests to SNMP requests
                 - Translating SNMP responses to CMIP responses
                 - Translating SNMP traps to CMIP notifications

            In a CMIP request, the "cmipsxmpProxyEntry" object is
            represented by one of the relative distinguished names (RDN)
            that make up a distinguished name (DN).  In the MIT, there
            are one or more party objects contained under the
            "cmipsxmpProxyEntry" object.

            2.3.1. Security

                    Section 3.3.1.1    Section 3.3.1.2
                             |             |
            +-------------+  |  +------------------+
            |ISO/CCITT mgr|<--->|ISO/Internet Proxy|<---> Internet agent
            +-------------+     +------------------+

            2.3.1.1. The Security Policy between the ISO/CCITT manager
            and the ISO/Internet Proxy

            The information transferred between the ISO/CCITT manager
            and the ISO/Internet proxy is protected by the security
            policy between the ISO/CCITT manager and the ISO/Internet
            proxy (acting as a CMIP agent).  The security policy between
            an ISO/CCITT manager and a CMIP agent is not part of the
            scope of this memo.

            2.3.1.2. The Security Policy between the ISO/Internet Proxy
            and the Internet agent

            The information transferred between the ISO/Internet proxy
            and the Internet agent is protected by a security policy
            between the ISO/Internet proxy and the Internet agent.  In
            order to minimize the network traffic between the
            ISO/Internet proxy and the Internet agent, and also to
            reduce the number of party objects, this security policy
            should be enforced using the following two distinct steps:

            2.3.1.2.1. Local Security Policy

            First, a local security policy that maps a CMIP request to a
            source party and a destination party based on the
            distinguished name, the access control field; and possibly
            the operation type and the attributes in the attribute list.

            The security mapping process should be based on a local
            security policy that is mutually agreed to and implemented
            by the ISO/CCITT manager and ISO/Internet proxy.  The local
            security policy is not within the scope of this memo.  A
            separate memo to define this security policy may be produced
            after the secure SNMP and SMP are finalized.



            Chang                                                 Page 8


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            The ISO/Internet determines a pair of source party and
            destination party contained in the "cmipsxmpProxyEntry"
            object based on the DN, access control parameter, and
            possibly the operation type, and attribute list.  The method
            of selecting the party pair is a local issue.

            If this mapping step fails, the ISO/Internet proxy must send
            an "access denied" error response back to the ISO/CCITT
            manager.  An SNMP request will not be generated by the
            proxy.

            2.3.2. Packaging SNMP Request

            Second, if the previous step is successful, a source party
            and a destination party are chosen as the basis for
            packaging the SNMP request.  The selected SNMP source party
            and destination party specifies the SNMP protocol version
            and the SNMP security protocol to use with the SNMP request
            generated by the ISO/Internet Proxy.

            SNMP request message should be encoded based on the secure
            SNMP protocol using the selected source party and
            destination party.


            3. Elements of CMISE Service Emulation

            The following sections describe the conceptual process for
            performing CMIP service emulation.  In an actual
            implementation, it should be possible to combine some of the
            processes.  It is highly recommended that the implementor of
            the ISO/Internet proxy combine the processes where possible
            to to optimize the implementation.  If the ISO/Internet
            proxy needs to perform an SNMP request to fulfill a CMIP
            request, the ISO/Internet protocol translation that would be
            used to translate the request is described in section 4 of
            this memo.

            3.1. Association Service

            The ISO/Internet proxy should provide the association
            service defined in section 8.1 of ISO/IEC 9596-2;1991.  This
            service includes association establishment and association
            release.  Each CMIP request issued within the context of a
            specific association, should only be performed if the
            request specifies functional units negotiated for the
            association.

            3.2. Management Object Selection - Scoping and Filtering

            Managed object selection is used to determine a set of
            object instances in the MIT on which a CMIP request is to
            operate.  Managed object selection is performed in two
            phases: scoping; and then, filtering. Scoping is used to


            Chang                                                 Page 9


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            specify a sub-tree of object instances in the MIT. A filter
            is then applied to the set of previously scoped object
            instances in order to identify a subset of object instances
            on which the CMIP operation is to be performed.

            The scope specified in the CMIP request is applied to
            determine a set of object instances against which a filter
            (if specified) is to be applied.  If no filter is specified
            the CMIP request will be performed for all object instances
            identified by the scope.

            There are different ways of performing scoping operation.
            This memo specifies one possible way of providing managed
            object selection service.

            3.2.1. Object Class Group

            The following algorithm specifies a method of determining an
            "object class group" that includes a set of object class
            object identifiers.  Each of the object instance within the
            scope, is an instance of an object class that is in the
            object class group.

            The variables used in these steps are fictitious variables
            used to control the process, not attributes or objects.

            Step 1:

            "current level" = 0
            "current level object classes" = the base object specified
                                         in the CMIP request
            "next level object classes" is set to empty
            "object class group" is set to empty

            Step 2:

            If the "current level" is greater than the maximum level
            relative to the base object in the scope or the "current
            level object classes" is empty, go to step 5.

            Step 3.

            If the "current level object classes" is empty, go to
            step 4.

            Take the first object class in the "current level object
            classes".  This object class is called "current object
            class"

            For all the known name bindings in the proxy's schema, if
            the "NAMED BY SUPERIOR OBJECT CLASS" is equal to the
            "current object class", the "SUBORDINATE OBJECT CLASS" is
            added into "next level object classes".



            Chang                                                Page 10


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            If the current level is greater than the minimum level and
            smaller than the maximum level in the scope, the
            "SUBORDINATE OBJECT CLASS" is added into "object class
            group".

            Interate through step 3 again.

            Step 4:

            "current level object classes" = "next level object classes"
            "next level object classes" is set to empty
            bump up "current level" by one

            Iterate through step 2 again.

            Step 5:

            If the "object class group" is empty, there is no object
            instance selected by the scope.  In this case, an empty
            final CMIS response should be returned.

            If the "object class group" is not empty, for each object
            class in the "object class group", the following three steps
            should be taken to retrieve the object instances in the
            scope:

            3.2.2. If the object class is a multiple instance object,
            the first instance (.i.e., the first row in the table)
            should be retrieved.

            If the object class is not a multiple instance object,
            retrieve the object instance of the object class.

            3.2.3. If a filter is specified, apply the filter to the
            retrived value.  If the filter evaluates to FALSE, the CMIP
            operation will not be performed for the object instance.  If
            the filter evaluates to TRUE, the operation will be
            performed for the instance.

            3.2.4. If the object instance is a multiple instance object,
            retrieve succeeding instances (i.e., the succeeding rows in
            the table).  If a filter is specified, apply the filter as
            specified in 5.2.2.  Repeat this process until all instances
            of the multiple instance object (i.e.  all rows) have been
            retrieved.

            The scoping process could be highly optimized by local means
            to retrieve information in multiple ISO/CCITT object
            instances at once.

            The filtering process should also be optimized where it is
            applicable.  For example, if the attribute in the filter
            item does not exist according to the object class
            definition, the ISO/Internet proxy should evaluate the


            Chang                                                Page 11


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            filter as FALSE without trying to retrieve the attribute
            from the object instance.  If the CMIP request is a get
            request, the filter process described above may also be
            combined with the retrieval of the attributes specified in
            the attribute id list.

            3.3. Synchronization

            If the ISO/Internet proxy receives a CMIP "atomic" request,
            but can not perform the operation atomically, the
            "synchronization not supported" CMIP error response should
            be returned to the ISO/CCITT manager.

            The types of atomic requests that the ISO/Internet proxy can
            perform are
            as follows:

                 1) if all the instances selected by a scoped CMIP
                    request are "local object instances", then the
                    ISO/Internet proxy can perform the CMIP request
                    locally (and atomically); and

                 2) if all the CMIP request can be performed by the
                    ISO/Internet proxy using a single SNMP request, then
                    the operation can also be performed atomically.

            For a "best effort" request, the ISO/Internet proxy should
            try to perform the request on all the instances specified by
            the request.  In some cases, the CMIP request has to be
            translated into multiple SNMP requests in order to fulfill
            the original CMIP request.  In the window in which these
            SNMP requests are being processed, another SNMP set request
            could be issued which could modify data in instances
            specified by the scope.  Because of this, the complete
            integrity of the scoped request can not be guaranteed.  A
            proxy which complies with this memo is not required to
            detect or avoid this situation, and will not usually report
            any error if this situation occurs.

            3.4. Management Operation Services

            If the specified instances (i.e., those identified by
            scoping and filtering specified in a CMIP request) are
            "local object", the ISO/Internet proxy would perform the
            services using local means. Instances of "partyTable", and
            "partyEntry" are considered to be "local objects".

            If the specified instances are "remote objects", then the
            following sections apply.  Any objects that physically
            reside in the SNMP agents are considered as "remote
            objects".  For example, any MIB II objects like system, tcp,
            and upd ate considered as "remote objects".

            3.4.1. M-GET Service


            Chang                                                Page 12


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992



            The following sections describe how to provide M-GET
            service.

            3.4.1.1. Check the Existence of the Base Object

            The existence of the ISO/CCITT base object specified in a
            CMIP request should always be verified before scoping is
            started.  If the base object specified in the request does
            not exist in the Internet agent, then the proxy must send a
            "NoSuchObjectInstance" CMIP error response back to the
            ISO/CCITT manager.

            If the base object is a table entry or an SNMP group with at
            least one Internet object type (i.e., not a pseudo object),
            the ISO/Internet proxy should try to retrieve at least one
            attribute of the base object from the SNMP agent to verify
            the existence of the base object.

            If the base object is a pseudo object, the ISO/Internet
            proxy should try to retrieve at least one attribute from the
            first subordinate object in the MIT that is not a pseudo
            object, in order to verify the logical existence of the base
            object (pseudo object).

            3.4.1.2. Perform the Get Operation

            If scoping or filtering is specified, the process described
            in section 4.2 of this memo is used to select the ISO/CCITT
            object instances.  For each selected ISO/CCITT object
            instance, all of the attributes specified in the "Attribute
            identifier list" parameter of the CMIP request are
            retrieved.  If the "Attribute identifier list" parameter is
            omitted, all attributes of the instance are of retrieved.
            The list of attributes are in an object class are included
            in the definition of the object class.  It is recommeded
            that the retrieval of the attributes be combined with the
            retrieval of the attributes specified by the filter.

            Section 5.4 describes the CMIP M-GET to SNMP get protocol
            mapping.

            3.4.1.3. Form the Response(s)

            The CMIP M-GET response should contain the attribute value
            list or the appropriate get list error.  Once the M-GET
            response has been formatted, it should be passed to the CMIP
            service provider.

            If the CMIP get request is a scoped request, each ISO/CCITT
            object should be reported as link reply.  a final empty CMIS
            M-GET response should be returned to the ISO/CCITT manager
            when the scoped request completes.



            Chang                                                Page 13


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            The managed object instance in the CMIP get response should
            use the the distinguished name (DN) specified in the
            original CMIP request as a prefix.  The get responses for
            subordinate objects below the base object in the naming
            tree, should contain DN's that are formed from the
            concatenation of the DN from the original CMIP request and
            the RDN's specifying the table entry deleted.

            3.4.2. M-CANCEL-GET Service

            The CMIP cancel get operation should be performed as
            described in ISO/IEC 9596.  The ISO/Internet proxy does not
            need to translate this request to any SNMP requests.

            After receiving a cancel-get request message the
            ISO/Internet proxy should terminate any outstanding
            communications with the Internet agent that were initiated
            as a result of the get request that is being canceled.  Once
            the cancel-get has been processed and responded to, the
            ISO/Internet proxy should not send any additional response
            messages to the ISO/CCITT manager for the get operation that
            was canceled.

            3.4.3. M-SET Service

            The following sections describe how to provide M-SET
            service.

            3.4.3.1. Check the Existence of the Base Object

            This operation is the same as described in section 4.4.1.1.

            3.4.3.2.  Scope and Filter

            This operation is the same as described in section 4.4.1.2.

            3.4.3.3. Perform the Set Operation

            For each selected ISO/CCITT object instance, the attributes
            specified in the "Modification list" parameter of the CMIP
            request are modified based on each attribute's modify
            operator.  Only the "replace" modify operator is supported
            by the ISO/Internet proxy.  The modify operator is optional
            and if it is not specified in a CMIP request, the "replace"
            operator should be assumed.

            The "add value" and "remove value" modify operators are not
            supported by SNMP protocol, and are not supported by the
            ISO/Internet proxy.  The "set to default" modify operator is
            not supported by the ISO/Internet proxy since the
            ISO/Internet proxy is acting as an Internet manager. The
            "set to default" behaviour is optionally implemented by the
            Internet agent, not the Internet manager.  If the modify



            Chang                                                Page 14


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            operator is not supported, "invalid operator" should be
            reported in the set list error.

            Section 5.5 of this memo describes the CMIP M-SET to SNMP
            set protocol mapping.

            3.4.3.4. Form the responses

            The CMIP M-SET response should contain the attribute value
            list or the appropriate set list error.  Once the M-SET
            response has been formatted, it should be passed to the CMIP
            service provider.

            If the CMIP set request is a scoped request, each ISO/CCITT
            object should be reported as link reply.  A final empty
            CMISE M-SET response should be returned to the ISO/CCITT
            manager when the scoped request completes.

            The managed object instance in the CMIP set response should
            use the the distinguished name (DN) specified in the
            original CMIP request as a prefix.  The set responses for
            subordinate objects below the base object in the naming
            tree, should contain DN's that are formed from the
            concatenation of the DN from the original CMIP request and
            the RDN's specifying the table entry deleted.

            3.4.4. M-ACTION Service

            The proxy is not required to emulate the CMIS M-ACTION
            service because Internet MIBs do not include any definitions
            which translate into M-ACTIONs in an ISO/CCITT GDMO MIB.
            Any CMIS M-ACTION request which is received pertaining to an
            Internet MIB object will be rejected by the proxy with an
            invalidOperation error response. However, CMIS M-ACTION may
            be used by the proxy for other purposes

            3.4.5. M-CREATE Service

            3.4.5.1. Request Validation

            The ISO/Internet proxy is responsible for validating that
            the CMIP create request does not violate name binding and
            object class definitions.

            3.4.5.1.1. Name Binding

            The ISO/Internet proxy must determine from the CREATE
            parameter in a name binding if an instance may be created.
            If the instance cannot be created, an "access denied" error
            response should be returned.

            The ISO/Internet proxy must also determine from the name
            binding if the instance specified in the request may be
            created under the specified superior in the MIT.  If the


            Chang                                                Page 15


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            name binding does not allow the specified containment
            relationship, an "invalidOperation" error response should be
            returned.

            3.4.5.1.2. Check for Duplication

            Determine if the instance already exists.  If it does, a
            "duplicate managed object instance"i error response should
            be returned.

            See 4.4.1.1. of this memo for checking the existence of an
            object.

            3.4.5.2. With Referenced Object

            If a CMIP create request specifies a reference object, the
            ISO/Internet proxy should retrieve the referenced object
            from the Internet agent.  If the reference object does not
            exist, the proxy must send a "No such reference object"
            error response back to the ISO/CCITT manager.

            3.4.5.3. With Automatic Instance Naming

            A CMIP create request can use automatic instance naming to
            form a name for the object instance to be created.
            Automatic instance naming is used if: a) a CMIP create
            request does not specify a distinguished name for the object
            instance to be created; and b) the request specifies an
            object class that has a name binding allowing automatic
            instance naming.

            It is the responsibility of the ISO/Internet proxy to form
            the name based on the behavior of the object class.  In some
            cases, the relative distinguished name (RDN) is formed using
            attributes provided in the CMIP request.  For example, the
            RDN for "atEntry" in MIB-II could be formed from the
            "atNetIfIndex" attribute and the "atNetAddress" attribute.
            In other cases, the RDN can be assigned by the ISO/Internet
            proxy.

            If the superior object instance is not specified, the
            ISO/Internet proxy can not create the object instance and
            "processing failure" error should be returned.

            3.4.5.4. Perform the Create Operation

            If the combination of the attributes specified in the CMIP
            request and the attributes obtained from the reference
            object do not provide attribute values for all of the
            mandatory attributes for the entry specified by the object
            class being instantiated, then the ISO/Internet proxy should
            still try to create the object with all the available
            attributes.



            Chang                                                Page 16


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            If the actual creation process based on the available but
            incomplete attribute list succeeds, the ISO/Internet proxy
            should retrieve all the attributes on the newly created
            entry since the Internet agent may fill in the missing
            attributes with the Internet agent's own default values.  If
            the missing attributes are provided by the agent, the CMIP
            create response should include the attributes that were
            provided by the Internet agent in its CMIP response.

            If the actual creation process based on the available but
            incomplete attribute list fails, the ISO/Internet proxy
            should send a "missing attribute value" error back to the
            ISO/CCITT manager.

            See 3.4.1.1. of this memo for checking the existence of an
            object.

            3.4.5.5. Form the responses

            The CMIP M-CREATE response should be formatted and then
            should passed to the CMIP service provider.

            The managed object instance in the CMIP set response should
            use the the distinguished name (DN) specified in the
            original CMIP request as a prefix.  The set responses for
            subordinate objects below the base object in the naming
            tree, should contain DN's that are formed from the
            concatenation of the DN from the original CMIP request and
            the RDN's specifying the table entry deleted.

            3.4.6. M-DELETE Service

            3.4.6.1. Check the Existence of the Base Object

            This operation is the same as described in section 3.4.1.1.

            3.4.6.2.  Scope and Filter

            This operation is the same as described in section 3.4.1.2.

            3.4.6.3. Perform the Delete Operation

            For all the selected ISO/CCITT object instances, the
            following procedures should be taken:

            3.4.6.3.1. Name binding

            Determine from the name binding if the instance specified in
            the request may be deleted.  If the name binding does not
            allow the specified delete operation, "access denied" error
            response should be returned.

            3.4.6.3.2. Check the Existence of the Selected Object



            Chang                                                Page 17


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            For each selected object, the following steps should be
            taken.

            If the selected object is a table entry or an SNMP group
            with at least one Internet object type (not a pseudo
            object), the ISO/Internet proxy should try to retrieve at
            least one attribute of the object from the SNMP agent to
            verify the existence of the selected object.

            If the base object is a pseudo object, the ISO/Internet
            proxy should try to retrieve at least one attribute from the
            first subordinate object in the MIT that is not a pseudo
            object, in order to verify the logical existence of the base
            object (pseudo object).

            3.4.6.3.3. Perform the Delete Operation

            If the object instance specified in the CMIP delete request
            exists, the delete operation is performed.

            3.4.6.3.4. Form the responses

            Format the CMIP M-DELETE response with the appropriate
            attribute list or delete list error.  Once the M-DELETE
            response has been formatted, it should be passed to the CMIP
            service provider.

            The managed object instance in the CMIP delete response
            should use the the distinguished name (DN) specified in the
            original CMIP request as a prefix.  The delete responses for
            subordinate objects below the base object in the naming
            tree, should contain DN's that are formed from the
            concatenation of the DN from the original CMIP request and
            the RDN's specifying the table entry deleted.

            3.5. Management Notification Services

            All the SNMP traps should be mapped to CMIP notifications.
            Only unconfirmed mode is used since the SNMP traps are not
            confirmed.

            An SNMP trap is translated to a single CMIP event report.
            The following procedures should be used to translate an SNMP
            trap to a CMIP event report.

            3.5.1.  Object Class

            The object class parameter in the CMIP event report should
            be set to the appropriate object class as defined in the
            object class definitions.

            3.5.2.  Object Instance




            Chang                                                Page 18


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            The object instance parameter in the CMIP event report is
            determined from information provided in the SNMP trap.  The
            SNMP trap sender's transport type, transport address, and
            network address are used to determine the DN of the proxy
            object instance.

            3.5.3. Event Time

            The event time parameter in the CMIP event report should be
            calculated based on the time stamp field in the SNMP trap.

            3.5.4. Event Type

            The event type parameter in the CMIP event report should be
            determined by the generic trap field and enterprise specific
            trap field in the SNMP trap.

            3.5.5. Event Info

            The event type parameter in the CMIP event report should be
            determined from a Notification definition.

            3.5.6. If any of the translations in the preceding sections
            fail, no CMIP event report is produced.

            3.6. Common Response Parameter

            This memo does not specify a standard translation for the
            timestamp value in the CMIP response.  However, the
            following paragraphs describe two potential implementations
            for this translation:

                  - ISO/Internet proxy's local time
                  - Internet agent's local time with fixed unknown delta

            3.6.1. ISO/Internet Proxy's Local Time

            The timestamp value in the CMIP response is set to the time
            provided by the ISO/Internet proxy's internal clock when a
            request's final SNMP response is received.

            3.6.2. Internet agent's local time with fixed unknown delta

            The ISO/Internet proxy should query the Internet agent for
            "sysUpTime" in addition to the original SNMP variable
            binding list in the first SNMP request.  The value should be
            recorded as the "agent's initial sysUpTime" and the
            ISO/Internet proxy's local time should be recorded as
            "initial contact time".

            Each CMIP request is translated to one or more SNMP requests
            by the ISO/Internet proxy to fulfill the CMIP request.  If
            the last SNMP request for the same CMIP request is an SNMP
            get request, the "sysUpTime" should be added into the SNMP


            Chang                                                Page 19


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            variable binding list.  Otherwise, an extra SNMP get request
            is issued with "sysUpTime" as the only element in the
            variable binding list.  This new "sysUpTime" is called
            "agent's current sysUpTime".

            The timestamp in the last CMIP response should be calculated
            using this formula: "initial contact time" + (agent's
            current sysUpTime - agent's initial sysUpTime").

            This approach eliminates the inaccuracy caused by network
            delay between the ISO/Internet proxy and Internet agent and
            gives the ISO/CCITT manager a more accurate time on when an
            operation is actually performed by the Internet agent rather
            than the time that is processed by the ISO/Internet proxy.


            4. CMIP and SNMP Protocol Mapping

            To retrieve and modify SNMP entries, the ISO/Internet proxy
            is required to perform CMIP and SNMP protocol translation.
            A CMIP request is translated to one or more SNMP requests.
            SNMP responses are translated to CMIP responses.  SNMP traps
            are translated to CMIP notifications.

            4.1.  Management Object Selection - Scoping and filtering

            A managed object selection process is described in section
            4.2 of this memo.  Section 3.2.2 and 3.2.4 state:

                 3.2.2. If the object class is a multiple instance
                 object, the first instance (.i.e., the first row in the
                 table) should be retrieved.

            The ISO/Internet proxy would issue SNMP get-next requests to
            retrieve the instance information from the table.

            Each attribute in the object class is used to form a
            variable binding in the variable binding list in the SNMP
            request.  The attributes in the object class are maintained
            by the ISO/Internet proxy locally.

            Each attribute in the object class is used as the "name"
            field in the variable binding.  The ISO/Internet proxy
            composes a variable binding list and then encodes an SNMP
            get-next request.

                 3.2.4. If the object instance is a multiple instance
                 object, retrieve succeeding instances (i.e., the
                 succeeding rows in the table).  If a filter is
                 specified, apply the filter as specified in 3.2.2.
                 Repeat this process until all instances of the multiple
                 instance object (i.e.  all rows) have been retrieved.




            Chang                                                Page 20


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            The ISO/Internet proxy should issue SNMP get-next requests
            to retrieve the succeeding object instance.  The variable
            binding list is the same as the the variable binding list in
            the previous SNMP get response (that resulted from the
            previous get-next request).

            If the SNMP error, noSuchName, occurs when an attribute is
            queried as part of a filter evaluation, then the filterItem
            will be evaluated as FALSE.

            4.2. Check for Existence of the Object to be Created

            Section 3.4.1.1 of this memo:

                 If the base object is a table entry or an SNMP group
                 with at least one Internet object type (i.e., not a
                 pseudo object), the ISO/Internet proxy should try to
                 retrieve at least one attribute of the base object from
                 the Internet agent to verify the existence of the base
                 object.

            The ISO/Internet proxy should issue an SNMP get request to
            retrieve at least one attribute in the base object.  The
            variable binding is composed using information specified in
            the CMIP request.

                 If the base object is a pseudo object, the ISO/Internet
                 proxy should try to retrieve at least one attribute
                 from the first subordinate object in the MIT that is
                 not a pseudo object, in order to verify the logical
                 existence of the base object (pseudo object).

            The ISO/Internet proxy should issue an SNMP get-next request
            is used to retrieve at least one attribute from the first
            subordinate object in the naming tree that is not a pseudo
            object.

            In both of the above cases, a variable binding is needed in
            the SNMP request.  The variable binding contains "name" and
            "value".  Only "name" is significant in the SNMP request.

            4.2.1 SNMP Entry

            If the base object is an "SNMP entry", the first component
            in the "name" field is taken from any attribute in the
            object class.  The object class is specified in the CMIP
            request and the attribute is obtained from the object class
            definition by the ISO/Internet proxy using local means.  The
            process specified in section 5.8 of this memo could be used
            to form the variable binding.  Once the variable binding has
            been formed, an SNMP get request is issued to get the
            attribute value, which will validate the existence of the
            base object.



            Chang                                                Page 21


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            4.2.2. Pseudo Entry

            If the base object is a "pseudo entry", there is no SNMP
            entry that maps to this ISO/CCITT entry.  Therefore the
            first SNMP subordinate entry of this base object is queried
            to verify the existence of this base object.

            The "name" field is taken from the object class object
            identifier directly to form the SNMP get-next request.

            If the "name" field in the variable binding in the SNMP get
            response contains the same object identifier prefix as the
            request, the ISO/Internet proxy can conclude that this
            pseudo entry should exist.  If the "name" field in the SNMP
            request and the "name" field in the SNMP response does not
            have the same object identifier prefix, the ISO/Internet
            proxy can conclude that the pseudo entry does not exist.
            The same object identifier prefix means that the "name"
            field, which is a object identifier, in the response should
            contain the same object identifier as the one in the request
            with one or more additional digits

            If SNMP "no such name" error is received, the ISO/Internet
            proxy can conclude that the pseudo entry does not exist.
            Any other error should refer to section 5.9 of this memo.

            Note.  The same method can also be used to verify the
            existence of an SNMP "group" entry.


            4.3. Create With Referenced Object

            An SNMP get request should be issued to obtain the
            attributes in the referenced object.

            Each attribute in the object class forms a variable binding
            in the variable binding list in the SNMP request.  The
            attributes in the object class id maintained by the
            ISO/Internet proxy locally.

            For each attribute in the object class, the process
            described in section 5.8 of this memo should be taken to
            form the variable binding.  The ISO/Internet then compose a
            variable binding list.

            If SNMP "no such name" error is received, the ISO/Internet
            proxy can conclude that the pseudo entry does not exist.
            Any other error should refer to section 5.9 of this memo..

            4.4. Perform the Get Operation

            For each selected attribute, the ISO/Internet proxy should
            use the process defined in 5.8 of this memo to form the
            variable binding.  The ISO/Internet proxy should then form


            Chang                                                Page 22


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            the variable binding list and then issue an SNMP get request
            to perform the get operation.

            4.5. Perform the Set Operation

            For each attributes, the ISO/Internet proxy should use the
            process defined in section 5.8 of this memo to form the
            variable binding.  The "value" field will be taken from the
            modification list.  The ISO/Internet proxy should then form
            the variable binding list and then issue an SNMP set request
            to perform the set operation.

            4.6. Perform the Create Operation

            For each available attributes, the combination of the
            attributes specified in the CMIP request and the attributes
            obtained from the reference object, the ISO/Internet proxy
            should use the process defined in section 5.8 of this memo
            to form the variable binding list.  The "value" field will
            be taken from either the CMIP request or the referenced
            object.

            4.7. Perform the Delete Operation

            The ISO/Internet proxy needs to determine the attribute type
            and attribute value that indicates an entry has been
            deleted.  This information is maintained locally by the
            ISO/Internet proxy.

            Each object selected by the CMIP delete request is
            translated to a variable binding.  All of the selected
            objects could be translated into variable bindings within
            one SNMP set request.  If the request is too big, the
            ISO/Internet proxy should divide the request to smaller
            requests.

            For each to-be-deleted object, the ISO/Internet proxy should
            use the process defined in section 5.8 of this memo to form
            the variable binding.  The "value" field will be filled in
            using the attribute value that indicates  an entry has been
            deleted.

            4.8. Form a Variable Binding

            The variable binding contains two fields: "name" and
            "value".  The "name" field is composed by the ISO/Internet
            proxy based on its object class, attribute, and a RDN.

            The "name" field in the variable binding is formed from the
            concatenation of two components.

            The first component in the "name" field is the attribute's
            object identifier.



            Chang                                                Page 23


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            There are two cases for the second component in the "name"
            field.

            If the object class is a "single instance" object, (i.e., an
            SNMP group or an SNMP table), the digit "0" is used for the
            second component.

            If the object class is a "multiple instance" object (i.e., a
            table entry), and if a RDN is supplied, the Internet object
            instance might be derived from the RDN.  An RDN consists of
            an attribute type and an attribute value.  The attribute
            value of the RDN has two parts.  The first part of the value
            is the object class object identifier.  The second part of
            the value is the Internet object instance.  This second part
            of the value is used as the second component in the "name"
            field of the variable binding.

            Example 1: single instance object

            Input:Object class: system
                  Attribute: sysName
                  attribute value in the RDN: system

            The SNMP variable binding: sysName.0


            Example 2: multiple instance object

            Input:Object class: ipRouteEntry
                  Attribute: ipRouteDest
                  attribute value in the RDN: ipRouteEntry.192.22.83.97

            The SNMP variable binding: ipRouteDest.192.22.83.97


            4.9. SNMP error to CMIP error mapping

            SNMP error responses received by the ISO/Internet proxy are
            translated to CMIP error responses and sent back to the
            ISO/CCITT manager.  The sections that follow list the SNMP
            errors that could be received, and describes which CMIP
            error responses they will be translated to.

            4.9.1. tooBig

            If the SNMP error, tooBig, is received, the ISO/Internet
            proxy should try to break the SNMP request to smaller
            requests and resend the requests.  If it is not feasible to
            break the request to any smaller request, and this error
            occurs, the CMIP error response, "Resource limitation",
            should be returned to the ISO/CCITT manager.

            4.9.2. noSuchName



            Chang                                                Page 24


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            If the SNMP error, noSuchName, occurs when an attribute is
            queried as part of a filter evaluation, then the filterItem
            will be evaluated as FALSE.

            In order to check if an object exists, all the object
            class's attributes should be queried until at least one
            attribute's existence is verified.  if none of the
            attributes exist, and the object is the base object, then a
            "NoSuchObjectInstance" CMIP error response should be
            returned.

            If the object exists and the SNMP error, noSuchName, occurs
            when attempting to modify an attribute while processing the
            attribute list, a "No such attribute" CMIP error response
            should be returned to the ISO/CCITT manager.

            If the ISO/Internet proxy maintains correct schema
            information and the SNMP agent is a conformant agent, an
            Internet object's attributes should all exist or not exist.
            In order to make the ISO/Internet proxy a practical
            solution, the preceding error situation is included in order
            to deal with a non-conformant Internet agent.

            4.9.3. badValue

            If the SNMP error, badValue, is returned for an SNMP get
            request, then a "processing failure" CMIP error response
            should be returned to the CMIP manager.  In the
            ProcessingFailure parameter of the CMIP error response, the
            errorId should be snmpBadValue, and the errorInfo should be
            the variable binding identified by the error-index.

            If the badValue error occurs during an SNMP set request to
            fulfil a CMIP delete request, a "processing failure" CMIP
            error response should be returned.  In the ProcessingFailure
            parameter, the errorId should be canNotDelete and the
            errorInfo should be the variable binding that is identified
            by the error-index.

            4.9.4. readOnly

            If the SNMP error, readOnly, occurs when checking for the
            existence of a base object, a "processing failure" CMIP
            error response should be returned to the ISO/CCITT manager.
            In the ProcessingFailure parameter of the CMIP error
            response, the errorId should be snmpReadOnly, and the
            errorInfo should be the variable binding identified by the
            error-index.

            If the readOnly error occurs when deleting the object, then
            the deleteErrorInfo in the delete response should be set to
            "access denied".

            4.9.5. genErr


            Chang                                                Page 25


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992



            If the SNMP error, genErr, occurs, the "ProcessingFailure"
            CMIP error response should be returned to ISO/CCITT manager.
            If the entry exists, scoping continues; otherwise, scoping
            terminates.  In the ProcessingFailure parameter of the CMIP
            error response, the errorId should be snmpGenErr.


            5. CMIP Processing Failure

            There are many error scenarios in which the error can not be
            mapped to a specific CMIP error.  In this case, the
            "processing failure" CMIP error response should be reported
            back to the ISO/CCITT manager.  In order to provide the
            ISO/CCITT manager a better description of the error, the
            specificErrorInfo field in ProcessingFailure is used to
            record the cause of the problem.

            The following object identifiers are defined:

                 errors         OBJECT IDENTIFIER :: { oim 11 }

                 snmpTooBig     OBJECT IDENTIFIER :: { errors 0 }
                 snmpBadValue   OBJECT IDENTIFIER :: { errors 1 }
                 snmpReadOnly   OBJECT IDENTIFIER :: { errors 2 }
                 snmpGenErr     OBJECT IDENTIFIER :: { errors 3 }
                 noResponse     OBJECT IDENTIFIER :: { errors 4 }
                 canNotDelete   OBJECT IDENTIFIER :: { errors 5 }
                 notImplemented OBJECT IDENTIFIER :: { errors 6 }

            For errorId snmpTooBig, the errInfo is defined as
            VarBindList.
            For errorId snmpBadValue, the errInfo is defined as VarBind.
            For errorId snmpReadOnly, the errInfo is defined as OBJECT
            IDENTIFIER.
            For errorId canNotDelete, the errInfo is defined as VarBind.
            For errorId notImplemented, the errInfo is defined as

                 INTEGER {
                           filter(0),
                           scope(1),
                           transport(2),
                           AuthenticationProtocol(6),
                           PrivacyProtocol(7)
                       }


            6. Functional Units

            A ISO/Internet proxy implementation that claims conformance
            to this memo must state the functional units that it
            supports.  Two functional units are defined:

                 a) a minimum proxy functional unit; and


            Chang                                                Page 26


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


                 b) an additional scoping functional unit.

            The minimum proxy functional unit requires the support of
            create operations, scoped get operations, base-object-only
            set operations, base-object-only delete operations, and
            notifications.

            The additional scoping functional unit requires the support
            of scoped set operations and scoped delete operations.

            This memo assigns the following object identifier:

                 {  cmipsxmpProxy  aAssociateUserInfo(7) }
            Editor's note: cmipsxmpProxy is specified in [OIMTRANSMIB].

            as a value of ASN.1 type FunctionalUnitPackageId defined in
            CCITT Rec.  X.701 | ISO/IEC 10040 to use for negotiating the
            following functional units:

                 0    minimum proxy functional unit; and
                 1    additional scoping functional unit.

            Where the above number identifies the bit position in the
            BIT STRING assigned to the functional units.

            Editor's note:  Is functional unit appropriate?  Maybe some
            sort of compliance sentence is more appropriate?  Is this
            section needed at all? Suggestions?


            7.   Abbreviations

            CMIP: Common Management Information Protocol
            MIB:  Management Information Base
            DN:   Distinguished Name
            RDN   Relative Distinguished Name
            SNMP: Simple Network Management Information Protocol


            8.   Acknowledgements

            The following individuals provided valuable comments on the
            memo prior to its initial distribution.

                 Dean Voiss, NetLabs
                 Jon Biggar, NetLabs
                 Lee LaBarre, MITRE
                 Lisa Phifer, Bellcore
                 Steve Ng, MPR Teltech


            References




            Chang                                                Page 27


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            [ISO8824]  ISO/IEC IS 8824: Information Technology - Open
                       System Interconnection - Specification of
                       Abstract Syntax Notation One (ASN.1),1990.

            [ISO10165-4]   ISO/IEC IS 10165-4: Information Technology -
                       Open Systems Interconnection - Structure of
                       Management Information - Part 4: Guidelines for
                       the Definition of Managed Objects, 1991.

            [ISO9595]  ISO/IEC IS 9595, Information Technology - Open
                       Systems Interconnection - Common Management
                       Information Service Definition, 1991.

            [ISO9596-1]ISO/IEC IS 9596-1, Information Technology - Open
                       Systems Interconnection - Common Management
                       Information Protocol - Part 1: Specification,
                       1991.

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

            [RFC1157]  RFC 1157, J.D. Case, M.S. Fedor, M.L.
                       Schoffstall, C. Davin, Simple Network Management
                       Protocol (SNMP),  May 1990.

            [RFC1351]  RFC 1351, Davin, J., Galvin, J., and K.
                       McCloghrie, "SNMP Administrative Model", MIT
                       Laboratory for Computer Science, Trusted
                       Information Systems, Inc., Hughes LAN Systems,
                       Inc., July 1992.

            [RFC1352]  RFC 1352, Galvin, J., McCloghrie, K., and J.
                       Davin, Trusted Information Systems, Inc., Hughes
                       LAN Systems, Inc., MIT Laboratory for Computer
                       Science, July 1992.

            [RFC1353]  RFC 1353, McCloghrie, K., Davin, J., and J.
                       Galvin, "Definitions of Managed Objects for
                       Administration of SNMP Parties", Hughes LAN
                       Systems, Inc., MIT Laboratory for Computer
                       Science, Trusted Information Systems, Inc., July
                       1992.

            [OIMTRANSMIB]  Lee LaBarre, ISO and Internet Management
                       Coexistence (IIMC): Translation of Internet MIBs
                       for ISO/Internet Proxy.  The MITRE Corporation,
                       September 92.

            [OIMPARTY] Lee LaBarre, ISO and Internet Management
                       Coexistence (IIMC): Proxy MIB for the SNMP Party
                       MIB.  The MITRE Corporation, September 92.




            Chang                                                Page 28


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            [OIMMIB-II]Lee LaBarre, ISO and Internet Management
                       Coexistence (IIMC): Proxy Management Information
                       Base II for TCP/IP Networks.  The MITRE
                       Corporation, September 92.

            [IIMCOMIBTRANS] O. Newnan, ISO/CCITT and Internet Management
                       Coexistence: Translation of ISO/CCITT GDMO MIBs
                       to Internet MIBs, October 1992.


            Appendix A: CMIP to RFC 1157 Agent proxy

            The philosophy of implementation for either a ISO/Internet
            proxy that acts as a proxy for an RFC 1157 Internet agent,
            or for a proxy for a secure Internet agent, is quite
            similar.  The following sections describe the differences
            between the two types of proxy agents.

            1. SNMP Protocol Selection

            The partyauthprotocol attribute in the selected SNMP party
            object indicates which SNMP protocol is to be used.  If the
            community protocol is selected, the ISO/Internet proxy
            encodes the SNMP message based on the definition in RFC
            1157.  If the md5 authentication protocol is selected, the
            ISO/Internet proxy encodes the SNMP message based on the
            definition in the secure SNMP memos.

            2. Security Protocol Selection

            If the attribute, partyAuthProtocol, indicates that the
            community protocol is to be used, the attribute,
            partyAuthPriv, provides the value for the community string
            that is to be used to form the SNMP request.

            If the attribute, partyAuthProtocol, indicates that the md5
            authentication protocol is to be used, the SNMP message
            should be encoded using the appropriate authentication and
            encryption mechanisms based on the definition in the secure
            SNMP memos.


            3. Internet agent Address Resolution

            For each of the CMIP requests received by the ISO/Internet
            proxy, an SNMP source party and a destination party are
            selected based on the DN and access control fields in the
            CMIP request.  The SNMP party object selected is the source
            party object contains the Internet agent's address
            information in the following two attributes: partyTDomain;
            and partyTaddr.

            The attribute, partyTDomain, specifies the transport
            mechanism.  The attribute, partyTAddr, specifies the


            Chang                                                Page 29


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            transport and network address.  The address format of the
            partyTaddr is determined from the value of the partyTDomain
            attribute.

            4. readyOnly error

            If the Internet agent that the ISO/Internet proxy represents
            is an RFC 1157 community-based Internet agent, the the SNMP
            readOnly error should never be received by the proxy.  If
            this error is received, a "processing failure" CMIP error
            response should be returned to the ISO/CCITT manager.  In
            the ProcessingFailure parameter, the errorId should be
            snmpReadOnly and the errorInfo should be the variable
            binding that is identified by the error-index.


            Appendix B: Example Operation

            Operation: CMIP get request
            Object class: ip
            Object instance:{cmipsxmpProxyId = "NetLabs" }
                            {internetClassId = ip }
            Scope: 2nd level down
            Filter: ipRouteType == indirect
            Attribute id list: ipRouteDest

            Example SNMP ipRouteEntries:

                 ipRouteDest    ipRouteType    Other object types
                 -----------    -----------    ------------------
                 192.95.93.1    direct
                 192.95.93.2    indirect
                 192.95.93.3    invalid
                 192.95.93.4    other
                 192.95.93.5    indirect
                 (end of the table)

            The following sections show an example of how the
            ISO/Internet proxy fulfills the above CMIP get request based
            on the example SNMP ipRouteEntries.

            1. Check the existence of the base object:

            The ISO/Internet proxy issues a SNMP get next request.

                 GetNextRequest { ip }
                 GetResponse { ipForwarding = 1 }

            If the get is successful, the ISO/Internet proxy would have
            verified that the base object exists.

            2. Managed object selection




            Chang                                                Page 30


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


            Based on the name binding definition, the following object
            classes are found in the "object class group":

                 a) ipAddrEntry
                 b) ipRouteEntry
                 c) ipNetToMediaEntry

            For each object in the "object class group", the object
            instances may be retrieved via SNMP get next requests.

               a) ipAddrEntry: The object class definition for this
                 object class does not contain the attribute specified
                 in the filter (ipRouteType), therefore the ISO/Internet
                 proxy will conclude that there is no object instances
                 with ipAddrEntry object class in the scope.

               b) ipRouteEntry:  The object class definition for this
                 object class contains the attribute specified in the
                 filter (ipRouteType), therefore the ISO/Internet proxy
                 would issue SNMP get next request to retrieve the
                 object instances.  The SNMP requests issued and the
                 responses received would be as follows:

               GetNextRequest {ipRouteDest, ipRouteType}
               GetResponse {ipRouteDest.192.94.93.1 = 192.94.93.1,
                            ipRouteType.192.94.93.1 = direct}

               GetNextRequest {ipRouteDest.192.94.93.1,
                               ipRouteType.192.94.93.1}
               GetResponse {ipRouteDest.192.94.93.2 = 192.94.93.2,
                            ipRouteType.192.94.93.2 = indirect}

               GetNextRequest {ipRouteDest.192.94.93.2,
                               ipRouteType.192.94.93.2}
               GetResponse {ipRouteDest.192.94.93.3 = 192.94.93.3,
                            ipRouteType.192.94.93.3 = invalid}

               GetNextRequest {ipRouteDest.192.94.93.3,
                               ipRouteType.192.94.93.3}
               GetResponse {ipRouteDest.192.94.93.4 = 192.94.93.4,
                            ipRouteType.192.94.93.4 = other}

               GetNextRequest {ipRouteDest.192.94.93.4,
                               ipRouteType.192.94.93.4}
               GetResponse {ipRouteDest.192.94.93.5 = 192.94.93.5,
                            ipRouteType.192.94.93.5 = indirect}

               GetNextRequest {ipRouteDest.192.94.93.5,
                               ipRouteType.192.94.93.5}
               GetResponse {ipRouteIfIndex = 5,
                            ipRouteProto = 1}

               c) ipNetToMediaEntry: The object class definition for
                 this object class does not contain the attribute


            Chang                                                Page 31


            Draft      ISO/CCITT to Internet Management Proxy  10/9/1992


                 specified in the filter (ipRouteType), therefore the
                 ISO/Internet proxy will conclude that there is no
                 object instances with ipNetToMediaEntry object class in
                 the scope.

            There are a set of five object instances in the scope. After
            the filter is applied to these five object instances, there
            are only two object instances left on which the get
            operation is performed.

            3. Form the response

            The following CMIP responses should be formed and sent back
            to the ISO/CCITT manager

                 CMIP get link reply:
                      Object class: ipRouteEntry
                      Object instance:{cmipsxmpProxyId = "NetLabs" }
                           {internetClassId = ip }
                           {internetClassId = ipRouteTable }
                           {internetClassId = ipRouteEntry.192.94.93.2 }
                      Attribute list: ipRouteDest = 192.4.93.2

                 CMIP get link reply:
                      Object class: ipRouteEntry
                      Object instance:{cmipsxmpProxyId = "NetLabs" }
                           {internetClassId = ip }
                           {internetClassId = ipRouteTable }
                           {internetClassId = ipRouteEntry.192.94.93.5 }
                      Attribute list: ipRouteDest = 192.4.93.5

                 Final Empty CMIS M-GET response


                      - INTERNET DRAFT Expires April 23, 1993 -





















            Chang                                                Page 32